特性二 围绕业务功能组织团队

特性二：围绕“业务功能”组织团队

当在寻求将一个大型应用系统分解成几部分时，公司管理层往往会聚焦在技术层面上，这会导致组建用户界面团队、服务器端团队和数据库团队。当团队沿着这些技术线分开后，即使要实现软件一个简单的变更，也会导致跨团队的项目时延和预算审批。在这种情况下，聪明的团队会进行局部优化，“两害相权取其轻”，来直接把代码逻辑塞到他们能访问到的任意应用系统中。换句话说，这种情况会导致代码逻辑散布在系统各处。这就是康威定律[5]在起作用的活生生的例子。

任何设计（广义上的）系统的组织，都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致。

                                ——梅尔文•康威（Melvyn Conway）, 1967年

图2：康威定律在起作用

微服务使用不同的方法来分解系统，即根据业务功能（business capability）来将系统分解为若干服务。这些服务针对该业务领域提供多层次广泛的软件实现，包括用户界面、持久性存储以及任何对外的协作性操作。因此，团队是跨职能的，它拥有软件开发所需的全方位的技能：用户体验、数据库和项目管理。

图3：被团队边界所强化的服务边界

以上述方式来组织团队的公司是www.comparethemarket.com。跨职能团队负责构建和运维每个产品，而每个产品被拆分为多个独立的服务，彼此通过一个消息总线来通信。

一个微服务应该有多大？

尽管对于这种架构风格，“微服务”已经成为一个流行的名字，但是这个名字确实会不幸地导致大家对服务规模的关注，并且产生了有关什么是“微”的争论。在与微服务从业者的交谈中，我们看到了有关服务的一系列规模。所听到的最大的一个服务的规模，是遵循了亚马逊的“两个比萨团队”（即一个团队可以被两个比萨所喂饱）的理念，这意味着这个团队不会多于12人。对于规模较小的服务，我们已经看到一个6人的团队在支持6个服务。

这引出了一个问题，即“每12人做一个服务”和“每人做一个服务”这样有关服务规模的差距，是否已经大到不能将两者都纳入微服务之下？此时，我们认为最好还是把它们归为一类，但是随着进一步探索这种架构风格，绝对有可能我们将来会改变主意。

大型单块应用系统也可以始终根据业务功能来进行模块化设计，虽然这并不常见。当然，我们会敦促构建单块应用系统的大型团队根据业务线来将自己分解为若干小团队。在这方面，我们已经看到的主要问题是，他们往往是一个团队包含了太多的业务功能。如果这个“单块”跨越了许多模块的边界，那么这个团队的每一个成员都难以记忆所有这些模块的业务功能。此外，我们看到这些模块的边界需要大量的团队纪律性来强制维持。而实现组件化的服务所必要的更加显式的边界，能更加容易地保持团队边界的清晰性。

[5]原始论文参见梅尔文•康威的网站：http://www.melconway.com/Home/Committees_Paper.html