微服务分层架构

原著信息： Microservices Layered Architecture

by:Kasun Indrasiri

With Microservices architecture, a single software application/functionality is implemented as a combination of multiple microservices and their interactions. Hence the communications between services and their coordination are vital for a successful realization of microservices architecture.

在微服务架构中，单个软件应用 / 功能被实现为多个微服务及其交互的组合。因此服务间的通信及他们的协调对于成功实现微服务架构至关重要。

It is important to understand that, the tasks that an ESB does in an ESB based SOA implementation, don’t simply disappear when you switch to Microservices Architecture. Rather, all ESB/integration functionalities are segregated and dispersed among all the microservices. Therefore some level of logical organization of the microservices based on their granularity and capabilities is quite useful when it comes to the implementation of services.

理解基于 ESB 的 SOA 实现中 ESB 所做的工作至关重要，当你转向微服务架构时不要轻易忽视这一点。相反，所有 ESB / 集成功能都被隔离和分散在所有微服务中。因此，当涉及到服务实现时基于其粒度和能力方面的逻辑组织层面的东西是相当有用的。

So, if we have a closer look at the microservices implementation, we can identify different types of services that we can categorize into few different layers. We can come up with a layered architecture as shown in figure 1 ( I originally proposed as a logical set of layers, but this could well be a concrete layered architecture too) with different microservices types.

因此，如果我们仔细研究微服务实现，我们就可以识别出可以分类为几个不同层的不同类型的服务。我们可以提出一个图 1 所示不同微服务类型的分层架构（我最初提出了一个逻辑集合的分层，但是这也可能是一个具体的分层架构）。

So, based on service functionalities and granularities, we can identify following service categories.

所以，基于服务的功能和粒度，我们可以定义以下服务分类。

1. Core/Atomic Micoservices

At the bottom layer, we have fine-grained self-contained services (no external service dependencies) that mostly comprise of the business logic and less or no network communication logic.

1. 核心 / 原子 微服务

在底层，我们有细粒度的自包含服务（没有外部服务依赖）它们大多由业务逻辑和少量或没有网络通信的逻辑组成。

2. Composite/Integration Microservices

Atomic microservices are often cannot be directly mapped to a business functionality as they are too fine-grained. Hence a specific business functionality may require a composition of multiple atomic/core services. The middle layer comprises of such composite or integration microservices. These services often have to support a significant portion of ESB functionalities such as routing, transformations, orchestration, resiliency and stability patterns etc.

Composite/integration services are coarse-grained(relative to atomic services), independent from each other and contains business logic(routing, what services to call, how to do data type mapping etc.) and network communication logic(inter-service communication through various protocols, resiliency behaviors such as circuit breakers).

Most of the ESB/integration capabilities(such as EIPs, resiliency and stability patterns) are realized in Microservices architecture at the composite/integration services layer.

These services also could bridge the other legacy and proprietary systems(e.g SAP ERP), external web APIs (e.g. Salesforce), shared databases etc. (often known as the anti-corruption layer).

2. 复合 / 集成 微服务

原子微服务通常不能直接映射到业务功能因为它们太细粒度。因此特定的业务功能可能需要多个 原子 / 核心的服务的组合。中间层包括这种复合或者集成的微服务。这些服务通常需要支持大部分 ESB 的功能，诸如路由、转换、编排、弹性和稳定性模式等。

复合 / 集成 服务是粗粒度（相对于原子服务），彼此独立并包含业务逻辑（请求路由，请求哪个服务？如何做日期类型映射等。）和网络通信逻辑（内部服务通过各种协议通信，诸如断路器这样的弹性行为）。

大多数 ESB / 集成功能（诸如 EIPs，弹性能力以及稳定性模式）都是在 复合 / 集成服务层的微服务架构中实现的。

这些服务通常可以桥接其他传统和专有的系统（例如 SAP ERP），外部 web APIs（例如：Salesforce），共享的数据库等（通常称为 anti-corruption 层）

3. API Services/Edge Services

You will expose a selected set of your composite services or even some atomic service as managed APIs using API services/Edge services.These services are a special type of composite services, that apply basic routing capabilities, versioning of APIs, API security patterns, throttling, apply monetization, create api compositions etc.

