系统架构设计：别错过出口——如何避免微服务的退化【摘录】

作者：Lars Gentsch，E-Post Development GmbH

---

  实际上，开发一个微服务并不太困难。但如何保证微服务最终不会退化成单体呢？下面通过一个例子说明，在什么情况下微服务会朝着错误的方向发展，以及我们可以采取什么措施来避免微服务的退化。
  假设有一个用于客户注册的小型 Web 应用。几乎所有 Web 应用都会遇到类似的情况。例如客户需要再网店（Amazon、Otto 等）上购物或注册视频点播门户（Amazon Prime、Netflix）等。该应用首先会引导客户完成注册流程。在这一步，客户填入用户名、密码、电子邮件，以及住址用户注册是一个自包含的小功能，因此非常适合作为微服务。
  在技术层面，该服务的结构非常简单，其中包含两到三个 HTML 页面或一个 AngularJS 单页应用，少量的 CSS，一个 Spring Boot 应用（采用 Maven 构建），以及一个 MySQL 数据库。
  服务收到数据后，会对数据进行验证，并将其转成领域模型，然后持久化到数据库中。那么，这样的微服务怎么会一步步退化成单体呢？

---

合并新功能

  只有成年用户才被允许在商店购物或在视频点播网站上观看视频，因此需要对客户的年龄进行验证。一种解决方案是将客户的出生日期与其他数据存储在一起，然后增加一个外部服务用于年龄验证。
  因此，服务的数据模型中要增加出生日期。由于加入了一个外部服务，需要编写该外部 API 的客户端，而且客户端要应对服务提供者不可用等异常情况。
  因为年龄验证功能很可能是一个异步流程，所以我们的服务可能要实现回调接口。因此，微服务需要保存流程的状态信息。什么时候发起年龄验证流程？是否有必要通过电子邮件通知客户？如何判断验证流程是否成功？

---

微服务究竟发生了什么改动

  注册微服务发生了如下的改动。

• 客户数据增加了出生日期。这一改动没有问题。
• 除了客户数据，还增加了流程数据。注意，这里流程数据与领域数据是混在一起的。
• 除了服务原本的 CRUD 功能，还需要增加某些工作流，导致同步处理与异步处理混在一起。
• 增加了一个外部系统。这增加了注册微服务的测试难度，因为测试过程中需要模拟这个外部系统及其行为。
• 对于扩缩容，与外部系统的异步通信还提出了其他的要求。考虑到负载和容灾（failover），注册微服务需要启动约 10 个实例。而增加的年龄验证功能只需要两个实例即可满足容灾和稳定运行的要求。因此，两类不同的运行时需求是混在一起的。

  正如示例所展示的，看似微不足道的功能（如年龄验证功能）可能会对微服务产生巨大的影响。

---

新增微服务还是扩展已有微服务

  何时增加新的微服务，主要依据如下准则。

• 引入了不同类型的数据模型和数据（领域数据与流程数据）。
• 同步和异步数据处理混在一起。
• 加入了新的服务。
• 同一服务的不同功能各自承担的负载不一样。

  示例中的注册服务可以进一步扩展，客户地址的验证也可以交由一个外部服务进行处理。该功能常用于验证地址是否存在，也可用于协助人工清理重复注册的用户。另外，注册时进行偿付能力检查或客户评分也是常见的应用场景。
  从领域角度来看，上述功能均属于客户注册，因此会诱导开发者和架构师将其集成到注册服务中。结果，该微服务将不再是一个微服务。

---

如何判断是否应该增加新的微服务

  如果你所遇到的情况符合如下特征，那么你很可能需要新的微服务。

• 该服务已经需要涌讨 Mavon 多模块项目或 Gradle 多模块项目进行构建。
• 测试执行的时间已经超过了 5 分钟（违背了 “快速反馈” 原则），导致测试必须要分组和并行执行。
• 在配置文件中、服务的配置已经需要根据领域进行分组，或者已经被拆分成多个配置文件来提高可读性。
• 服务完整构建一次所花费的时间足够你喝杯咖啡休息一会儿，因此已经无法实现短周踟的快速反馈（违背了 “快速反馈” 原则）。

---

结论

  正如上述示例中的注册微服务所示，维持一个微服务的本来面目，并抵制因时间压力而将新功能集成进已有微服务的诱惑，这已经成为严峻的挑战。即便相关的功能显然属于同一领域也是如此。
  那么如何防止微服务退化呢？原则上，新服务（包括其数据存储）的创建必须要尽可能简单采用 Spring Boot，Grails，Play 等架构可简化新服务的创建。通过项目模板（如 Maven archetype）， Docker 容器部署等措施，可以简化新的微服务的创建、配置，以及部署到生产环境的过程。降低创建新服务的 “成本”，从而清除引入新的微服务的障碍，能够有效地抵制在已有服务中实现新功能的诱惑。