《架构真经》随心摘要备忘

规则一：避免过度设计

内容：在设计中要警惕复杂的解决方案

场景：适用于任何项目，而且应在所有大型或者复杂系统或项目的设计过程中使用。

用法：通过测试同事是否能够轻松地理解解决方案，来验证是否存在过度设计。

原因：复杂的解决方案实施成本过高，而且长期的维护费用昂贵。

要点：过于复杂的系统限制了扩展性。简单的系统易于维护、易于扩展而且成本低。

 

    正如维基百科中解释的那样，过度设计有两大类：第一类指产品的设计和实施超过了实际的需求。第二类值所完成的产品过于复杂。

 

    第二类过度设计是指把一件事情做的过于复杂和以复杂的方式去完成一个任务。简单地说，它包括让某些事物超过实际需要过度工作，让用户花费不必要的精力去完成一件事，让工程师付出很大的努力去理解不必要的需求。

 

    过度设计是可扩展性的大敌之一，设计一个超过实际需要的方案就是浪费时间和金钱。更进一步说，这种方案会浪费系统的处理资源，增加系统扩展的成本，限制系统的整体可用性。构建过于复杂的解决方案与此相似。过度工作的系统会增加成本并限制平台最终的规模，那些让用户费很多精力的系统，会在增加用户数量和快速开展业务时遇到瓶颈。复杂到难以理解的系统会扼杀组织的生产力，加大工程师团队扩大的难度，也提高了为系统增加新功能的难度。

 

规则二：方案中包括扩展

内容“提供及时可扩展性的DID方法。

场景：所有项目通用，是保证可扩展性的最经济有效的方法。

用法：

    --Design（D）设计20倍的容量    （智力成本高、资产成本低）

    --Implement（I）实施3倍的容量    （工程成本高）

    --Deploy（D）部署1.5倍的容量    （智力成本低，资产成本高）

原因：DID为产品扩展提供了经济、有效、及时的方法。

要点：在早期考虑可扩展性可以帮助团队节省时间和金钱。在需求发生大约一个月前实施（写代码），在客户蜂拥而至的几天前部署。

 

    （个人理解：D--功能特性的架构设计方案应该支持20倍的容量，这要求设计方案应该具有更高的可扩展性和前瞻能力；I--技术实施、代码实现层面应该支撑3倍的容量，技术实施受制于组件选择、特性权衡、实施成本、时间效益等制约，可能无法满足理想的容量设计，但是容量支撑能力上应该在3倍以上；D--部署层面，涉及到物理层实施，通常需要一定的时间成本，比如机器准备，网络扩容等，我们在部署实施时，应该至少满足1.5倍的容量）

 

规则三：三次简化方案

内容：在设计复杂系统时，从项目的范围、设计和实施角度简化方案。

场景：当设计复杂系统或者产品时，面临着技术和计算资源的限制。

用法：

    --代用帕累托（Pareto）原则简化范围。

    --考虑成本优化和扩展性来简化设计。

    --依赖其他人的经验来简化部署。

原因：只聚焦“不过度复杂”，并不能解决需求或历史发展与沿革中的各种问题。

要点：在产品研发的各个阶段都需要做好简化。

 

    如何简化方案范围？不断地应用帕累托原则（80-20原则，八二原则）。收益的80%来自于20%的工作？在保持大多数好处的前提下，思考如何减少不必要的功能。

    如果简化方案设计？简化设计与过度设计的复杂性密切相关。消除复杂性相当于工作中忽略无关紧要的活动，简化就是寻找一条捷径。简化设计的方法表明，首先要看本地，像内存这样的信息共享资源中是否已经有了数据请求。消除复杂性涉及做更少的工作，而简化设计涉及更快和更容易地完成工作。简单来说，简化设计的步骤要求易于理解、低成本、高效益和可扩展的方式完成工作。

    如何简化方案实施？....这些问题的答案都指向一个共同的主题：“如何利用其他经验和已经存在的解决方案来简化方案实施？”。因为不可能在每件事情上都做到最好，所以我们应该首先寻找被广泛采用的开源或第三方解决方案来满足需求。如果那些都不存在，那么我们应该看看组织内部是否有人已经准备了可扩展的解决方案来解决问题。在没有专有解决方案的情况下，我们应该再从外部看看是否有人已经描述了一种可以合法复制或模仿的可扩展方案。只有无法在这三项中找到合适的选择情况下，我们才会开始尝试自己创建解决方案。最简单的实时几乎总是那些有过实施经历并通过实践证明了的可扩展方案。

 

