到目前为止，本书大部分的内容集中在向细粒度架构迈进时所面临的技术挑战。但除此之 外，我们也需要考虑组织方面的问题。在这一章，我们将了解到忽略公司的组织结构会带 来什么样的危险。
我们的行业还很年轻，它似乎在不断地重塑自己。不过，一些关键定律还是经受住了时间 的考验。例如摩尔定律，它表示集成电路上可容纳的晶体管数目每两年会增加一倍。该定 律已经被证明准确得惊人（尽管有人预测，这种趋势已经放缓）。还有一条定律，我发现 几乎普遍适用，在我的日常工作中也更有用，那就是康威定律。
梅尔•康威于1%8年4月在Datamation杂志上发表了一篇名为“How Do Committees Invent”的论文，文中指出：
任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上 都与该组织的沟通结构保持一致，
这句话被称为康威定律，经常以各种形式被引述。埃里克*S.雷蒙德在《新黑客字典》 中总结这一现象时指出：“如果你有四个小组开发一个编译器，那你会得到一个四步编译器。”
论被证实，但你不必相信我的话。自从康威的论文提交以来，人们在这一领域进行了大量 的研究，探讨组织结构和他们创建的系统之间的关系。
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-ll.pdf),观察其自身组织结构如何影响软件质量。具体而言，研究者 通过查看多种因素来确定系统中什么样的组件容易出错。涉及的指标包括代码复杂度等 常用的软件质量指标。从统计数据可以看出，与组织结构相关联的指标和软件质量的相关 度最高。
关于组织结构如何影响其创建的系统，还有另一个例子。
10.2 Netflix 和 Amazon
组织和架构应该一致，信奉这个理念的两个典范是Amazon和Netflix。在早期，Amazon 就开始理解了，团队对他们所管理系统的整个生命周期负责的好处。它想要团队共同拥有 和运营其创建的系统，并管理整个生命周期。Amazon也相信，小团队会比大团队的工作 更有效。于是产生了著名的“两个比萨团队”，即没有一个团队应该大到两个比萨不够吃。 帮助小团队对服务的整个生命周期负责，是驱动Amazon开发AWS的一个主要原因。团 队需要一些工具来自助式地获取相应的计算资源等。
Netflix从这个例子中学到了很多，因此从一开始，它就确保其本身是由多个小而独立的团 队组成，以保证他们创建的服务也能独立于彼此。这确保了系统的架构可以快速地优化。 实际上，Netflix为了想要的系统架构，才设计了这样的组织结构。
10.3我们可以做什么
这些证据、轶事和经验表明，组织结构对系统的性质和质量确实有着深刻的影响。这个理 解对我们有什么帮助？让我们看看几种不同的组织情况，了解每种情况对我们的系统设计 可能产生的影响。
10.4适应沟通途径
让我们首先单独考虑一个简单的团队。它负责系统设计与实现的各个方面。团队内可以进 行频繁的、细粒度的沟通。想象一下，由这样的团队负责一个单一的服务，比如音乐商店 的产品目录服务。服务的内部是大量细粒度的方法或函数调用。正如之前所讨论的，我们 希望通过服务拆分，使得服务内变化的频度要远远高于服务间变化的频度。这个有着细粒 度沟通能力的团队，能够与服务内部频繁讨论代码这个需求很好地匹配。
这个团队发现，关于更改和重构的讨论更容易进行，而且团队成员通常都很有责任感。
现在让我们来想象一个不同的场景。拥有我们产品目录服务的，不再是一个单一的、物理 位置上在一起的团队，而是英国和印度的团队都在积极参与对服务的更改，也就是对服务 拥有共向所有权。这里的地域和时区界限，使得团队之间非常难于进行细粒度的沟通。相 反，他们依靠更多的粗粒度的沟通，比如视频会议和电子邮件。这种情况下，一个英国的 团队成员，想要充满信心地去做一个简单的重构有多困难？异地分布式团队的沟通成本较 高，因此协调变化的成本也比较高。
当协调变化的成本增加后，有一件事情会发生：人们要么想方设法降低协调/沟通成本， 要么停止更改。而后者正是导致我们最终产生庞大的、难以维护的代码库的原因。
我记得曾参与过一个客户的项目，分处异地的两个团队共享单个服务的所有权。最终，每 个团队开始处理专门的工作。这允许团队至少对代码库的一部分负责，从而更容易地修改 代码。接着，团队间会有更多关干如何集成两部分代码的粗粒度的沟通；最终，与组织结 构内的沟通途径匹配所形成的粗粒度API，形成了代码库中两部分之间的边界。
那么，在考虑服务如何演化设计方面，这个例子给了我们什么样的启示呢？我认为，参与 创建系统的开发人员之间存在地理位置差异，是一个应该对服务进行分解的很明显的信 号，一般来说，你应该分配单个服务的所有权给可以保持低成本变化的团队。（也就是在一起办公的团队）
也许你的公司决定，在另一个国家新开一间办公室，通过这种方式来增加项目的人数。这 个时候，积极思考系统的哪部分可以移交给新团队。也许适应沟通途径这种方式，能够驱 动你做出将某个接缝拆分出去的决定。
还有一点值得一提，至少基于之前引用的Exploring the Duality Between Product and Organizational Architectures 的作者的观察，如果构建系统的组织更加松耦合（例如，由异 地的团队组成）（由不同的团队负责不同的微服务），其所构建的系统则倾向于更加模块化，因此耦合度也越低。一个拥有许 多服务的单个团队对其管理的服务会倾向于更紧密地集成，而这种方式在分布式组织中是 很难维护的。
10.5服务所有权
服务所有权是什么意思呢？ 一般来说，它意味着拥有服务的团队负责对该服务进行更改。 只要更改不破坏服务的消费者，团队就可以随时重新组织代码。对于许多团队而言，所有 权延伸到服务的方方面面，从应用程序的需求、构建、部署到运维。这种模式在微服务的 世界尤为普遍，一个小团队更容易负责一个小服务。所有权程度的增加会提髙自治和交付 速度。团队需要自己负责部署和维护应用程序，这会激励团队创建出易于部署的服务；也 就是说，当没有人能够接受你扔出去的东西时，也就不用担心人们会犯“把东西扔出墙” 这种错误了！
当然我很喜欢这种模式。它把决定权交给最合适的人，赋予团队更多的权力和自治，也使 其对工作更负责。我见过太多太多的开发人员，把系统移交给测试或部署阶段后，就认为 他们的工作已经完成了。
10.6共享服务的原因
我见过很多团队采用共享服务所有权的模式。不过我发现这种方式效果不佳，原因之前已 经讨论过。然而，理解人们为何选用共享服务的原因是很重要的，尤其是当我们能够找到 一些令人信服的替代模式，来解决人们潜在的担忧时。
10.6.1难以分割
很显然，拆分服务的成本太高是多个团队负责单个服务的原因之一，你的组织或许看不到 这一点。这常见于大型的单块系统中。如果这是你所面临的主要挑战，那么我希望第5章 的一些建议可以帮到你。你也可以考虑将团队合并在一起，以更紧密地匹配架构本身。
10.6.2特性团队
特性团队（即基于特性开发的团队）的想法，是一个小团队负责开发一系列特性需要的所 有功能，即使这些功能需要跨越组件（甚至服务）的边界。特性团队的目标很合理。这种 结构促使团队保持关注在最终的结果上，并确保工作是集成起来的，避免了跨多个不同的 团队试图协调变化的挑战。
在许多情况下，特性团队是对传统的IT组织中，团队结构围绕技术边界进行组织的一种修正。例如，你可能有一个团队专门负责用户界面，另一个团队负责应用程序逻辑，第三 个团队负责处理数据库。这种环境下，特性团队迈出了一大步，它跨越所有层提供完整的 功能。
大范围地采用特性团队后，所有服务都是共享的。每个人都可以改变任意一个服务，任意 一段代码。在这种情况下，服务守护者的角色如果还存在的话，会变得复杂得多。不幸的 是，采用这种模式后我很少看到守护者，这会导致我们前面讨论的种种问题。
但是，让我们再考虑一下什么是微服务：服务会根据业务领域，而不是技术进行建模。 如果负责某个微服务的团队与业务领域相匹配，则它更容易保持对客户的关注，也更容 易进行以特性为导向的开发，因为它对服务相关的所有技术有一个全面的了解并且拥有 所有权。
当然，也会出现横跨多个服务的特性，但由于我们避免技术导向的团队，这种可能性会大 大降低。
10.6.3交付瓶颈
共享服务的另一个关键原因是，这样做可以避免交付瓶颈。如果某个服务突然出现了大量 的变更需求怎么办？想象一下，我们要推出一个功能，让客户能够在所有的产品中看到单 个音轨的风格，以及添加一个全新类型的铃声：手机的虚拟音乐铃声。网站团队需要改变 界面样式的信息，而移动应用程序团队需要让用户能够浏览、预览和购买铃声。这两个需 求都需要更改产品目录服务，但不幸的是，团队的一半成员感染了流感，而另一半被困在 了生产环境上的故障诊断中。
不共享服务，我们有几种方式来应对这种情况。第一种方式就是等待。网站和移动应用程 序团队转而开发别的功能。取决于特性的重要性和延迟的时长，这可能是个好的主意，但 也可能是一个糟糕的想法。
另一种方式是，你可以派人到产品目录团队帮助他们更快地工作。你的系统使用越标准化 的技术栈和编程范式，就越容易让其他人更改你的服务。当然，另一方面，如前文所述， 标准化会导致团队降低采取正确的解决方案来解决问题的能力，并可能会降低效率。而 且，如果该团队在地球的另一边，这也是不可能的。
另一个选择是，把产品目录拆分成一般音乐目录和铃声目录两个服务。如果支持铃声的工 作量非常小，而我们未来在这一领域工作的可能性也很低，这个选择可能是不成熟的。另 一方面，如果铃声相关的功能累积有10周的工作量，拆分出服务，并且让移动访队拥有 所有权，可能还是有意义的。
不过，还有另一种模式可以很好地工作。
每条业务线团队，负责自己创建的服务的整个生命周期，包括构建、测试、发布和运维， 甚至弃用。一个核心交付服务团队，为这些团队提供建议、指导和工具来帮助他们完成工 作。浓厚的自动化文化非常关键，REA大量使用AWS，关键原因是想让团队更加自治。 图10-1说明了这一切是如何工作的。
图10-1: Realestate.com.au的组织和团队结构，和架构保持一致
与业务相一致的不仅仅是交付团队的组织，还包栝架构，例如集成方式。一个业务线内， 服务间可以不受任何限制地以任何方式来通信，只要团队确定的服务守护者认为合适即 可。但是在业务线之间，所有通信都必须是异步批处理，这是非常小的架构团队的几个严 格的规则之一。这种粗粒度的通信与不同业务之间的粗粒度的通信是匹配的。坚持异步批 处理，每条业务线在自身的行为和管理上有很大的自由度。它可以随时停止其服务，只要 能满足其他业务线的批量集成，以及自己业务干系人的需求，那么没有人会在意。
这种结构不仅使团队，也让不同的业务实现了很好的自治性。几年前REA只有少量的几 个服务，但现在已经拥有数百个服务，数量比项目人员还多，而且还在以迅猛的速度增长。 拥抱变化的能力成功地帮助公司从本地市场扩张到海外市场。而且，更振奋人心的是，与 项目组成员交流后留给我的印象是，现在的架构和组织结构只是最新的版本，而不是最终 的目的地。我敢说五年后，REA将再次迥然不同。
这些组织的系统架构和组织结构对变化都有着很好的适应性，这能够产生巨大的效益，因 为这样的组织改进了团队的自治性，并且能够加快新需求和新功能的发布速度。很多组织 都意识到，系统架构并非凭空产生的，REA是其中之一。
10.11反向的康威定律
到目前为止，我们已经谈论过组织是如何影响系统设计的。但是反向的呢？也就是说， 系统设计能改变组织吗？虽然我没能找到足够充分的证据来支持这一想法，但确实听说
过一些。
也许最好的例子是我多年前为其工作过的一个客户。当时，Web刚刚起步，互联网就像是 将AOL软盘里的东西送货上门，这家公司是一个大型印刷公司，有一个小网站。它有网 站是因为曾经想做这个事情，但是与许多其他业务相比，这个网站并不是很重要。当创建 原始系统时，关于系统如何工作的技术决策也做得相当随意。
这个系统的内容源于多个渠道，但大部分来自供公众浏览的第三方广告。系统有一个输入 子系统，允许付费的第三方创建内容；有一个核心子系统，得到输入的数据并以各种形式 来充实它；最后还有一个输出子系统，创建最终的网站供公众浏览。
最初的设计决策是否正确已属于历史学家间的对话，但公司多年来改变了不少，我和很多 同事都开始怀疑该系统设计是否符合公司的现状。其物理打印业务已经明显减弱，收入急 剧减少，因此目前公司的主营业务是在线业务。
当时，我们看到公司的组织结构与系统的三个子系统严格一致。三个IT方面的业务线或 部门，分别对应输入、核心和输出子系统。这些业务线都有单独的交付团队。我当时并没 有意识到，这些组织结构没有早于系统设计，反而是根据系统设计发展成这样的。在印刷 业务减少时，伴随着数字业务的增长，系统设计无意中为组织如何发展铺好了道路。
最后，我们意识到，无论系统有什么设计缺陷，我们都不得不通过改变组织结构来推动系 统的更改。许多年后，这个过程仍然在进行中！ >
关于这个话题，每个组织都有自己的节奏。了解你的员工能够承受的变化，不要逼他们改 变太快！也许在短时间内，你仍然需要一个单独的团队来处理线上支持或生产环境部署， 以便给开发人员足够的时间调整到新的实践中。然而，你可能不得不接受，需要组织中不 同人的参与才能搞定这个工作。无论方法是什么，你需要跟员工清楚地阐明，在微服务的 世界里每个人的责任，以及为何这些责任如此重要。这能够帮助你了解技能差距并思考如 何弥补它们。对许多人来说，这将是一个非常可怕的旅程。请记住，如果没有把人们拉到 一条船上，你想要的任何变化从一开始就注定会失败。
10.13 小结
康威定律强调了试图让系统设计跟组织结构不匹配所导致的危险。这引导我们试图将服务 所有权与同地团队相匹配，而两者本身与组织限界上下文是匹配的。当两者不一致时，我 们会得到本章所阐述的那些摩檫点。认识到两者之间的联系，我们要确保正在构建的系统 对组织而言是合理的。
我们这里讲的所有内容，都会涉及组织规模化后的挑战。当我们的系统开始扩大规模，不 再是几个分散的服务时，还需要担心其他一些技术方面的考虑。接下来我们会阐述这方面 的内容。