《架构与未来》摘要（三）
《确立架构原则》（特别推荐）
1、目标和原则
目标树的主题是：在降低成本基础上创造更多的盈利机会和更大的收入。这一主题可以进一步分解为：质量（体现在错误率和故障级别、测试覆盖率等）、可用性（服务的可用时间，SLA）、成本（软硬件投入、团队规模等）、市场响应时间（体现在SLA、发布时效性、自动化水平）、效率（需求迭代与人员投入时间比、自动化水平等）
理想情况下，架构原则将基于高层次的目标树主题，而不是具体的目标。目标可能会随着时间的推移而改变，因此，原则应该广泛地支持未来的和当前的目标。
架构原则非常抽象，以至于实际上无法直接应用在设计和架构审查上，无法协助驱动性价比高、可扩展性好和高可用的架构。同样，在本质上原则是高高在上的，在实践中，常常为了便于或者其他的原因把这些原则置之不理。
一个经常被提到，高高在上的不幸的架构原则是“无限可扩展”。无限可扩展是根本无法实现的，因为那将需要无限的成本。此外，这原则不允许验证。没有不是架构可以满足定义的目标。最后，我们必须考虑架构原则在指导组织工作习惯中的作用。在理想情况下，原则应该有助于设计，并指出一条通往成功的道路。像“无限设计”这样高高在上的理想原则不提供通往目的地的地图，使其作为一个无用的指南。
好的架构原则：
原则应该影响团队的行为和文化。它们应该帮助指导设计，并以此测试和确定这些设计是否符合公司的目标和需求。有效的架构原则和公司的目标、愿景和使命紧密地结合在一起。一个好的原则有以下几个特点：
1）具体的：原则不应该被混淆在它的措辞中。
2）可度量的：原则不应该包含“无限”这样的词汇。
3）可达到的：尽管原则应该是鼓舞人心的，它们应该能够在设计和执行上实现。
4）现实的：团队应该有能力达成目标，有些原则是可以实现的，但是需要时间和天赋。
5）可测试的：修改后的原则可以用于测试设计，以验证它是否符合需要。
2、架构选择
我们把维恩图减少到三个区域：可用性/可扩展性/质量，成本/效率，TTM（市场响应时间）
逐步孵化的原则：你希望团队能够拥有指导可扩展性项目的架构原则。达成此目的最好的方式是让他们参与原则的制订和选择。一个好的制订原则过程涉及下述步骤。
1）确保所有参与方应用这些原则。
2）通过将这些原则与公司的愿景、任务和目标关联，创建一个成功的因果图。
3）为原则拟定主题，维恩图对显示重叠的原则很有用。
4）把大团队分成小团队，然后由每个小团队分别提出他们的原则。虽然所提出的原则可能措辞不同，但是你会惊讶有这么多重叠原则出现。
5）把团队集合起来做个小型展示，然后再分成小团队来修改他们的原则。
6）进行另一轮的陈述，然后选择那些重叠的原则。
7）进行投票。
在架构原则制定的过程中一定要应用RASCI方法，因为你不希望团队认为没有最终的决策者。如果在制定架构原则的过程中只有架构师参与，而没有包括关键的团队成员，那么可能会形成“象牙塔”架构文化，工程师认为架构师没有适当的掌握客户的需求，架构师认为工程师不拥有和不遵循架构标准。
3、AKF采用的最普遍的架构原则
1）N+1设计：
简单来说，这个原则所要表达的是要确保任何你所开发的系统在发生故障时，至少有一个冗余的实例。该原则广泛地应用在从大型数据中心设计到网络服务实施的一系列活动中。（避免单点问题）
2）回滚设计：
回滚设计是提供网络、WEB 2.0或者SaaS服务公司的一个重要架构原则。无论你构建什么，都要确保它可以向后兼容。通过预先的设计允许产品或者平台回滚、发布或部署。（系统设计时，考虑回滚与兼容）
3）禁用设计：
当设计系统，特别是与其他系统或者服务通讯的高风险系统系统时，要确保这些系统能够通过开关来禁用。这将为修复带来额外的时间，确保系统不因为错误引起的诡异需求而宕机。（比如流量控制、安全限制等）
4）监控设计：
如果监控做得好，不仅能够发现服务的死活，检查日志文件，还能够收集系统相关的数据，评估终端用户的响应时间。如果系统和应用在设计和构建时就考虑好监控，那么即使不能自我修复，也至少可以自我诊断。如果系统在设计时做好监控和日志收集，那么很容易确定系统的预留空间，并采取适当的行为尽早纠正可扩展性问题。（面向监控设计）
5）设计多活数据中心
6）使用成熟的技术：
我们都喜欢学习和实施最新和最有吸引人的技术。采用这样的技术通常可以帮助我们降低成本、减少上市时间、降低开发成本、提高可扩展能力、减少终端用户的响应时间。在许多情况下，新技术甚至可以创造一个短暂的竞争优势。不幸的是，新技术也往往有较高的故障率。因此，如果应用在架构的关键部分，可能会导致对可用性有显著的影响。如果可用性对解决方案或服务很重要，那就要应该采可靠的技术。
7）异步设计：
同步系统比那些异步行为设计的系统具有较高的故障率。此外，同步系统的可扩展性被在通信链中最慢的和最不具备可扩展性的系统所限制。如果系统或服务减慢，整个链条的速度减慢，吞吐量降低。因此，同步系统更难以实现实时扩展。
在处理一个请求时，有一个服务在等待响应。虽然吞吐量大致相同，但它们更能容忍慢速处理，因为可以继续处理请求。在某些情况下，反应可能会有所减缓，但是真个系统不会停顿下来。因此，如果只有一个周期性的缓慢，异步系统将允许交易缓慢通过而不是停止整个系统。
8）无状态系统：
状态系统中的操作都是在前后关联的情况下进行的。因此，对任何给定的执行或系列的请求，其过去的操作信息必须要暂时存储在某个地方。在维持交易状态的情况下，工程团队通常开始收集并保存大量有关请求的信息。状态消耗资金、处理能力、可用性和可扩展性。
只要有可能，就要避免开发需要状态的产品。在必要的情况下，可以考虑存储在用户端，而不是系统里（cookie，agent）。如果这是不可能的，考虑一个集中的状态缓存机制避免把状态数据分散存储在多个服务器上。
9）水平扩展非垂直升级：
如果你想达到近乎无限的扩展，那么就必须分散系统、组织和流程以利于扩展。
其中一些面临着与试图依靠更大、更快的系统相关的扩展性危机。所有那些不做水平扩展，而做垂直升级的人都面临这些危机。
10）设计至少要有两个步骤的前瞻性：
领导者、管理者和架构师都要考虑未来。你的设计不只是为了今天，而是要搭建一个可以使用和修改的未来系统。
11）非核心则购买：
虽然非核心则购买是一个成本效益原则，它也影响扩展性、可用性以及生产力。基本的前提是，无论你和你的团队是多么聪明，你不可能什么事情都做得最好。此外，股东希望你能关注真正创造差异化竞争，进而提高股东价值的事情。做你真正擅长的事情，形成产品、平台或系统方面的显著差异。
12）小构建、小发布，快试错：
小版本的失败率较低，因为失败率和解决方案中的变更数量直接相关。对染我们可以而且应该目标远大，但是我们必须要有原则，迫使我们聚焦在以小型和迭代的方式实施。（MVP，最小可用产品）
13）故障隔离：
故障隔离的原则类似于建立一个有断路器的电气系统。细分你的产品、服务或子系统，确保服务或者子服务不会影响其他的服务。另外，把客户分入不同的组里，如果系统出现任何问题，不至于影响到全体客户。（服务隔离，泳道）
14）自动化：
我们认为所有系统都应该在开始设计的阶段就要考虑自动化。自动化部署、构建、测试、监控甚至报警。（程序设计之初，考虑到自动化部署、测试、监控，非常重要）
--第十二章《确立架构原则》