转载

Apache 的架构师们遵循的 30 条设计原则&软件架构的10个常见模式

架构之道：如何设计出灵活、高可用性以及能够快速适应变化的系统架构？

什么是道，什么是术？道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大路通罗马，罗马是道，大路是术。道为本，术为途，如果事先知道罗马在哪里，那么遍地是路，路路相通。架构也是如此，如果能领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型、架构境界等。

架构的本质

任何系统，自然情况下，都是从有序到无序，这是有科学依据的，按照热力学第二定律，自然界的一切自发过程都有方向性，一个孤立系统会由有序变为无序，即它的熵会不断增加，最终寂灭。但生物可以通过和外界交互，主动进行新陈代谢，制造 “负熵” 来保证自身有序，继续生存。

同样，一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。

架构的本质就是对系统进行有序化重构，不断减少系统的 “熵”，使系统不断进化。

那架构是如何实现无序到有序的呢？基本的手段就是分和合，先把系统打散，然后重新组合。

在首席架构师眼里，架构的本质是……分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，第一步的拆分更难。

拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。

架构师的能力要求包括：

兼具技术的广度（多领域知识）和深度（技术前瞻）

兼具思维的高度（抽象思维）和深度（问题到本质）

兼具感性（沟通）和理性（平衡）

架构师的境界

架构师从境界上由浅到深可以分为四层：第一看山不是山，第二看山是山，第三看山不是山，第四看山是山。

在首席架构师眼里，架构的本质是……刚接手项目时，对业务不了解，时时被业务方冒出的术语弄得一愣一愣的，如果把现有问题比作山，则是横看成岭侧成峰，根本摸不透，此时看山不是山。

经过业务梳理和对系统深入了解，可以设计出一个屌丝的方案，把各个系统串起来，解决当前的问题，对当前这个山能够看清楚全貌，此时能够做到看山是山。

通过进一步抽象，发现问题的本质，原来这个问题是共性的，后续还会有很多类似问题。设计上进行总结和升华，得出一个通用的方案，不光能解决当前的问题，还可以解决潜在的问题。此时看到的已经是问题本质，看山不是山。

最后回到问题本身，去除过度的抽象，给出的设计简洁明了，增之一分嫌肥，减之一分嫌瘦，既解决当前问题，又保留最基本的扩展，此时问题还是那个问题，山还是那个山。

第一境界给不出合适方案，不表。

第二境界的方案只解决表面问题，往往设计不够，碰到其它类似问题或者问题稍微变形，系统需要重新做。

第三境界的方案往往过度设计，太追求通用化会创造出过多抽象，生造概念，理解和实现均困难，此时系统的无序度反而增加，过犹不及。

第四境界的方案，在了解问题本质的基础上，同时考虑现状，评估未来，不多做，不少做。

佛教讲空和色，色即事物现象，空即事物本质，从这个意义上说，第一重境界无色无空，第二重境界过色，第三重境界过空，第四重境界站在色和空之间，既色又空，不执着于当前，不虚无于未来。

不空不色，既空既色，道法自然，本性如来，架构之髓也。

软件架构介绍

架构定义：

软件架构不仅仅注重软件本身的结构和行为, 还注重其他特性:使用, 功能性, 性能, 弹性, 重用, 可理解性, 经济和技术的限制及权衡。

软件架构的目标：

可延伸性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展；

可维护性（Maintainable）。软件系统的维护包括两方面：

1、排除现有的错误；

2、将新的软件需求反映到现有系统中去，一个易于维护的系统可以有效地降低技术支持的花费。

客户体验（Customer Experience）。软件系统必须易于使用。

市场时机（Time to Market）。软件用户

软件逻辑架构：

逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等

软件物理架构：

物理架构：软件元件是怎样放到硬件上的？

Apache 的架构师们遵循的 30 条设计原则

Apache 的架构师们遵循的 30 条设计原则&软件架构的10个常见模式

基本原则

原则 1： KISS(Keep it simple,sutpid) 和保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。

原则 2： YAGNI(You aren’t gonna need it)- 不要去搞一些不需要的东西，需要的时候再搞吧。

原则 3：爬，走，跑。换句话说就是先保证跑通，然后再优化变得更好，然后继续优化让其变得伟大。迭代着去做事情，敏捷开发的思路。对于每个功能点，创建里程碑（最大两周），然后去迭代。

原则 4：创建稳定、高质量的产品的唯一方法就是自动化测试。所有的都可以自动化，当你设计时，不妨想想这一点。

原则 5：时刻要想投入产出比（ROI）。就是划得来不。

原则 6：了解你的用户，然后基于此来平衡你需要做哪些事情。不要花了几个月时间做了一个 devops 用户界面，最后你发现那些人只喜欢命令行。此原则是原则 5 的一个具体表现。

原则 7：设计和测试一个功能得尽可能的独立。当你做设计时，应该想想这一条。从长远来看这能给你解决很多问题，否则你的功能只能等待系统其他所有的功能都就绪了才能测试，这显然很不好。有了这个原则，你的版本将会更加的顺畅。

