重视架构扩展性和可运维性。无状态的系统的是可扩展的和直接的。任何时候都要考虑这一点，不要搞个不可扩展的，有状态的东东出来。否则，一旦需要改变，成本很高。

原则六：简单即正义

解析：

简单即正义的另一种说法叫做KISS。KISS(Keep it simple,sutpid)保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。

原则七：尽量自动化

解析：

人力成本既慢又贵，还有经常不断的人工失误。如果不能降低人力成本，反而需要更多的人，那么这个架构设计一定是失败的。

稳定性原则

原则八：依赖最简

解释：

依赖原则是去除依赖、弱化依赖、控制依赖。多一个依赖多一分风险。能不依赖则不依赖，能异步弱依赖不要同步强依赖。实在不能弱依赖的，比如必须要调用加密存储来获取数据库的密码，不然无法连接数据库，可以控制获取密码在服务启动时进行，如果获取不到则服务启动失败，因为现在都是集群部署，一台无法启动不影响整体提供服务。

原则九：不作不死

解释：

尽可能的做较少的功能。当有疑问的时候，就不要去做，甚至干掉。很多功能从来不会被使用。最多留个扩展点就够了。

等到有人提出再说（除非是影响核心流程，否则就等到需要的时候再去做）。

原则十：容灾容错

解析：

Everything fails! 人都是要死的，机器都是要坏的。如果一件事情有可能发生则在生产环境中一定会发生，架构中要做好容错设计。

原则十一：用成熟的技术

解析：

不要给别人的技术当小白鼠，不要因技术本身的问题影响系统的稳定。尽可能的使用红利大的主流技术，而不要自己发明轮子，更不要魔改。在技术选型上，千万不要被——“你看某个公司也在用这个技术”，或是一些在论坛上看到的一些程序员吐槽技术的观点（没有任何的数据，只有自己的喜好）来决定自己的技术，还是看看主流大多数公司实际在用的技术栈，会更靠谱一些。

总结

一张图总结今天的内容：