AKF扩展立方体

规则七：X轴扩展

内容：通常叫水平扩展，通过复制服务或数据库以分散事务处理带来的负载。

场景：

    --数据库读写比很高（> 5:1）

    --事务增长超过数据增长的系统。

用法：

    --克隆服务的同时配置负载均衡器。

    --确保使用数据库的代码清楚读和写的区别。

原因：以复制数据和功能为代价获得事务的快速扩展。

要点：X轴拆分实施速度快，研发成本低，事务处理扩展效果好。然而，从运维角度来看，数据的运营成本比较高。

 

    X轴拆分不仅仅可以应用于数据库。通常可以很容易的克隆网络服务器和应用服务器。这种克隆允许事务在系统之间均匀地分布以实现水平扩展。

 

规则八：Y轴拆分

内容：有时也称为服务或者资源扩展，本规则聚焦在沿着动词（服务）或名字（资源）的边界拆分数据集、交易和技术团队。

场景：

    --数据之间的关系不是那么必要的大型数据集。

    --需要专业化技术资源的大型复杂系统。

用法：

    --用动词来拆分动作，用名词拆分资源，或者两者混用。

    --沿着动词/名词定义的边界拆分服务和数据。

原因：不仅允许事务极其相关的大型数据集有效扩展，也支持团队的有效扩展。

要点：Y轴或者面向数据/服务的拆分允许事务和大型数据集的有效扩展，有益于故障隔离。Y轴拆分也有助于减少团队之间的非必要沟通。

 

规则九：Z轴拆分

内容：经常根据客户的独特属性（例如ID、姓名、地理位置等）进行拆分。

场景：非常大而且类似的数据集，如庞大而且增长快速的客户群，或者当响应时间对在地理上广泛分布的客户变得很重要的时候。

用法：根据所知道的客户端属性（例如ID、名，地址位置或设备）对数据和服务进行拆分。

原因：客户的快速增长拆过了其他形式的数据增长，或者在扩展时，需要在某些客户群之间进行必要的故障隔离。

要点：Z轴拆分对扩大客户基数的效果明显，也用在其他那些无法使用Y轴拆分的大型数据集上。

 

    此规则，通常被称为分片。

 

    总结：

    1）通过克隆扩展：通过克隆或服务数据和服务是你很容易地扩展事务。

    2）通过拆分不同的东西来扩展：通过名词或动词标识来拆分数据和服务。如果正确完成，可以有效的扩展事务和数据集。

    3）通过拆分类似的东西来扩展：通常是客户数据集，依据客户属性拆分客户数据，形成独特和隔离的数据分片或者泳道，以实现事务和数据的扩展。

 

规则十：向外扩展

内容：向外扩展是通过复制或拆分服务或数据库二分散事务负载的方法，与此相对的是向上扩展，即通过购买更大的硬件二实现的扩展。

场景：任何预计会迅速增长或想追求低成本高收益的系统、服务或数据库。

用法：用AKF扩展立方体因地制宜确定正确的拆分方法，通常最简单的是水平拆分。

原因：以复制数据和功能为代价实现事务的快速扩展。

要点：让系统向外扩展，为成功铺好路。期待能向上扩展，结果却发现自己跑得越来越快，已经无法再购买到更快和更大的系统，千万不要掉进这个陷阱。

 

 

规则十一：用商品化系统（金鱼而非汗血宝马）

    让我们解释一下为什么这些东西称之为“金鱼”。因为这些系统（组件）比较便宜，如果它们“死掉”，你可能会比较轻松地丢弃它们，而不是投入大量的时间来修复。另一方面，“汗血宝马”代表了相当大量的投资，因此需要时间来维护和修复。最后，我们更喜欢有很多的小朋友，而不是几个大朋友。

 