原则 8：不要搞花哨的。我们都喜欢高端炫酷的设计。最后我们搞了很多功能和解决方案到我们的架构中，然后这些东西根本不会被用到。

功能选择

原则 9：不可能预测到用户将会如何使用我们的产品。所以要拥抱 MVP（Minimal Viable Product），最小可运行版本。这个观点主要思想就是你挑几个很少的使用场景，然后把它搞出来，然后发布上线让用户使用，然后基于体验和用户反馈再决定下一步要做什么。

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

（小编点评：产品经理可能是听不进去的，最好采取数据度量说话…）

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

原则 12：有时候你要有勇气和客户说不。这时候你需要找到一个更好的解决方案来去解决。记住亨利福特曾经说过的：”如果我问人们他们需要什么，他们会说我需要一匹速度更快的马”。记住：你是那个专家，你要去引导和领导。要去做正确的事情，而不是流行的事情。最终用户会感谢你为他们提供了汽车。

服务端设计和并发

原则 13：要知道一个 server 是如何运行的，从硬件到操作系统，直到编程语言。优化 IO 调用的数量是你通往最好架构的首选之路。

原则 14：要了解 Amdhal 同步定律。在线程之间共享可变数据会让你的程序变慢。只在必要的时候才去使用并发的数据结构，只在必须使用同步（synchronization）的时候才去使用同步。如果要用锁，也要确保尽可能少的时间去 hold 住锁。如果要在加锁后做一些事情，要确保自己在锁内会做哪些事情。

原则 15：如果你的设计是一个无阻塞且事件驱动的架构，那么千万不要阻塞线程或者在这些线程中做一些 IO 操作，如果你做了，你的系统会慢的像骡子一样。

分布式系统

原则 16：无状态的系统的是可扩展的和直接的。任何时候都要考虑这一点，不要搞个不可扩展的，有状态的东东出来，这是起码的。

原则 17：保证消息只被传递一次，不管失败，这很难，除非你要在客户端和服务端都做控制。试着让你的系统更轻便（使用原则 18）。你要知道大部分的承诺 exactly-once-delivery 的系统都是做了精简的。

原则 18：实现一个操作尽可能的幂等。这样的话就比较好恢复，而且你还处于至少一次传递（at least once delivery）的状态。

原则 19：知道 CAP 理论。可扩展的事务（分布式事务）是很难的。如果可能的的话，尽可能的使用补偿机制。RDBMS 事务是无法扩展的。

原则 20：分布式一致性无法扩展，也无法进行组通信，也无法进行集群范围内的可靠通信。理想情况下最大的节点限制为 8 个节点。

原则 21：在分布式系统中，你永远无法避免延迟和失败。

用户体验

原则 22：要了解你的用户和清楚他们的目标。他们是新手、专家还是偶然的用户？他们了解计算机科学的程度。极客喜欢扩展点，开发者喜欢示例和脚本，而普通人则喜欢 UI。

原则 23：最好的产品是不需要产品手册的。

原则 24：当你无法在两个选择中做决定的时候，请不要直接把这个问题通过提供配置选项的方式传递给用户。这样只能让用户更加的发懵。如果连你这个专家都无法选择的情况下，交给一个比你了解的还少的人这样合适吗？最好的做法的是每次都找到一个可行的选项；次好的做法是自动的给出选项，第三好的做法是增加一个配置参数，然后设置一个合理的默认值。

原则 25：总是要为配置设置一个合理的默认值。

原则 26：设计不良的配置会造成一些困扰。应该总是为配置提供一些示例值。

原则 27：配置值必须是用户能够理解和直接填写的。比如：不能让用户填写最大缓存条目的数量，而是应该让用户填写可被用于缓存的最大内存。

原则 28：如果输入了未知的配置要抛出错误。永远不要悄悄的忽略。悄悄的忽略配置错误往往是找 bug 花了数小时的罪魁祸首。

艰难的问题

原则 29：梦想着新的编程语言就会变得简单和明了，但往往要想真正掌握会很难。不要轻易的去换编程语言。

原则 30：复杂的拖拉拽的界面是艰难的，不要去尝试这样的效果，除非你准备好了 10 人年的团队。

最后，说一个我的感受。在一个理想的世界里，一个平台应该是有多个正交组件组成 - 每个组件都负责一个方面（比如，security，messaging，registry，mdidation，analytics）。好像一个系统构建成这样才是完美的。但不幸的是，现实中我们很难达到这样的状态。因为在项目初始状态时，很多事情是不确定的，你无法做到这样的独立性，现在我更倾向于在开始的时候适当的重复是必要的，当你尝试铲除他们的时候，你会发现引入了新的复杂性，分布本身就意味着复杂。有时候治愈的过程要比疾病本身更加的糟糕。

总结

作为一个架构师，应该像园丁一般，更多的是修剪花草，除草而不是去定义和构建，你应该策划而不是指挥，你应该去修剪而不是去定义，应该是讨论而不是贴标签。虽然在短期内可能会觉得也没什么，但从长远看，指导团队找到自己的方式会带来好处。如果你稍不留神，就很容易让架构成为一个空洞的词汇。比如设计者会说他的架构是错误的，但不知道为什么是错误的。一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。