《微服务设计》第 10 章　康威定律和系统设计

第 10 章　康威定律和系统设计

• 梅尔 · 康威于 1968 年 4 月 在 Datamation 杂志上发表了一篇名为“How Do Committees Invent”的论文，文中指出：任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。这句话被称为康威定律

10.1　证据

10.1.1　松耦合组织和紧耦合组织

• 在 Exploring the Duality Between Product and Organizational Architectures 一书中，作者 Alan MacCormack、John Rusnak 和 Carliss Baldwin 研究了大量不同的软件系统，把创建这些系统的组织大致分为松耦合组织和紧耦合组织。紧耦合组织的一个例子是商业产品公司，他们的员工都在一起工作，并有着一致的愿景和目标；而松耦合组织的典型代表是分布式开源社区
• 在研究中，通过匹配不同类型组织中比较相似的产品，他们发现，组织的耦合度越低，其创建的系统的模块化就越好，耦合也越低；组织的耦合度越高，其创建的系统的模块化也越差

10.1.2　Windows Vista

• 微软对它的一个特定产品 Windows Vista进行了实证研究（ http:// research. microsoft. com/ pubs/ 70535/ tr-2008-11. pdf），观察其自身组织结构如何影响软件质量。从统计数据可以看出，与组织结构相关联的指标和软件质量的相关度最高

10. 2 　 Netflix和 Amazon

• Amazon也相信，小团队会比大团队的工作更有效。于是产生了著名的“两个比萨团队”，即没有一个团队应该大到两个比萨不够吃
• Netflix从这个例子中学到了很多，因此从一开始，它就确保其本身是由多个小而独立的团队组成，以保证他们创建的服务也能独立于彼此。这确保了系统的架构可以快速地优化

10. 3 　我们可以做什么

• 这些证据、轶事和经验表明，组织结构对系统的性质和质量确实有着深刻的影响。让我们看看几种不同的组织情况，了解每种情况对我们的系统设计可能产生的影响

10. 4 　适应沟通途径

• 服务的内部是大量细粒度的方法或函数调用。正如之前所讨论的，我们希望通过服务拆分，使得服务内变化的频度要远远高于服务间变化的频度。这个有着细粒度沟通能力的团队，能够与服务内部频繁讨论代码这个需求很好地匹配
• 当协调变化的成本增加后，有一件事情会发生：人们要么想方设法降低协调 /沟通成本，要么停止更改。而后者正是导致我们最终产生庞大的、难以维护的代码库的原因
• 如果构建系统的组织更加松耦合（例如，由异地的团队组成），其所构建的系统则倾向于更加模块化，因此耦合度也越低。一个拥有许多服务的单个团队对其管理的服务会倾向于更紧密地集成，而这种方式在分布式组织中是很难维护的

10. 5 　服务所有权

• 对于许多团队而言，所有权延伸到服务的方方面面，从应用程序的需求、构建、部署到运维。这种模式在微服务的世界尤为普遍，一个小团队更容易负责一个小服务。所有权程度的增加会提高自治和交付速度。团队需要自己负责部署和维护应用程序，这会激励团队创建出易于部署的服务；

10. 6 　共享服务的原因

10. 6. 1 　难以分割

• 很显然，拆分服务的成本太高是多个团队负责单个服务的原因之一，你的组织或许看不到这一点。这常见于大型的单块系统中。你也可以考虑将团队合并在一起，以更紧密地匹配架构本身

10. 6. 2 　特性团队

• 特性团队（即基于特性开发的团队）的想法，是一个小团队负责开发一系列特性需要的所有功能，即使这些功能需要跨越组件（甚至服务）的边界
• 大范围地采用特性团队后，所有服务都是共享的。每个人都可以改变任意一个服务，任意一段代码
• 让我们再考虑一下什么是微服务：服务会根据业务领域，而不是技术进行建模。如果负责某个微服务的团队与业务领域相匹配，则它更容易保持对客户的关注，也更容易进行以特性为导向的开发，因为它对服务相关的所有技术有一个全面的了解并且拥有所有权

10. 6. 3 　交付瓶颈

• 如果某个服务突然出现了大量的变更需求怎么办？
• 不共享服务，我们有几种方式来应对这种情况。第一种方式就是等待
• 另一种方式是，你可以派人到产品目录团队帮助他们更快地工作
• 另一个选择是，把产品目录拆分成一般音乐目录和铃声目录两个服务
• 不过，还有另一种模式可以很好地工作

10. 7 　内部开源

• 标准的开源项目中，一小部分人被认为是核心提交者，他们是代码的守护者。如果你想修改一个开源项目，要么让一个提交者帮你修改，要么你自己修改，然后提交给他们一个 pull请求。核心的提交者对代码库负责，他们是代码库的所有者

10. 10 　案例研究：RealEstate. com. au

• REA的核心业务是房地产，但包含多个不同的方面，每一方面都是一条业务线（ Line Of Business， LOB）
• 每条业务线团队，负责自己创建的服务的整个生命周期，包括构建、测试、发布和运维，甚至弃用。一个核心交付服务团队，为这些团队提供建议、指导和工具来帮助他们完成工作。浓厚的自动化文化非常关键， REA大量使用 AWS，关键原因是想让团队更加自治

• 这些组织的系统架构和组织结构对变化都有着很好的适应性，这能够产生巨大的效益，因为这样的组织改进了团队的自治性，并且能够加快新需求和新功能的发布速度。很多组织都意识到，系统架构并非凭空产生的， REA是其中之一

10. 12 　人

• “不管一开始看起来什么样，它永远是人的问题。”——杰拉尔德 ·温伯格，咨询第二定律
• 每个组织都有自己的节奏。了解你的员工能够承受的变化，不要逼他们改变太快！也许在短时间内，你仍然需要一个单独的团队来处理线上支持或生产环境部署，以便给开发人员足够的时间调整到新的实践中

10. 13 　小结

• 康威定律强调了试图让系统设计跟组织结构不匹配所导致的危险。这引导我们试图将服务所有权与同地团队相匹配，而两者本身与组织限界上下文是匹配的