来自 Craig Larman 的软件设计书《UML 和模式应用》，Larman 在书中提出软件设计的关键任务是职责分配，并提炼总结出 9 种 (5 种核心 +4 种扩展) 软件职责分配模式，这些模式是比 GoF 设计模式更抽象的元模式。
为对象分配职责的通用原则 – 把职责分配给拥有足够信息可以履行职责的专家
将创建 A 的职责赋给 B，如果至少下面一种情况为真：
B“包含”或者聚合 A
B 记录 A 的实例
B 密切地使用 A
B 拥有 A 的初始化数据
赋予职责使得对象间的耦合度尽可能低，最小化对象间的依赖和变更影响，最大化重用。
赋予职责使得每个对象的职责尽可能保持聚焦和单一，易于管理和理解。
把职责赋予系统、设备或者子系统的表示类 (门面控制器)，或者某个用例的表示类 (用例控制器)，让控制器接收事件并协调整个系统的运作。
将职责分配给多个具有同名方法的多态子类，运行时根据需要动态切换子类，让系统行为变得可插拔。
针对真实问题域中不存在，但是设计建模中有用的概念，设计虚构类并赋予职责。
在两个或者多个对象间有交互的情况下，为避免直接耦合，提高重用性，创建中间类并赋予职责，对象的交互交由中间类协调。
简单讲就是封装变化。识别系统中可能的不稳定或者变化，在不稳定组件上创建稳定的抽象接口，将可能的变化封装在接口之后，使得系统内部的不稳定或者变化不会对系统的其它部分产生不良影响。
S.O.L.I.D 是面向对象设计和编程 (OOD&OOP) 中几个重要原则的首字母缩写，受 Robert Martin 推崇。
修改某个类的理由应该只有一个，如果超过一个，说明类承担不止一个职责，要视情况拆分。
软件实体应该对扩展开放，对修改封闭。一般不要直接修改类库源码（即使你有源代码），通过继承等方式扩展。
当一个子类的实例能够被替换成任何超类的实例时，它们之间才是真正的 is-a 关系。
高层模块不应该依赖于底层模块，二者都应该依赖于抽象。换句话说，依赖于抽象，不要依赖于具体实现。比方说，你不会把电器电源线焊死在室内电源接口处，而是用标准的插头插在标准的插座 (抽象) 上。
不要强迫用户去依赖它们不使用的接口。换句话说，使用多个专门的接口比使用单一的大而全接口要好。
这 15 个架构原则来自《架构即未来 (The Art of Scalability)》 一书，作者马丁 L. 阿伯特和迈克尔 T. 费舍尔分别是 eBay 和 PayPal 的前 CTO，他们经历过 eBay 和 PayPal 大规模分布式电商平台的架构演进，在一线实战经验的基础上总结并提炼出 15 条架构原则：
永远不要少于两个，通常为三个。比方说无状态的 Web/API 一般部署至少>=2 个。
确保系统可以回滚到以前发布过的任何版本。可以通过发布系统保留历史版本，或者代码中引入动态开关切换机制 (Feature Switch)。
能够关闭任何发布的功能。新功能隐藏在动态开关机制 (Feature Switch) 后面，可以按需一键打开，如发现问题随时关闭禁用。
在设计阶段就必须考虑监控，而不是在实施完毕之后补充。例如在需求阶段就要考虑关键指标监控项，这就是度量驱动开发 (Metrics Driven Development) 的理念。
不要被一个数据中心的解决方案把自己限制住。当然也要考虑成本和公司规模发展阶段。
只用确实好用的技术。商业组织毕竟不是研究机构，技术要落地实用，成熟的技术一般坑都被踩平了，新技术在完全成熟前一般需要踩坑躺坑。
能异步尽量用异步，只有当绝对必要或者无法异步时，才使用同步调用。
尽可能无状态，只有当业务确实需要，才使用状态。无状态系统易于扩展，有状态系统不易扩展且状态复杂时更易出错。
永远不要依赖更大、更快的系统。一般公司成长到一定阶段普遍经历过买更大、更快系统的阶段，即使淘宝当年也买小型机扛流量，后来扛不住才体会这样做不 scalable，所以才有后来的去 IOE 行动。
在扩展性问题发生前考虑好下一步的行动计划。架构师的价值就体现在这里，架构设计对于流量的增长要有提前量。
如果不是你最擅长，也提供不了差异化的竞争优势则直接购买。避免 Not Invented Here 症状，避免凡事都要重造轮子，毕竟达成业务目标才是重点。
在大多数情况下，便宜的就是最好的。这点和第 9 点是一致的，通过商品化硬件水平扩展，而不是买更大、更快的系统。
全部研发要小构建，不断迭代，让系统不断成长。这个和微服务理念一致。
实现故障隔离设计，通过断路保护避免故障传播和交叉影响。通过舱壁泳道等机制隔离失败单元 (Failure Unit)，一个单元的失败不至影响其它单元的正常工作。
设计和构建自动化的过程。如果机器可以做，就不要依赖于人。自动化是 DevOps 的基础。
这 15 条架构原则基本上是 eBay 在发展，经历过流量数量级增长冲击过程中，通过不断踩坑踩出来的，是干货中的干货。消化吸收这 15 条原则，基本可保系统架构不会有原则性问题。
这 15 条原则同样适用于现在的微服务架构。eBay 发展较早，它内部其实很早 (差不多 2010 年前) 就已形成完善的微服务生态，只是没有提出微服务这个概念。
这 15 条原则可根据 TTM(Time To Market)，可用性 可扩展性 质量，成本 效率分布在三个环内，如下图所示。
在 2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出了著名的 CAP 猜想，而后，在经过两年的努力，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了此猜想，从而使 CAP 理论正式成为了分布式计算领域的公认定理。
CAP 理论强调，在分布式系统中，最多只能同时满足一致性 (Consistency)、可用性 (Availability) 和分区容忍性 (Partition Tolerance) 中的两项。其中:
一致性指所有节点在同一时间点看到的数据完全一致
可用性则指 reads 和 writes 操作始终成功和响应时间正常
分区容忍性则指分布式系统能够在遭遇到某节点或网络分区故障时，仍然能够对外提供满足一致
eBay 架构师 Dan Pritchett 凭借其丰富的实践经验，在 ACM 上发表了一篇文章，并提出了 BASE 理论，作为对 CAP 理论的一种延伸。其核心思想是：尽管无法做到强一致性（即 CAP 理论中的一致性概念），但是通过采用适当的方式可以实现最终一致性。BASE 代表基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventual Consistency）。
1.基本可用 (Basically Available)
基本可用是指分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。比如服务降级。
2.软状态 (Soft State)
软状态是指允许系统存在中间状态，而该中间状态不会影响系统的整体可用性。分布式存储中一般一份数据至少存三个副本，允许不同节点间副本同步的延迟就是软状态的体现。
3.最终一致性 (Eventual Consistency)
最终一致性是指系统中的所有数据副本经过一段时间后，最终能够达成一致状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
CAP 和 BASE 理论课题极深，背后甚至涉及到很复杂的数学证明。但我从简单浅显的角度来理解：在分布式系统中，性能、高可用、不丢数据和数据一致性通常是强需求。由于流量不断增长，数据复制和分区成为了不可避免的挑战：
复制（replication）：数据在多个节点上存储多份，以确保数据不丢失且系统保持高可用；
分区（partition）：数据按照某种规则切分分发到不同节点上，以降低单个节点的负载并提高系统性能，例如数据库的分库分表、系统拆分成微服务等，这种做法也会带来一些一致性问题。为了解决一致性问题，我们可以在时间上做出一定的妥协，即实现最终一致性。如果要求时间上的强一致性，就必须适当地牺牲可用性。因此，在系统架构设计上，与状态一致性的斗争是其中一个重要组成部分。
当选择使用分布式产品时，比如 NoSQL 数据库，必须了解它在 CAP 环章除的位置，以确保它可以满足特定场景的需求。
Melvin Conway 在 1967 年提出所谓康威法则，指出组织架构和系统架构之间有一种隐含的映射关系：
Organization which design system […] are constrained to produce designs which are copies of the communication structures of these organization. 设计系统的组织其产生的设计等价于组织间的沟通结构。
康威法则也可以倒过来阐述：
Conway’s law reversed：You won’t be able to successfully establish an efficient organization structure that is not supported by your system design(architecture)。如果系统架构不支持，你无法建立一个高效的组织；同样，如果你的组织架构不支持，你也无法建立一个高效的系统架构。
IT 运维管理畅销书《凤凰项目》 的作者 Gene Kim 在调研了众多高效能 IT 组织后总结出支撑 DevOps 运作的三个原理 (The Three Ways: The Principles Underpinning DevOps)，我认为也是系统改进提升的一般性原理，见下图：
原理一：系统思考 (System Thinking)
对于以开发为导向的组织而言，他们的能力已不仅仅只是生产软件，更重要的是持续地向客户传递价值。该价值从业务需求开始，依次经过研发、测试、部署、运维等流程，并最终以服务形式交付给客户。整个价值链的流速并不只依赖于单个团队或个人的杰出贡献，而是由整个价值链中最薄弱环节的限制而决定。所以，局部优化通常并不管用，反而还可能会损害整体效率。Gene Kim还特别强调："瓶颈之外的所有优化只是幻象"。
原理二：强化反馈环 (Amplify Feedback Loops)
通过加强反馈机制实现流程改进是非常常见的方法。原则二着重于加强企业与客户、组织团队、流程和系统内部的反馈环路。如果没有测量，则无法实现提升，只有通过测量数据反馈来优化和改进系统。
原理三：持续试验和学习的文化 (Culture of Continual Experimentation And Learning)
新企业管理文化鼓励进行勇于尝试和不断实验、学习、改进的文化氛围。
尽管上述原则对架构师而言具有深远的指导意义，但在实际工作中，根据业务、时间、资源和团队情况灵活应用它们才能收到更好的效果。这些原则并非僵化的规则，有时候甚至会被违反，不过要注意，这样的做法通常都有相应的成本，架构师需要在意并及时变通以弥补成本带来的损失。
作者|易安
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。