什么是微服务架构?( 三 ) _微服务架构

业务逻辑的周围是适配器。与端口一样，有两种类型的适配器：入站和出站。入站适配器通过调用入站端口来处理来自外部世界的请求。入站适配器的一个实例是Spring MVC Controller，它实现一组REST接口（endpoint）或一组Web页面。另一个实例是订阅消息的消息代理客户端。多个入站适配器可以调用相同的入站端口。

出站适配器实现出站端口，并通过调用外部应用程序或服务处理来自业务逻辑的请求。出站适配器的一个实例是实现访问数据库的操作的数据访问对象（DAO）类。另一个实例是调用远程服务的代理类。出站适配器也可以发布事件。

六边形架构风格的一个重要好处是它将业务逻辑与适配器中包含的表示层和数据访问层的逻辑分离开来。业务逻辑不依赖于表示层逻辑或数据访问层逻辑。

由于这种分离，单独测试业务逻辑要容易得多。另一个好处是它更准确地反映了现代应用程序的架构。可以通过多个适配器调用业务逻辑，每个适配器实现特定的API或用户界面。业务逻辑还可以调用多个适配器，每个适配器调用不同的外部系统。六边形架构是描述微服务架构中每个服务的架构的好方法。

分层架构和六边形架构都是架构风格的实例。每个都定义了架构的构建块（元素），并对它们之间的关系施加了约束。六边形架构和分层架构（三层架构）构成了软件的逻辑视图。现在让我们将微服务架构定义为构成软件的实现视图的架构风格。

2.1.3　微服务架构是一种架构风格

前面已经讨论过4+1视图模型和架构风格，所以现在可以开始定义单体架构和微服务架构。它们都是架构风格。单体架构是一种架构风格，它的实现视图是单个组件：单个可执行文件或WAR文件。这个定义并没有说明其他的视图。例如，单体应用程序可以具有六边形架构风格的逻辑视图。

模式：单体架构
将应用程序构建为单个可执行和可部署组件。请参阅：http://microservices.io/patterns/monolithic.html 。

微服务架构也是一种架构风格。它的实现视图由多个组件构成：一组可执行文件或WAR文件。它的组件是服务，连接器是使这些服务能够协作的通信协议。每个服务都有自己的逻辑视图架构，通常也是六边形架构。图2-3显示了FTGO应用程序可能的微服务架构。此架构中的服务对应于业务功能，例如订单管理和餐馆管理。

模式：微服务架构
将应用程序构建为松耦合、可独立部署的一组服务。请参阅：http://microservices.io/patterns/microservices.html 。

文章插图

图3　FTGO应用程序可能的微服务架构。它由众多服务组成

微服务架构强加的一个关键约束是服务松耦合。因此，服务之间的协作方式存在一定限制。为了解释这些限制，我将尝试定义什么是服务，解释松耦合意味着什么，并告诉你为什么这很重要。

什么是服务

服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能。图2-4显示了服务的外部视图，在此示例中是Order Service 。服务具有API，为其客户端提供对功能的访问。有两种类型的操作：命令和查询。API由命令、查询和事件组成。命令如createOrder()执行操作并更新数据。查询，如findOrderById()检索数据。服务还发布由其客户端使用的事件，例如OrderCreated 。

服务的API封装了其内部实现。与单体架构不同，开发人员无法绕过服务的API直接访问服务内部的方法或数据。因此，微服务架构强制实现了应用程序的模块化。

微服务架构中的每项服务都有自己的架构，可能还有独特的技术栈。但是典型的服务往往都具有六边形架构。其API由与服务的业务逻辑交互的适配器实现。操作适配器调用业务逻辑，事件适配器对外发布业务逻辑产生的事件。

文章插图

图4　服务具有封装实现的API 。API定义了由客户端调用的操作。有两种类型的操作：命令用来更新数据，查询用来检索数据。当服务的数据发生更改时，服务会发布可供客户端订阅的事件

在本书第12章讨论部署技术时，你将看到服务的实现视图可以采用多种形式。该组件可以是独立进程，在容器中运行的Web应用程序或OSGI包、云主机或Serverless技术，等等。但是，一个基本要求是服务具有API并且可以独立部署。