先利其器

    “工具法则”即马斯洛的锤子。“当你只有一个锤子时，任何东西看起来都像是个钉子”。该法则至少包含以下两个重要含义。

    第一个含义，我们都有一种试图使用自己熟悉的仪器或工具来解决当前问题的倾向。

    第二个含义其实是建立在第一个含义的基础上，在我们的组织内，如果持续引进有类似技能的人来解决问题或实施新产品，我们很可能会用类似的工具和第三方产品得到一致的答案。该方法的问题是，虽然它有一致性好和可预测性高的有点，但是它却很可能会驱动我们去使用对完成任务来说不适合或不理想的工具或解决方案。

    “我们已经看到了Paas、缓存和NoSQL数据解决方案以及高效的大数据工具和基础设施，一波接着一波地发展。这些新工具以现代方法解决问题，远比旧工具更有效。不幸的是，许多公司缺乏实验和采用这些新技术的勇气，结果导致工具被锁定和过度使用。这种过度使用基础设施工具的情况在许多公司都很常见。一个快速增长和快速发展的公司，在完成重要业务目标过程中，没有办法投入大量时间或没有能力去更多的风险时可以理解的。意外，引进新工具就不会再去努力改善现有的工具。这可能会把公司引上一条永远巩固核心基础设施、从不实验和寻找更好工具的绝路，而这些新工具有很可能会更优雅和高效的解决问题，并打来更好的结果”。

    “至关重要的是，每个公司都要避免陷入创新者的困境。虽然一部分研发资源需要去做关键项目使现有的工具更好，但是总是要拿出一部分资源来主动分析、试验和采用新工具。拥有核心工具的团队也是采用新进步和新技术创新的团队，这一点很重要。这将使一个公司能够引领、创新和有成本效益的解决问题，使用合适的工具来解决合适的问题，并将使公司从长远来看更加成功。”

 

前车之鉴

    长期研究的结果表明：从失败而不是成功中能学习到更多的东西。但是，只有营造开发和诚实沟通的环境，同事辅以能帮助我们反复从错误和失败中吸取教训的轻量级过程，才能真正地从失败中吸取教训。若隐藏失败，结果必然是反复失败，不如努力营造把分享失败作为最贱时间反模式的环境。要想成功，我们需要观察客户并把每次失败当成一个吸取教训的机会来积极学习，适当地依靠像QA这样的组织，预期系统失败，并针对这些失败做好充分的准备。

 

    查尔斯.佩罗的正常事故理论，假设现代耦合系统所固有的复杂性使事故不可避免。（备注：复杂系统的概率性事故认为是一种正常表现）

    托德.拉波特提出了高可靠性组织理论，他认为即使在没有事故的情况下组织也可以学习，并以组织战略来实现更高的可靠性。尽管这些理论存在不一致性，但是它们有一些共性元素。首先经常失败的组织往往有更好的学习和成长机会，当然假设他们能够抓住机会并从中学习，在团队没有其他办法的情况下，系统不会增长和改善。（任何人不要刻意“以身试法”、通过经历试错和付出代价来获得经验）

 

重中之重

 

    通过增加可扩展性，我们希望降低规范程度。（即规范与业务适配度之间，可以平衡。）

 

意犹未尽

    “你提供的是服务，而非软件”。（这要求架构师，在看待技术架构输出时，我们需要以“服务方式”而非“单纯的软件组件”，用户或者接入团队更希望可靠的使用架构产出“服务”，而不是随手扔出一个“仅供参考”的文档或者部署一套软件组件，我们需要尽力围绕“用户需求”本身，在构建软件的基础之上，提供诸如监控、自动化、最佳实践等服务策略，并持续跟进。）

 

谋定而动

 

    对可用性和可扩展性方面的关注代表了我们的风险观。因无法扩展而导致的风险事件表现为对服务质量或可用性的威胁。计算风险的方法是，用某个问题发生的概率乘以它假如发生而产生的影响。

    “优先级公式”：“风险降低” 、成本、结果利益，三方面权衡。