从单片应用转向微服务架构

Joris Kuipers 在一次演讲中声称，将现有系统迁移到微服务与构建一个新的系统迥然不同。该演讲描述了一个正在进行中的将大型单片应用重构成更加分布式的或基于微服务的架构的过程。

Kuipers 是 Trifork Amsterdam 的一名架构师，他所描述的应用是一个医疗保障的电子病历系统。它于六年前创建，头两年是一个带有少量 B2B 集成的单片应用。从一开始，它就是使用 Trifork 开发的开源框架 Axon 基于命令查询责任隔离（CQRS）构建的。它运行得很好，但是随着系统和用户数量的增长，新需求出现了，包含针对保险开支的需求，保险开支必须是一个单独的应用，但是仍然需要使用当前应用的数据。因为他们现在不得不转向共享状态的多个应用，这是一个巨大的改变。

今天，核心应用仍然相当庞大，周围围绕着三个独立的保险开支应用，在十多个可部署的应用中，一共包含了近 40 个第三方集成功能。它拥有约 65 个租户和 12,000 个用户。

许多集成的生命周期比核心应用短得多，所以他们转向微服务的主要原因是因为需要扩展开发以适应集成的不同的生命周期。扩展开发团队和加大开发步伐是这一转变的真实动力。

因为在开始重构的时候他们的应用是基于 CQRS 和事件的，他们决定使用事件作为集成点，通过消息代理向其它集成应用广播所有事件。他们将所有存在的 B2B 集成相关的代码抽取到单独的应用中，将它们连接到代理上以获取所有发送的事件。针对抽取出来的应用，需要与核心应用通信的，他们使用了核心应用中已经存在的 CQRS 命令。

数据流的典型例子是用户使用核心应用更新一些数据。该更新进而会引起事件的发布，然后集成应用异步读取事件，基于这种逻辑，这会发送通知给外部应用。Kuipers 把这看作一个轴辐式架构，核心应用是 hub，被几个更小的应用围绕。他指出这种通过消费者解藕的方式是一种非常适合他们的转向微服务的方式。

对于 Kuipers 来讲，事件对于拆分一个系统有非常大的帮助，因为它们本质上是异步的，描述已经发生的事情，并且其它系统能够监听并响应它。他指出使用事件也会引入一些挑战，当事件成为集成的支柱时，考虑这些挑战尤其重要。这些挑战有：

• 既然事件是共享的数据结构，它们可能导致耦合
• 一些事件可能需要在一个应用或者一个服务内私有
• 需要考虑类型粒度和数据量，它们能够防止事件处理器请求更多的数据
• 不破坏客户端的情况下事件如何随着时间演化

作为结论，Kuipers 指出，他们现在能快速开发和部署与主应用隔离的新集成功能，这也意味着风险的降低，因为核心系统没有被动过，Kuipers 声称所有这些让他们有了重要的竞争优势。

查看英文原文： Moving a Monolithic Application towards a Microservices Architecture

感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。