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

只愿长相守 提交于 2019-12-06 15:15:01
 
到目前为止,本书大部分的内容集中在向细粒度架构迈进时所面临的技术挑战。但除此之 外,我们也需要考虑组织方面的问题。在这一章,我们将了解到忽略公司的组织结构会带 来什么样的危险。
 
我们的行业还很年轻,它似乎在不断地重塑自己。不过,一些关键定律还是经受住了时间 的考验。例如摩尔定律,它表示集成电路上可容纳的晶体管数目每两年会增加一倍。该定 律已经被证明准确得惊人(尽管有人预测,这种趋势已经放缓)。还有一条定律,我发现 几乎普遍适用,在我的日常工作中也更有用,那就是康威定律。
 
梅尔•康威于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 小结
 
康威定律强调了试图让系统设计跟组织结构不匹配所导致的危险。这引导我们试图将服务 所有权与同地团队相匹配,而两者本身与组织限界上下文是匹配的。当两者不一致时,我 们会得到本章所阐述的那些摩檫点。认识到两者之间的联系,我们要确保正在构建的系统 对组织而言是合理的。
 
我们这里讲的所有内容,都会涉及组织规模化后的挑战。当我们的系统开始扩大规模,不 再是几个分散的服务时,还需要担心其他一些技术方面的考虑。接下来我们会阐述这方面 的内容。
 
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!