在古代的狼人传说中，只有用银质子弹（银弹）才能制服这些异常凶残的怪兽。在软件开发活动中，“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。 软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。从IT技术的发展历程来看，先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是，这些 方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点：我们可以通过诸多方式去接近“银弹”，但很遗憾，软件活动中没有“银弹”。 布鲁克斯发表《人月神话》三十年后，又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计，架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得，对 这个平衡点的把握，就是架构设计中的取舍问题。而这种决策大部分是靠技术，但是一定程度上也依赖于架构师的“艺术”，技术可以依靠新工具、方法论、管理模式去提升，但是“艺术”无法量化 ，是一种权衡。 软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论，软件架构是一种对软件的“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进 度、质量得到有效控制。但是，一个成功的软件设计是要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现 新问题，解决新问题，没有所谓的“一招鲜”。 以上只是针对设计领域的银弹讨论，放眼到软件全生命周期，银弹问题会更加突出。 小到一个软件开发团队，大到一个行业，没有银弹，但是“行业最佳实践”可以作为指路明灯。 —— 公号-Java大后端

目的

上世纪四十年代之前, 开发软件使用的"机器语言", 是直接使用0 1来进行编写指令与数据的, 四十年代之后, 出现了汇编语言, 用短小的单词如mov来表示指令, 大大加强了代码的可读性, 减少了编程的复杂度, 但是编写一个如加减乘除的实现依然很困难, 于是, 上世纪五十年代, 高级语言出现了, 如LISP, Cobol等, 这些就是现代常用编程语言的雏形。

可以看出, 编程语言的进化史, 就是化繁为简, 由复杂到简单。同理, 架构设计的目的, 也是一样的, 随着模块, 组件的越来越多, 系统的复杂性也会增加, 而架构设计的主要目的, 就是为了解决软件系统复杂度带来的问题。

准则

• 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
• 架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
• 理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。
• 如果系统的复杂度不是在性能这部分，TPS再高也没什么用。
• 别人的架构是为了解决别人的问题，并不是所有软件的用户量都是某宝那么大。
• 没有万能的软件，比如Docker只是为了解决资源重用和动态分配而设计的，如果系统复杂度根本不是在这方面，引入Docker没有什么意义。

复杂度的来源

高性能

软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

• 单台计算机
• 多台计算机

高可用

定义: 系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

CAP定理: 存储高可用不可能同时满足“一致性、可用性、分区容错性”，最多满足其中两个。

• 高可用状态决策