《可扩展的艺术》内容回顾与作者采访

《可扩展的艺术，现代企业的Web​架构、流程及组织》第二版，作者：Martin L. Abbott and Michael T. Fisher，是一本关于扩张中的企业组织采用web 扩展来增长他们的产品和服务的书。也谈及了技术和架构的实现，以及处理扩展也要上升到组织的结构。目的是为读者展现如何组织技术、人和流程来达到良性循环的目的，以及持续改进的方法，从而实现可扩展性。

近期发行的第二版新增了来自Apple、Spotify 等公司等实际案例，还挑选了第一版发行以来被认为是至关重要的一些主题，InfqQ 就这些内容采访了作者。

InfoQ: 可扩展性看起来是个技术问题。你是怎么想到通过组织这样一个角度来写这本书的？

我们在 8 年半之前创建公司的起初时间也是这么想的。当时我们只是想帮助一些公司在技术／产品架构上的事情。但是一次又一次的经历后，我们发现虽然在产品架构内会表现出一些扩展的限制的症状，但是组织和流程的性质也是引起的原因。因此之后，我们就开始专注于组织、流程和架构，将问题扼杀于萌芽之中。

InfoQ: 那么谁应该将本书的阅读放在首要位置，IT 专家还是 IT 管理者？

我们认为本书是为诸如专注于产品的工程师、工程管理人员、工程执行人员，以及产品经理、产品管理人员而写的。此书的其中一个前提就是工程师需要有业务知识，经理和管理人员要有产品／技术知识。本书聚焦于那些要创建最好的产品的人们－能够同时理解业务开发和产品开发并能从中找到有价值的内容。

InfoQ: 在书中您谈到了人是一个可扩展系统的重要部分，你能在这里阐述下这个观点吗？

我们经常开玩笑的说机器人给我的启示正如电影“终结者”那样，但是它目前还没有那么的先进。因此，人仍然是定义产品的不二选择，那么或明或暗的表明人是有局限的。因此，人才是扩展方程中最为重要的部分。

InfoQ: 对于可扩展来说除了人之外三个最重要的方面是什么？为什么会这样呢？

• 流程：根据你的公司的成熟度选择合适的流程。流程太多就会扼杀创新，太少又会带来灾难。适当的流程会是导轨的形式，能够有助于产品计划在正常的道路上行进，哪怕是在我们人类有着犯错的毛病。
• 架构：特别的架构可以确保能够回答它是如何做到伸缩的以及是如何失败的问题的？而后者则是我们经常忽略的问题。我们通常是为了“正常工作”而设计－而不是为了“失效”时设计。但是如果我们不能够理解失效是如何发生的话，那么失效就是不可预测的。
• 组织结构和所有权：建设一支能够相互配合、完全拥有自主服务的团队，他们不仅会创建出高水平的可扩展性，还会有高水平的创新能力。

InfoQ: 伸缩云的广泛使用不是已经由云供应商为我们解决了可扩展的的问题了吗？

这是一个常见而又危险的误解。伸缩云通过“按需使用”来扩大我们的解决方案，从而能够降低成本，缩短上市时间。但他们不会为我们的扩展性提供解决方案的架构，也不会让我们的应用更加的高可用。他们能够做到：增加更多的服务器、更多的资源－是可以的；解决方案能够让成功率更高、更加容易的切分独立组件－做不到。

InfoQ: 考虑到这些方面, 改变一个组织的规模是一个系统性的努力, 这些改变从哪儿开始?

在顶层－－基于管理、共享以及相关利益者的批准。不进行改变这种规模就永远不会成功，除非是团队全部成员都同意作出改变。

InfoQ: 企业目前不仅在寻找一个可扩展的架构，还同时要求大幅缩短上市时间，对于此同时实现这二者你有什么方法上的建议？

读我们的书：），必须认真－我们所提供的解决方案很多都是为了帮助公司的扩展和缩短上市的时间。举例来说，服务的开发，我们帮助团队从原来的架构无缝迁移到组件的分离架构，假设该团队在各自的服务中没有冲突的话，就减少了开发的摩擦，理所当然的上市时间就短了。

InfoQ: 在书中您也提及了关于 ITIL 和 DevOps，如果你认为他们的方法对于敏捷来讲是站在对立面的，那么可扩展最适合配合什么方法？

是也不是。将 ITIL 和 ITSM 引入到可扩展中有其表现强大的一面，比如问题和事件管理分离的概念。如果过度的采用的话（参考上面的流程），它就会带来负面的效果。但是，从概念的角度来讲，他们的想法在这些领域不仅是强大的还是必要的。讲 ITIL 流程引入到 DevOps 是绝对可能的。我们认为是他们在其它领域将之设为了对立，其实我们认为 DevOps 的态度在任何地方都较适用。举例来说，从流程管理的角度看待日常工作（构建一台服务器等等），我们对于 ITIL 的流程并不待见。

书中的主要观点

本书从人员、流程、架构设计的角度探讨了可扩展性。

人员：书的第一部分是对管理进行了简短的介绍。作者在这里特别强调了人力资源的重要性，合适的人在合适的时间做着合适的工作，并能够在扩展中作出正确的行动。作者还在这里给出了具体的建议：

• 他们建议对于组织结构以下几点要谨记在心：
  • 额外的工作单元可添加到组织的容易程度。
  • 衡量组织成功的容易程度以及随时间推移的独立贡献。
  • 如何将目标轻松的分配以及归到某个组，而且这个组是否有授权来实现这个目标。
  • 如何处理组内部或其之间的冲突，看其是对公司的任务有帮助还是拦路虎。
  • 什么样的结构能够有助于创新和减少上市时间。
  • 怎样的组织结构会降低每单位创造价值的成本。
  • 如何组织工作流最轻松。
