最近在看亚马逊首席技术官Werner Vogels博士关于俭约架构演讲视频的时候，里面有一句话特别触动：Constrains breed creativity，翻译过来的意思是：约束孕育创造力。
时间总是不够，资源一定不足。被很多人吐槽的“既要...又要”的约束，确实实在在的创造了很多经典。
01 半个房子的故事
2004年，智利政府找到建筑设计师Alejandro，希望他为一百个贫民家庭提供社会保障房。这些家庭都是从智利农村进入城市，他们非法占据了市中心半公顷的土地，政府希望把他们彻底的安置下来。政府给他的预算是每户7500美元，他要用这7500美元来买土地、提供基础设施、建造住房。
政府提供的预算有限，如果按照预算建造能容纳一百个家庭的房子，在已有方案中只有高层公寓一个选项，但是这些家庭都强烈发对，甚至要绝食抗议。到这里似乎陷入了僵局。
但最终Alejandro给出了他自己的答案，就是建造下图这种“半个房子(Half A House)”，即为这些家庭设计的只完成一半的住房，另一半则留给居民根据自身需求和财力进行扩建。
“半个房子”不仅解决了这些家庭的住房问题，还激发了居民的创造力和自主性，把这些居民的力量利用起来，让他们参与到整个设计建造流程当中去。既给了他们自由，又能在有限的预算里，安排出最多的安置房。
结果也和Alejandro预想的一样，这些居民积极参与到房子的建设中，和其他难民安置区犯罪率高企完全不一样，这个安置小区变成了一个生活环境很好的小社区，而Alejandro也因这个项目在2004年获得了号称建筑界诺贝尔奖的普利兹克奖。
02 软件架构设计
软件架构设计同样面临各种约束，在满足业务功能需求的同时，架构设计还要考虑非功能性需求，如安全性、性能、可用性等。Alejandro博士2023年re:Invent大会上提出了“俭约架构”的概念，指出软件架构师应该要具备成本意识和优化策略。
Alejandro博士分享了俭约架构的七个核心思想。
1. Cost is a Non-Functional Requirement：将成本视为一个非功能性需求
当架构师在架构设计时候，除了业务功能需求以外，通常都会考虑安全性、合规性、可访问性、性能等非功能性需求，但成本和可持续性常常被忽视。这两者应该受到同等重视，我们必须在设计架构的每一步都考虑成本。
2. System that Last Align Cost to Business 使系统成本与业务保持一致
我们构建技术架构的目的是为了支持我们的业务，一定要确保你的收入来源与你的成本来源相一致。技术债务和经济债务一样，你必须偿还它。所以你必须考虑成本。
3. Architecting is a Series of Trade-offs 架构设计是一系列的权衡
架构设计总是一系列的权衡。而且它是非功能性需求和功能性需求之间的一系列权衡。
巴西Nubank公司工程高级总监Cat Swetel分享了Nubank如何调整技术重点以支撑业务的飞速增长，在巴西，Nubank拥有超过9000万客户，每两个成年人中就有一个是Nubank公司的客户，业务量的快速发展给系统带来了很大的压力。面临系统稳定性和成本冲突越来越大，该如何处理成本和稳定性之间的权衡？Swetel的答案是两者都要。Swetel认为大量成本的增加可能是由于为实现稳定而采用了错误的方法，很多时候只是投入了更多的机器更多的内存，而没有真正解决问题。在AWS的帮助下，Nubank通过升级到Z Garbage Collector垃圾回收算法来解决垃圾回收导致的系统不稳定，同时优化数据库缓存策略等方式最终实现了系统的问题，而稳定的系统最终实现了净成本的节约。稳定的系统就是高效的系统，成本趋于稳定并变得更加可预测，实现了成本和稳定性的双赢。
总结Bunak的经验，Alejandro说架构设计权衡的关键是对齐好优先级，而对齐优先级的前提是需要深刻的理解业务。
以上三个法则都是在设计阶段的经验，除了在设计阶段以外，我们还需要了解成本随着时间的推移发生了什么变化。
4. Unobserved Systems Lead to Unknown Costs 无法观测的系统将带来未知的成本
Alejandro博士分享了他的家乡阿姆斯特丹的一个故事，这是一个很有名的调查，在阿姆斯特丹，有些几乎一模一样的房子，但其中一些房子的能耗比另外一些少三分之一，那么这些房子的区别是什么呢？最后调查发现，耗能较多的房屋将电表安装在地下室，耗能较少的房屋将电表安装在走廊上，每次回家的时候你都可以看到你使用了多少能源，而这完全改变了人们的行为。
随着时间的推移，你的单位成本应该会下降，这样才会有规模经济，应该不断的Review分析架构来降低成本。所以首先需要定义你的计量器，并确保你的计量器包含成本和可持续性。
5. Cost Aware Architectures Implement Cost Controls 成本感知架构实现成本控制
你不能只依赖良好的意愿，你需要建立机制，因此你需要构建并随时掌握基于云的可调节（Tunable Architecture）架构。
服务的不同分层（tires）决定了取舍，有的层非常重要，必须确保可用，需要三个可用区来备份，而有的服务可能两个区就够用了，而对于有的层级，比如畅销书列表，即使离线5分钟（没更新）也不会对客户体验产生影响。因此要考虑不同类型服务的弹性，但要确保所有这些部分都是可控的。因此，首先必须确定你的服务层级（重要性等级），思考我的系统中哪些部分绝对需要保持可预测的性能正常运行。
6. Cost Optimization is Incremental 成本优化是循序渐进的
我们在很多限制下快速前进，我们所做的很多事情实际上是在较小的层面上进行修修补补，但是这些小的修补是非常重要的，因为事实证明相当于部分成本实际就花在了那些地方。要保持好奇心并持续探索。
7. Unchallenged Success Leads to Assumptions 一直成功会让人盲目自信
英语中，最危险的一句话是：我们一直都是这样做的。Alejandro博士认为开发构建成本和运行应用成程序相比微不足道。因此，一个架构师必须记住：你构建应用程序的方式、你使用的平台，以及所使用的编程语言都应该不断的去Review，以确定是否选择了正确的语言及工具。
Alejandro博士讲到，对比各种编程语言发现，Ruby和Python的耗时是C++和Rust的50倍以上，所以Amazon使用Rust来实现S3等重要服务。作为一个技术人员，生活在如此快速发展的世界，我们总是需要持续学习，我们总是需要推翻自己的信念，放下曾经的成功，开始思考实际成本，以及如何处理垃圾收集的复杂性。因此，需要改变你的信念。
03 总结和思考
Alejandro博士说成本意识是一门失传的艺术，我们必须重新掌握这门艺术，因为可持续性是一列向你驶来的货运列车，你无法逃离，也不应该逃离。Alejandro博士以他在亚马逊长期的学习和工作经验，对成本和可持续性的观察的总结思考，提出了俭约架构的七个核心法则，对我们的软件架构设计有非常好的借鉴参考价值。
我们需要主动的为自己设置一些限制，比如对成本、可持续性的考量，即使是自我强加的限制，也能激发创造力。因此，当下次我们面临“既要.....又要......”，不要抗拒，勇敢面对，终将收获我们自己的惊喜！
