Stefan Tilkov在microXchg柏林的演讲：微服务的模式与反模式

by

• Jan Stenberg

摘要：

在柏林举行的microXchg 2018上，Stefan Tilkov在演讲中以他的视角探讨了微服务项目的模式与反模式，包括演化性的架构、基于幻想进行解耦、分布式单体以及实体服务。他特别强调，有些他认为是模式的内容，其他人可能认为是反模式，反之亦然。

在柏林举行的microXchg 2018上，Stefan Tilkov在演讲中以他的视角探讨了微服务项目的一系列模式与反模式。他特别强调，有些他认为是好模式的内容，其他人可能认为是反模式，反之亦然。

这个演讲首先讨论了微服务是一种设计模块的模式，在这种模式中我们将模块设计为单独的部署和运维单元，这些模块的实现有着非常高的自由度。模块基于网络进行通信，会在它们之间建立一个边界，这样的话会促进封装，在交互和协作的时候，更加难以违背模块的设计初衷。

Tilkov是INNOQ的联合创始人，对他来说，采用微服务的影响包括隔离性、自治以及灵活性，他也提到按照他的定义构建模块化的软件时，其实没有必要完全采用微服务的方式。但是，鉴于我们经常不能有效地设计大规模的软件，所以我们依然需要微服务模式。

演化性的架构

在构建系统的时候，我们不一定从一开始就能创建出合适的架构，你可以创建“演化性的架构（Evolutionary Architecture）”，它的构造具有适应性，能够在特定的时间点转换为合适的架构。对于Tilkov来说，这种架构的实现方式包括：

• 将大型的域分割为他所称的“变更孤岛”
• 针对可替代性进行设计，而不是可重用性
• 最小化共享依赖，重点关注自治和冗余，而不是重用

这种架构的一个优势就是能够帮助我们实现实验性的特性，比如使用A/B测试。

分布式单体应用

Tilkov提到的第一个反模式是分布式单体应用（Distributed Monolith），或者称之为变坏的微服务，他将其描述为：

系统是由规模随意、紧密耦合的模块所组成的，这些模块之间通过网络接口进行通信。

Tilkov认为，这通常是跟风或会议驱动所形成的架构，对业务领域缺少关注。使用这种模式带来的常见后果包括：

• 变更所带来的连锁反应
• 复杂的环境
• 难以理解和维护

在极端负面的情况下，这可能会变成无人能够管理的技术和框架所组成的混合体。

幻想解耦

在Tilkov的经验中，团队引入微服务通常是为了更加灵活并且能够快速适应变化。“幻想解耦（Decoupling Illusion）”是一个反模式，在这种模式下我们会将系统拆分为模块，但是因为缺少领域相关的知识，所以并没有解决基础的问题，这样会背离利益相关者和业务需求。我们已经创建的模块会从两个或更多的利益相关者那里获取需求，它们还会依赖于其他的模块。这样的话，这些模块必须要一起演化和部署。

微平台

与前面对应的另外一个反模式叫做“微平台（Micro Platform）”，在这种反模式下，会将所有的内部/运维服务标准化到一个框架之中，并强制所有的团队采用。现在，我们可能面临的问题就是每个服务中都会有一个技术性的依赖，所有的服务都会对某个利益相关者产生依赖。这种反模式的主要推动力来自标准化的目标，有时候这种目标看起来是很有道理的，尤其是在项目的初期，但是这也会带来一些需求，也就是协调新的特性以及跨所有的团队进行更新。为了缓解这种状况，Tilkov建议框架的使用是可选的。

实体服务

“实体服务（Entity Service）”，举例来说，某个订单（order）服务，在零售领域这可能是一个看上去很合理和有用的服务。这种反模式的问题在于对该服务感兴趣的所有其他的服务都会对该服务提出需求，因此最终的结果就会导致实体服务变成了所有客户端需求的混合体。Tilkov认为这种实体服务有时候根本不需要，它们的责任应该由其他的服务来完成，这些服务对订单有着自己的视角。他认为，创建该实体服务的唯一原因就是它的名字中包含了“订单”这个词，在你尝试创建订单通用定义的地方，推荐参考企业数据模型（enterprise data model，EDM）。

DDDD与SCS

Tilkov经常见到一些客户，他们具有非常复杂的应用，这些应用由不同的部分所组成，即界限上下文（bounded context）。当这些上下文与微服务结合的时候，最终形成的就是“分布式领域驱动设计（Distributed Domain-Driven Design，DDDD）”模式，在这种模式中，通信通常是异步的，还可能会使用业务事件，数据是冗余存储的。这些服务是松耦合的，如果每个服务的大小符合界限上下文的话，它们也会更加自治。对Tilkov来说，采用这种方式的主要驱动力在于能够实现单独的演化。

自包含系统(Self-Contained System，SCS）类似于DDDD模式，区别在于每个服务还包含了自己的UI组件，与服务的轻量级集成通常是在前端完成的。这样的话，能够最小化所需的基础设施，对Tilkov来说，这种模式最适合解耦开发团队。

单体应用

Tilkov提到的最后一个模式是“单体应用(Monolith）”，他相信这种模式依然适用于很多场景，例如单个小型的团队。这是一个标准的应用，开发起来非常简单直接、易于重构并且不包含任何人为引入的分布性:

高度内聚、紧密集成、单一部署的应用。

总结

Tilkov在演讲中，主要关注了服务的大小以及正确进行规模划分所面临的挑战。他相信如果一个架构有2000个事项组成的话，那么它将会非常难以理解。因此，他主张借助分组或集群的方式，为系统构建更多的结构。他总结到，没有哪个模式是最适合的模型，它们都依赖于具体的上下文。我们选择的解决方案要始终是由领域和所需的业务收益所驱动的。他还指出，如果可能的话，你应该争取采用一种可演化的架构，它能够随着需求而增长。

会议演讲的视频已经进行了录制，其中有一部分已经发布，更多的视频稍后会发布。

查看英文原文：Stefan Tilkov at microXchg Berlin: Microservice Patterns and Antipatterns