1.6 案例分析

本节将通过构建一个精简但又完整的系统来展示微服务架构相关的设计理念和常见实现技术。本案例系统称为订单系统（Order System），试图对互联网应用中最常见的订单业务做抽象。现实环境中订单业务可以非常复杂，该案例的目的在于演示从业务领域分析到系统架构设计再到系统实现的整个过程，不在于介绍具体业务逻辑，所以业务领域建模上做了高度抽象，并不代表实际的应用场景。

按照实施微服务架构的基本思路，服务建模是案例分析的第一步。服务建模包括子域与界限上下文的划分以及服务拆分和集成策略的确定。

OrderSystem包含的业务场景比较简单，用户浏览商品，然后在商品列表中选择想要购买的商品并提交订单；在提交订单的过程中，我们需要对商品和用户账户信息进行验证。从领域的角度进行分析，可以把该系统分成以下3个子域。

• 商品（Product）子域

商品管理，用户可以查询商品以便获取商品详细信息，同时基于商品提交订单；系统管理员可以添加、删除、修改商品信息。

• 订单（Order）子域

订单管理，用户可以提交订单并查询自己所提交订单的当前状态。

• 用户账户（Account）子域

用户管理，我们可以通过注册成为系统用户，同时也可以修改或删除用户信息，并提供账户有效性验证的入口。

从子域的分类上讲，用户账户子域比较明确，显然应该作为一种通用子域。而订单是OrderSystem的核心业务，所以应该是核心子域。至于商品子域，在这里可将其归为支撑子域。从子域之间的上下游关系上看，订单子域需要同时依赖于商品子域和用户子域，商品子域和用户子域之间不存在交互关系。3个子域的关系如图1-1所示。

图1-1　OrderSystem的3个子域

为了简单起见，我们对每一个子域都提取一个微服务作为示例。基于以上分析，可以把OrderSystem简单划分成3个微服务：ProductService、OrderService和AccountService，图1-2展示了OrderSystem的基本架构。在图1-2中，3个微服务之间需要基于REST进行跨服务之间的交互。

图1-2　OrderSystem服务模型

以上3个微服务构成了OrderSystem的业务主体，而围绕构建一个完整的微服务系统，还需要引入其他很多服务，这些服务从不同的角度为实现微服务架构提供支持。本书中所介绍的关于Spring Boot、Spring Cloud和Docker的各项核心技术都会在该案例中得到体现。关于该案例的完整代码可参考本书提供的案例资源。