• 小团队很明显无法提供足够的资源来实现业务的优先级，团队过大又会造成生产率低下和士气低落，所以建议每个团队有 6 到 15 人较为合适。
• 你的项目管理时间的 5% 是用来创建项目计划的细节，其余的 95％的时间是处理哪些突发事件。
• 在适当的时间范围内要集中到实现的结果，而不是去迎合初始规划时的活动。
• 可扩展性指标应包括可用性测量、响应时间、工程的生产力、效率、成本以及质量。
• 计算宕机和服务中断时间的成本，是创造专注于可扩展性的企业文化所必需的。
• 技术人员须担起将可扩展性的举措的一些术语能够让非技术人员理解的责任。

流程：作者描述了 ITIL 和 CMMI，但是还是有必要在流程和组织之间找到适合的团队，为了避免文化冲突和政治腐败，作者建议团队自行决定自己的流程。

作为一个实例，作者还引用了容量规划和总体计算：“对于各种各样的组件知道你的总体非常重要，因为你需要得知这个信息来做财务预算、雇佣计划、发布计划、以及可扩展项目的优先级。对于系统内部的每个主要组件都要做计算，诸如每个应用服务池、网络设备、带宽使用、以及数据库服务器等。”作者还建议任何组件规划都不要超过容量规划的 50%。取决于组件的类型这个数字可以增长到 60%，但他们认为一个计划是 75％的话绝对是最大值了。

架构：这里是作者总结的 15 条最佳应该采用的架构设计：

1. N＋1 的设计，永远不要让任何服务少于 2 个，而且三个应铭记在心。
2. 为回滚做设计，确保你可以回滚到功能的任何版本。
3. 设计可禁用，随时可以关掉你发布的任何东西。
4. 设计可监控，在设计的阶段就要考虑监控，而不是在设计完成之后再考虑。
5. 要设计为多个活动的站点，不要将自己困在一站式的解决方案的框中。
6. 使用成熟的技术。使用你知道的东西更好。
7. 异步设计。仅在绝对必要的情况下使用同步通信。
8. 无状态系统。仅在业务返回可证明时才使用有状态的系统。
9. 横向扩展，而不是纵向。永远不要依赖更大、更快的系统。
10. 设计用于至少两面。要在扩展的需要之前提前考虑下一步。
11. 购买非核心的程序。如果你并不擅长构建它们，而且它们并不能够做到竞争的差异，那就购买它们。
12. 硬件的购买，多数时候便宜的更好。
13. 小步构建、小步发布、快速失败。一切都以小为美，快速迭代，跟上增长的公司步伐。
14. 错误隔离。实践故障隔离设计、实现断路器让故障缩小到最小范围。
15. 自动化要高于人为。让一切都自动化，永远不要依赖一个机器可以完成而让人去做的事。

在本书的第一版中就推出了 AKF Scale Cube，这是一个分析和解决扩展问题的三维模型，它们是：

• X 轴表示是实体的克隆，或是数据的克隆，工作负载会在它们之间平等的分配。这往往是实施成本最低的，但会受到指令长度和数据单元的约束。
• Y 轴表示通过活动或数据来分离工作负载。这要比 X 轴的实施成本稍高，但是解决了指令长度和数据单元的问题，另外还能做到故障隔离。
• Z 轴表示通过哪些正在执行工作的请求或人来分离工作负载。这是三者之中实施成本最高的，但是是最能提供高扩展性的。它解决了数据单元大小的相关问题，虽然不一定能够解决指令长度的问题。它也用于全球分布式的服务。

AKF 的 Scale Cube 曾是 NGINX 介绍微服务一文中所采用的例子。

关于作者

Martin L. Abbott，增长与扩展咨询公司 AKF 的联合创始人，他曾是 Quigo 的首席运营官，Quigo 是一家广告技术的创业公司，在 Quigo 他主要负责产品的策略、产品管理、技术开发以及客户服务。Marty 曾经在 eBay 干了六年，头衔有高级技术副总裁、首席技术官、以及执行团队成员。而他再加入 eBay 之前，Marty 在 Gateway 和摩托罗拉做过很多国内和国际的工程、管理和行政岗位。他也曾服务过几个私人和上市公司的董事会。Marty 拥有美国军事学院的计算机科学学士学位，并在佛罗里达大学获得计算机工程硕士学位，也在哈佛商学院高管教育项目修习过，并获得凯斯西储大学的管理学博士。

Michael T. Fisher，增长与扩展咨询公司 AKF 的联合创始人，Michael 曾是 Quigo 的首席技术官，而 Quigo 是 2007 年被 AOL 所收购的一家做广告技术的创业公司。在加入 Quigo 之前，Michael 是 eBay 的子公司 PayPal 负责工程和架构的副总裁。在 PayPal 之前，Michael 曾在通用电气 (General Electric) 待了 7 年，负责帮助开发公司的技术战略，并在哪里获得了六西格玛黑带大师。Michael 在美国陆军服役 6 年，做过飞行员和队长。他在凯斯西储大学韦瑟管理学院获得了博士学位和工商管理硕士学位，在夏威夷大学获得信息系统硕士学位，也是美国陆军军官学校 (西点军校) 的计算机科学学士，Michael 也是凯斯西储大学韦瑟管理学院的设计和创新部门的副教授。

查看英文原文： Book review and Q&A: The Art of Scalility

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。