转载

微服务与康威定律

（本文是对《 Building Microservices 》一书第10章的摘录）

康威定律

Melvin Conway于1968年发表的论文《 How Do Committees Invent 》指出：系统设计的结构必定复制设计该系统的组织的沟通结构。这一论断被称为“康威定律”。在《 Exploring the Duality Between Product and Organizational Architectures %201309%E2%80%93%201324_c5c2350e-013c-4065-a2f9-d95eb32177d5.pdf)》一文中，作者发现紧密耦合的组织（例如典型的商业产品公司，所有员工在同一地点工作，具有高度一致的愿景与目标）开发的软件倾向于较少模块化，而松散耦合的组织（例如分布式的开源社区）开发的软件则倾向于更加模块化、耦合较少。

当一支小型团队负责整个系统的设计与实现时，团队内部可以具有频繁的、细粒度的沟通。而随着团队变大、分布在不同地点甚至时区，协调变更成本急剧增加，紧跟着就有两种可能性：人们要么找到降低协作／沟通成本的办法，或是停止做变更。后者就会导致庞大、难以维护的代码库。最终，各个地点不得不选择各自专门处理的一部分工作，拥有一部分代码，并在团队之间形成更粗粒度的沟通机制。组织结构中的沟通路径会造就与之对应的粗粒度API，形成代码库各个大块之间的边界。

服务的边界应该围绕着约束上下文（ bounded context ）来画，正如我们希望团队结构与约束上下文保持一致。这样做有几方面的好处。首先，团队在一个约束上下文内更容易抓住领域概念；其次，一个约束上下文内的多个服务更可能彼此交互，因此系统设计和发布协作都得以简化；最后，交付团队与业务代表沟通时，团队只需与各自约束上下文中的一两个专家建立良好关系即可。

服务所有权

一般而言，每个服务属于一个团队，拥有这个服务的团队负责其所有修改。这个团队可以任意调整代码结构，只要这些修改不对服务的消费者造成破坏即可。在很多团队中，“所有权”延伸到了服务的各个方面，从需求来源直到软件的构建、部署和维护。由同一个团队负责开发、部署和维护会促使他们简化部署环节，而不是“写完代码扔过墙”。

有很多团队采用“共享服务所有权”的模式。这种模式并不理想，但有必要了解团队为什么做此选择。常见的理由包括：

难以拆分。《Building Microservices》一书的第5章提供了一些关于如何拆分服务的建议。也可以考虑把团队合并，从而使组织结构与软件架构匹配。
特性团队。比起传统的“按技术/职能划分团队”的IT组织结构，“一个团队端到端负责一个特性开发”的结构是一个进步。然而微服务环境下的团队结构可以再向前一步：如果业务领域、服务边界、团队结构三者能保持对齐，一个团队就能聚焦一组客户，以整体视角为这组客户提供服务。横切多个业务领域的修改固然会发生，但可能性会降低很多。
交付瓶颈。有几个办法可以应对交付瓶颈而不必共享服务所有权。第一个办法就是等待，各个服务不一定要以同样的节奏发布，遇到交付瓶颈的服务可以稍后再发布。另外，也可以直接向有交付困难的团队中加人。横跨整个组织的技术栈越标准，临时加人的效果就会越好。当然，另一方面，标准化的技术栈也可能给团队造成束缚。

内部开源

通常的开源项目组织方式可以用在企业内部：一个代码库由一组受信任的提交者（核心团队）管理，并接受未获信任的提交者（外围团队）提交的修改。开源项目以这种方式来保障代码质量和一致性。大多数开源项目在第一个核心版本成型之前倾向于不接受外来的提交。当服务变得成熟且稳定，便可以更放心地开放接受贡献。

分布式版本控制工具允许任何人提交pull request，这是很重要的能力。取决于组织的规模，内部开源体系可能需要考虑借助代码评审工具来讨论和评估是否接受pull request。同时，类似于github提供的pull request评论功能也很有用。最后，需要让提交者很容易构建和部署整个软件，通常这需要定义良好的构建和部署流水线，以及集中管理的构建产物仓库。

案例：REA

REA的服务由“小队”（squad）拥有，小队负责服务的整个生命周期，包括构建、测试、发布、支持、直到下线。一支交付服务团队给这些小队提供建议和指导，以及必要的工具支持。REA有着强烈的自动化文化，并大量使用AWS使团队更具自主性。

不仅交付团队与业务经营对齐，软件架构也是一样。以服务集成为例：在一条业务线内部，所有服务可以用任何方式自由交流，小队自己可以做决定；然而在业务线之间，所有交流必须以异步批处理的形式发生，这是中央架构团队规定的很少几条“铁律”之一。粗粒度的系统集成与业务线之间已有的粗粒度交流相匹配。

人

为了对齐业务经营，组织结构和软件架构都需要改变。变革的阻力真实存在：从大一统的系统转到微服务，对于习惯了单一编程语言、不用考虑运维问题的开发者而言是一次痛苦的觉醒；习惯了把软件“丢过墙”的程序员突然发现没有别人可以推诿责任，可能会很不习惯自己对所有工作负责；如果要让开发者承担7*24在线支持工作，甚至可能有劳动合同上的阻碍。变革推动者需要理解员工的喜恶，顺势而为，不能急于求成。

原文 http://gigix.thoughtworkers.org/2016/8/9/micro-services-conways-law/

正文到此结束