（接前文）

组织转变

这一节我们将讨论为了更好地应用云架构，组织在建立团队方面将如何改进。这个理论的背后是著名的Conway’s Law，我们的办法是围绕一个长期的产品线建立多职责的团队，而不是鼓励每种职责的人员呆在自己单独的团队里（比如testing）。

业务能力¹团队

任何组织设计的产品，它的设计结构都跟组织的交流结构一致。—— Melvyn Conway

我们已经讨论了把IT划分为竖井的做法。自然地，这时我们也把每个人放进了这样的竖井里。那么我们来看看需要开发一个新软件时会发生什么。

通常的做法是建立一个项目团队，指定一名项目经理。然后项目经理会跟各个竖井打交道，获得项目所需的各种人员。从上面引用的Conway’s Law我们会看到，这种团队自然就产出了类似竖井结构的架构：

• 数据操作层
• 服务层
• Web MVC 层
• 消息层
• ……

这些层次横亘在各个业务能力间，各个业务能力要想不影响其他地创新和落地，变得比较困难。

很多公司想要迁移到云架构，比如按业务能力划分微服务。他们应用的是Thoughtworks所谓的 “反Conway策略”。不是按组织结构来决定架构，而是反过来，按照想要的架构来重新调整组织架构。按照Conway的观点，只有这样，你想要的架构才会最终出现。

所以，作为迁移到DevOps文化的一部分，团队跨职责并按照业务能力来组织，他们开发产品而不是项目。产品是长期存在的，直到他们不再具有业务价值。交付一个业务能力需要的人员都在一个团队中——开发、测试、发布、运营，代码不需要在各个团队间传来传去。这种团队往往也叫“两个披萨团队”，也就是说如果两个披萨不够这个团队分，那这个团队就太大了点。

现在我们来看如何决定要建立什么团队。如果我们遵从“反Conway策略”，我们将从组织的领域模型开始，找到能够封装在“界限上下文”²里地业务能力。一旦确定了这些业务能力，我们就建立相关的业务能力团队，负责这个业务能力的整个生命周期，同时也负责从开发到运营的整个循环。

平台团队

业务能力团队依赖于“敏捷的自助基础设施”³。实际上，我们可以定义一个业务能力，叫做“可以开发、部署、运营业务能力的业务能力”。这个能力由平台团队负责。

平台团队根据业务能力团队的要求运营着“敏捷的自助基础设施”。如果公司自己运行云平台，那平台团队需要负责数据中心和了解硬件。

IT运营往往通过各种ticket系统与客户交互。但平台团队运营的是“自助”的平台，它要以不同的方式交互。就像业务能力团队通过API合同跟其他团队协作，平台团队也为平台定义一套合同。业务能力团队不是将环境和数据请求放到等待队列等待实施，而是请求并获得一个自动发布管道，需要的时候能够自行处理环境和数据。

技术转变

现在我们来看看迁移到云中的DevOps可能遇到的实现问题。

分解单体⁴架构

传统的n层单体架构部署到云基础设施很难运行得好。因为它们往往就运行环境做了一些假设，然而云基础设施并不支持，比如：

• mount好的共享文件系统
• P2p的应用服务集群
• 共享运行库
• 已知位置的配置文件

这些假设都基于这种架构的应用被部署在长期存在的基础设施上，它们跟云基础设施弹性短期的想法并不兼容。如果应用并没有这些环境假设呢？还是有问题：

• 单体架构将所有业务能力的变化绑在一起，不利于各个业务能力的创新分别落地。妨害了创新的快速。
• 单体架构中的服务很难单独伸缩，负载效率难以提升。
• 新加入组织的员工难以适应，他们需要学习整个领域和大量的代码，没有几个月的时间，他们很难成为真正有效率的开发人员。
• 开发组织通过增加人员来扩大规模很难，增加沟通和协作的成本。
• 技术栈长期不变，引入新技术风险较大。

以上清单正好是“微服务”⁵的优势清单逐条反过来（我Kao）。同时，将组织划分为业务能力团队，也要求将单体架构分解为微服务。只有这样，才能充分享有我们迁移到云基础设施的好处。

分解数据

分解单体架构并不足够。数据模型也需要分解。如果业务能力团队看似自治但却被限制在同一个数据上协作，单体架构对创新的阻碍只不过搬到了数据层面而已。

