基本原则
原则一：价值为王
解析：
价值为王的另一种说法叫做YAGNI。YAGNI 是 You aren’t gonna need it 的缩写。该原则的基本含义就是，不应该开发任何当前不使用的功能。因为这些占用开发成本的功能，可能根本没有人用。而且不仅仅是开发成本打了水漂，你还要不断投入维护成本，来保证这些无人使用的功能可以正常运行。
要了解阿姆达尔定律，它告诉我们，我们不可能无限制的提升系统某一部分的效率。要提升的总体效果有没有产生相应的价值。
原则二：以终为始
解析：
以终为始是一种思维模式，最早出自《黄帝内经》，先人是在告诫后人要在人生的春天就认真思考人生终点的意义和价值。其引申义有三：一是凡事要有目标；二是凡事要有计划；三是凡事要有原则。正所谓“凡事预则立，不预则废”。
白话来说，以终为始，就是在做事之前，先想想结果是什么样子的，这个结果是否能达到最初的目标。小心X-Y问题：为了解决 X问题，觉得用 Y 可以解，于是研究 Y 问题，结果搞到最后，发现原来要解决的 X 问题。
原则三：分治原则
解析：
做架构时不要想着一次性把所有的功能都做好，要拥抱 MVP（Minimal Viable Product），最小可运行版本。先让程序完成最基本功能上线，根据反馈调整和决定下一步的迭代。
迭代着去做事情，敏捷开发的思路。对于每个功能点，创建里程碑，然后去迭代。
原则四：服务自治
解析：
在系统设计时，要考虑服务上线后，对于问题要自感知、自修复、自优化、自运维及自安全。
原则五：拥抱变化
解析：
重视架构扩展性和可运维性。无状态的系统的是可扩展的和直接的。任何时候都要考虑这一点，不要搞个不可扩展的，有状态的东东出来。否则，一旦需要改变，成本很高。
原则六：简单即正义
解析：
简单即正义的另一种说法叫做KISS。KISS(Keep it simple,sutpid)保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。
原则七：尽量自动化
解析：
人力成本既慢又贵，还有经常不断的人工失误。如果不能降低人力成本，反而需要更多的人，那么这个架构设计一定是失败的。
稳定性原则
原则八：依赖最简
解释：
依赖原则是去除依赖、弱化依赖、控制依赖。多一个依赖多一分风险。能不依赖则不依赖，能异步弱依赖不要同步强依赖。实在不能弱依赖的，比如必须要调用加密存储来获取数据库的密码，不然无法连接数据库，可以控制获取密码在服务启动时进行，如果获取不到则服务启动失败，因为现在都是集群部署，一台无法启动不影响整体提供服务。
原则九：不作不死
解释：
尽可能的做较少的功能。当有疑问的时候，就不要去做，甚至干掉。很多功能从来不会被使用。最多留个扩展点就够了。
等到有人提出再说（除非是影响核心流程，否则就等到需要的时候再去做）。
原则十：容灾容错
解析：
Everything fails! 人都是要死的，机器都是要坏的。如果一件事情有可能发生则在生产环境中一定会发生，架构中要做好容错设计。
原则十一：用成熟的技术
解析：
不要给别人的技术当小白鼠，不要因技术本身的问题影响系统的稳定。尽可能的使用红利大的主流技术，而不要自己发明轮子，更不要魔改。在技术选型上，千万不要被——“你看某个公司也在用这个技术”，或是一些在论坛上看到的一些程序员吐槽技术的观点（没有任何的数据，只有自己的喜好）来决定自己的技术，还是看看主流大多数公司实际在用的技术栈，会更靠谱一些。
总结
一张图总结今天的内容：
编程一生
因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。
PDCA方法论，检查自己是否错过更新：每周三晚上8点左右，我都会更新文章，如果你没有收到，记得点开【编程一生】公众号找一下(*^▽^*)