3. API 服务 / 边缘服务

你将使用 API 服务 / 边缘服务将选定的一组复合服务甚至一些原子服务导出为托管 API。这些服务是特殊类型的组合服务，它应用基础的路由功能，APIs 版本管理，API 安全模式，节流、应用货币化、创建 API 组合等。

Technologies for building Microservices

When it comes to implementation of microservices, most of the current microservices implementation arbitrary use a given framework or a programming language to build microservices without taking the different service types into the account. With the proliferation of the number of services, this will lead to design, implementation and scalability nightmares. Therefore, we need to pick the right technology, based on the nature of the microservices that we are developing.

创建微服务的技术

当涉及微服务的实现时，大多数当前的微服务实现都任意使用给定的框架或者编程语言来创建微服务，而不考虑不同的服务类型。随着微服务数量的剧增，这将导致设计、实现和扩展性的噩梦。因此我们需要根据我们正在开发的微服务的性质来选择正确的技术。

Core/Atomic Services: Most of the existing technologies are focusing on building these services. There are numerous of frameworks/libraries available for build this type of services (e.g. SpringBoot, Dropwizard, WSO2 MSF4J)

核心 / 原子服务：大多数现存的技术都专注于创建服务。有大量可用的 框架 / 包可用来创建这类型的服务（例如：SpringBoot，Dropwizard, WSO2 MSF4J）

Composite/Integration Services: Most of the current microservice implementations tried to use the same set of technologies to build both core/atomic services and composite/integration services. However, most of the microservices frameworks and platforms are not designed for building composite services.

Therefore building composite services is becoming the most challenging task(just imagine the amount of work related to implementing various integration patterns from scratch, using Java or any other similar programming language) in realizing microservices architecture.

To overcome this problem There are emerging technologies such as Ballerina(which is a programming language designed for service compositions and network interactions), and Service Mesh frameworks (With ‘Service Mesh’ you can offload the network communications to the service mesh and we can only focus on Business logic. E.g. you don’t need to worry about circuit breaking when you call another service).

复合 / 集成 服务： 现今大多数微服务的实现都试图使用相同的技术来同时创建 核心 / 原子 服务和 复合 / 集成 服务。但是，大多数微服务框架和平台并非设计用于构建组合服务。

因此创建组合服务在微服务架构实践过程中正在变成最具挑战的任务（设想一下大量的工作因为要从零开始、使用 Java 或者其他类似编程语言来实现大量集成模式）

要解决这个问题有一些新兴的技术诸如 Ballerina（它是一种为服务组合和网络集成而被设计出来的编程语言），和 Service Mesh 框架（通过 Service Mesh 你可以将网络通信下沉到 Service Mesh，我们只需要关注业务逻辑。例如当你调用其他服务时，你不需要担心断路的问题）。

API/edge Services: Most of the existing (monolithic) API Management and gateway solutions can facilitate these service, as long as API services contain minimal business logic. However, most microservice implementations try to put a massive amount of business logic into this layer, while keeping it as a single monolith. That’s not a sustainable architecture and it violates the key principle of Microservice. So, there are two possible approaches to overcome this problem.

API / 边缘服务：只要 API 服务包含最小的业务逻辑，大多数现存（单体）API 管理和网关方案可以促进这些服务。但是，大多数微服务实现试图在这一层加入大量商业逻辑，同时将其作为一个单体服务。这不是一个可持续发展的架构，它违反了微服务的关键原理。因此，有两种可能的方法来解决这个问题。

Offload the compositions to composition layer and can use a monolithic gateway for just exposing them as APIs. Segregate API Gateway runtime(micro-gateway concept) so that each API/edge service can be built and manage independently. The same technologies that we use to build composite service can also be used in API/edge service development. So, most of the existing (monolithic) API Management/Gateway solutions are still evolving to support concepts such as micro-gateways.

将复合服务卸载到组合层，并可以使用一个单体网关来将其作为 API 导出。

隔离 API 网关运行时（微网关概念），以便可以独立构建和管理每个 API / 边缘服务。

我们用来创建复合服务的技术同样可以用到 API / 边缘服务开发。因此，大多数现有（单体） API 管理 / 网关解决方案仍在不断发展，以支持微网关等概念。