DDD认为⁶我们的成功很大程度上依赖于我们的领域模型的质量。领域模型只有内部一致才能有用，同一个模型中不应该有不一致的概念和词汇。

要产出一个大一统的领域模型非常困难和昂贵，甚至是不可能的。Evans根据内部一致的子集来划分领域，称为“界限上下文”。

最近在跟航空业的客户合作时，我们讨论了几个他们业务的核心概念。比如“预定”，我们能在相关业务中找出十七个不同的定义，显然它们不能看做是同一个概念。相反，每个定义都是有细微差异的不同概念。这成为了组织的瓶颈。

界限上下文允许我们在组织范围保留不一致的定义，同时在单个上下文里面保持一致。

我们开始识别哪些能够内部一致的领域模型片段。我们在这些片段的周围画出边界，这就成了我们界限上下文。这样我们就能把我们的业务能力团队对应到界限上下文，这些团队将产出对应的微服务。

微服务的定义又指导了需要哪些十二因子应用。十二因子主要是技术上的规范，而微服务主要是业务上的规范。我们定义界限上下文，赋予之业务能力，围绕业务能力建立团队，让团队开发十二因子应用。由于这样的应用都是独立可部署的，使得业务能力团队有更多的技术手段可用。

我们将界限上下文与“每服务每数据库”模式关联，也就是每个微服务封装、管理和保护它们自己的领域模型和数据存储。在这个模式中，只有一个应用服务可以访问它的数据存储（可能是一个多租户数据库集群中的一个schema，也可以是一个独占的物理数据库）。任何外部访问只能通过API合同（经常是REST，但是可以是任何协议）。

这种分解使应用可以根据自己的数据特征选择不同的数据存储，比如数据结构和数据读写模式。另一方面，为了能回答一些跨上下文的问题，数据通过事件驱动技术重新组合起来。比如CQRC和event sourcing就常常用来实现跨上下文将相似概念同步起来。

容器化

容器镜像（比如由LXC、Docker、Rocket准备的）正在迅速成为云架构的部署单元。这些镜像也迅速得到了调度工具的支持，比如Kubernetes、Marathon、 Lattice。公有云提供商比如Amazon和Google也提供了基于容器的调度和部署服务。容器技术提供了跟虚拟机相似的资源分配和隔离，同时相对来说大大地轻量和易移植。应用开发者要尽快适应将应用打包为容器镜像，以便能享有现代云基础设施带来的便利。

从奏乐到舞蹈⁷

不仅仅服务产出、数据模型和管理应该去中心化，服务的集成也应该去中心化。企业中服务集成传统上使用类似ESB。ESB就成为了服务间交互的所有决策的控制者，包括路由、传输、协议、安全等。我们称为“奏乐”，类似于指挥决定了整个音乐的演奏进程。ESB和奏乐模式使得架构图显得非常简单，但不幸的是这种简单性具有欺骗性。ESB中经常隐藏着一张复杂性的网。管理这种复杂性非常费时，跟它一起工作也成为了应用开发团队的瓶颈。就像我们谈到的大一统的数据模型一样，大一统的服务集成也成为了追求快速的绊脚石。

在云架构中，比如微服务，我们倾向于“舞蹈”，类似于芭蕾舞。不是把精力放在集成机制，而是放在各个节点。当舞台上发生了跟原计划不符的异常情况，并没有一个指挥来告诉舞者该怎么做，而是舞者自己适应。类似的，我们的服务也是自己适应他们运行环境中出现的异常情况，比如通过“客户端负载均衡⁸”和“断流器⁹”。

虽然架构图看上去趋向于一张纠结的网，但其复杂性并不超过传统的SOA。舞蹈模式只是承认和暴露了系统本质的复杂性。这个转变同样是为了支持自治进而实现云架构快速地目标。团队可以迅速应对各种情况，不必与其他团队过多协作，也不用疲于跟ESB打交道。

总结

以下为译者自己总结的 :-)

1. 文化转变：DevOps、持续交付、自治
2. 组织结构转变：业务能力团队、平台团队
3. 技术转变：分解服务、分解数据、容器化、分解集成

（后文继续，迁移指南）