微服务的服务网格

原著信息： Service Mesh for Microservices

by:Kasun Indrasiri

Microservices architecture has been evolving a lot during the last couple of years and there are quite a few new concepts and patterns are emerging. ‘Service Mesh’ concept is getting quite popular. In this post, I’m planning to cover the key concepts related to Service Mesh and how it is used in real-world microservices implementations.

微服务架构在过去几年中发展很多，出现了相当多的新的概念和模式。“Service Mesh” 的概念越来越受欢迎。本文，我计划涵盖 Service Mesh 的关键概念以及如何在实际的微服务实现中使用。

Why ‘Service Mesh’?

As with many emerging technologies, there was a lot of hype around the Microservices Architecture. Most people think that microservices is the answer to all the problems they had with previous architecture such as SOA/ESB. However, when we observe the real world microservices implementations, we can see that most of the functionalities that a centralized bus (ESB) supports are now implemented at microservices level. So, we are more or less solving the same set of fundamental problems, but we are solving them at different dimensions with Microservices.

为什么需要 “Service Mesh”？

跟很多新兴技术一样，微服务架构也有很多炒作。大多数人认为微服务是解决之前架构诸如 SOA / ESB 所遇到的所有问题。然而，当我们观察现实世界微服务的实现时，我们可以看到大多数中央总线（ESB）支持的功能现在都在微服务层面实现。因此，我们或多或少正在解决相同的本质问题，只是我们在微服务的不同维度解决它们。

For example, let’s take a scenario where you need to call multiple downstream services in resilient manner and expose the functionality as a another (composite) service. As shown in figure 1, with the ESB architecture, you can easily leverage the inbuilt capabilities of ESB, for building virtual/composite services and functionalities such as circuit breakers, timeouts and service discovery etc., which are useful during inter-service communication.

例如，让我们思考这样一个场景，你需要以弹性的方式调用多个下游服务，且将这个功能导出为另外一个（复合）服务。如下图 1 所示，通过 ESB 架构，你可以轻松利用 ESB 的内建能力来创建 虚拟 / 复合服务和功能，诸如熔断器、超时和服务发现等这些在内部服务间通信中非常有用。

When you implement the same scenario using Microservices, then you no longer have a centralized integration/ESB layer but a set of (composite and atomic) microservices. So, you have to implement all these functionalities at the microservices level.

当你使用微服务来实现相同的场景时，你不再拥有集中式 集成 / ESB 层，而是一组（组合 和 原子）微服务。因此，你必须在微服务层面来实现所有这些功能。

Therefore a given microservice which communicates with other services(figure 2), comprises of:

• Business Logic that implements the business functionalities, computations and service composition/integration logic.

• Network Functions that take care of the inter-service communication mechanisms (basic service invocation through a given protocol, apply resiliency and stability patterns, service discovery etc.) These network functions are built on top of the underlying OS level network stack.

因此一个给定的与其他服务有交互的微服务（如图 2 所示）由以下几点组成：

• 业务逻辑 实现业务功能，计算以及服务 组合 / 集成 逻辑。
• 网络功能 负责服务间通信机制（通过给定的协议进行基本服务调用，弹性请求以及稳定性模式，服务发现等。）这些网络功能基于操作系统底层网络栈构建。

Now think about the effort involved in implementing such microservice. Implementing the functionalities related service-to-service communication from scratch is a nightmare. Rather focusing on the business logic, you will have to spend a lot of time on building service-to-service communication functionalities. And this is even worse if you use multiple technologies to build microservices (such as multiple programming languages as shown in figure 1), because you need to duplicate the same efforts across different languages (e.g. Circuit breaker has to be implemented on Java, Node, Python etc.).

现在想想实现这种微服务所需的努力。从头开始实现服务到服务通信相关的功能是一场噩梦。而专注于业务逻辑，你将不得不花费大量时间来构建服务到服务间通信的功能。如果你使用多种技术来构建微服务（比如图 1 所示多语言的情况），那就更糟了，因为你需要在不同的语言中重复实现相同的功能（例如需要在 Java、Node、Python 等语言实现断路器。）

The most complex challenge in realizing microservice architecture is not building the services themselves, but the communication between services.

在实现微服务架构中最复杂的挑战不是构建服务本身，而是服务间的交互。

Since most of the inter-service communication requirements are quite generic across all microservices implementations, we can think about offloading all such tasks to a different layer, so that we can keep the service code independent. That’s where ‘service mesh’ comes into the picture.

由于大多数服务间通信需求在所有微服务实现中都非常通用，我们可以思考将所有这些任务都下沉到一个单独的层，以便我们可以保持服务代码独立。这就是图中 “Service Mesh” 所处的位置。

What is a ‘Service Mesh’?

In a nutshell, a Service Mesh is an inter-service communication infrastructure.

With a service mesh,

• A given Microservice won’t directly communicate with the other microservices.
• Rather all service-to-service communications will take places on-top of a software component called service mesh (or side-car proxy).
• Service Mesh provides built-in support for some network functions such as resiliency, service discovery etc.
• Therefore, service developers can focus more on the business logic while most of the work related to network communication is offloaded to the service mesh.
• For instance, you don’t need to worry about circuit breaking when your microservice call another service anymore. That already comes as part of service mesh.
• Service-mesh is language agnostic: Since the microservice to service mesh proxy communication is always on top to standard protocols such as HTTP1.x/2.x, gRPC etc., you can write your microservice from any technology and they will still work with the service mesh.

Let’s try to further understand the service interactions and responsibilities which are shown in figure 3.

“Service Mesh” 是什么？

简而言之，Service Mesh 是一种服务间通信基础设施。

通过 Service Mesh，

• 给定的微服务不会直接与其他微服务通信。
• 相反，所有服务到服务的通信都将在被称为 Service Mesh（或者 Side-Car 代理）的软件组件内进行。
• Service Mesh 为一些网络功能诸如 弹性、服务发现等提供内建的支持。
• 因此，服务开发者可以更加专注于业务逻辑，同时将与网络通信相关的大部分工作被下沉到 Service Mesh。
• 例如，当你的服务依赖另一个服务时，你不需要再担心断路的问题，这已经作为 Service Mesh 的一部分提供了。
• Service Mesh 是语言无关的，从微服务到 Service Mesh 代理通信通常基于标准协议诸如 HTTP1.x/2.x,gRPC 等，你可以使用任何技术编写你自己的微服务，一样可以跟 Service Mesh 很好的工作。

让我们尝试进一步理解下图三中的服务交互和职责。

Business Logic

The service implementation should contain the realization of the business functionalities of a given service. This includes logic related to it’s business functions, computations, integration with other services/systems(including legacy, proprietary and SaaS) or service compositions, complex routing logics, mapping logic between different message types etc.

业务逻辑

服务实现应包含给定服务的业务功能的实现。这包括商业功能相关的逻辑、计算、与其他服务 / 系统（包括遗留，专有和 软件即服务）或者服务组合，复杂的路由逻辑，不同消息类型间的映射逻辑等相关的逻辑。

Primitive Network Functions

Although we offload most of the network functions to service mesh, a given service must contain the basic high-level network interactions to connect with the service mesh/side-car proxy. Hence, a given service implementation will have to use a given network library(unlike the ESB world, where you just have to use a very simple abstraction)to initiate network calls (to service mesh only). In most cases, microservices development framework embed the required network libraries to be used for these functions.

原始网络功能

尽管我们将大部分网络功能下沉到了 Service Mesh，给定的服务必须包含与 Service Mesh / Side-Car 代理进行连接的基本的高级网络接口。因此，给定的服务实现必须使用给定的网络包（不像 ESB 世界中，你仅需要使用非常简单的抽象）来初始化网络调用（仅连接 Service Mesh）。在大多数场景下，微服务开发框架内嵌了这些功能需要用到的网络包。

Application Network Functions

There are application functionalities which tightly coupled to the network, such as circuit breaking, timeouts, service discovery etc. Those are explicitly separated from the service code/business logic, and service mesh facilitate those functionalities out of the box.

应用网络功能

存在与网络紧密耦合的应用功能，诸如熔断，超时，服务发现等。这些功能明确地与服务代码 / 业务逻辑隔离，并且 Service Mesh 促使这些功能开箱即用。

Most of the initial microservices implementations simply ignore the gravity of the network functions offered from a central ESB layer, and they implemented all such functionalities from scratch at each microservice level. Now they have started realizing the importance of having a similar shared functionality as a distributed mesh.

大多数初始微服务实现只是忽略了从中央 ESB 层提供的网络功能的重要性，并且它们在每个微服务级别都从头实现这些功能。现在他们开始意识到具有分布式网格类似的共享功能的重要性。

Service Mesh Control Plane

All service mesh proxies are centrally managed by a control pane. This is quite useful when supporting service mesh capabilities such as access control, observability, service discovery etc.

Service Mesh 控制平面

所有 Service Mesh 代理都被一个控制平面集中管理。在支持 Service Mesh 功能比如访问控制、可见性、服务发现等时，这非常有用。

Functionalities of a Service Mesh

As we have seen earlier, the service mesh offers a set of application network functions while some (primitive) network functions are still implemented the microservices level itself. There is no hard and fast rule on what functionalities should be offered from a service mesh. These are the most common features offered from a service mesh.

• Resiliency for inter-service communications: Circuit-breaking, retries and timeouts, fault injection, fault handling, load balancing and failover.
• Service Discovery: Discovery of service endpoints through a dedicated service registry.
• Routing: Primitive routing capabilities, but no routing logics related to the business functionality of the service.
• Observability: Metrics, monitoring, distributed logging, distributed tracing.
• Security: Transport level security (TLS) and key management.
• Access Control: Simple blacklist and whitelist based access control.
• Deployment: Native support for containers. Docker and Kubernetes.
• Interservice communication protocols: HTTP1.x, HTTP2, gRPC

Service Mesh 的功能点

正如我们之前所见，Service Mesh 提供了一组应用程序网络功能，而一些（原始）网络功能仍然在微服务层面自身来实现。没有硬性规定什么功能应该由 Service Mesh 来提供。以下这些是 Service Mesh 所提供的最常见功能。

• 服务间通信的弹性：熔断、重试和超时、故障注入、错误处理、负载均衡和故障转移。
• 服务发现：通过专有的服务注册中心来发现服务节点。
• 请求路由：原始路由功能，但没有与服务的业务功能相关的路由逻辑。
• 可观察性：度量、监控、分布式日志记录、分布式追踪。
• 安全：传输层安全（TLS）和秘钥管理。
• 访问控制：基于简单黑白名单的访问控制。
• 部署：容器的本地支持。Docker 和 Kubernetes。
• 服务间通信协议： HTTP1.X，HTTP2, gRPC

Service Mesh Implementations

Linkerd and Istio are two popular open source service mesh implementations. They both follow a similar architecture, but different implementation mechanisms. You can find a very good comparison between these two service mesh implementations at 1.

Servivce Mesh 实现

Linkerd 和 istio 是两个流行的开源 Service Mesh 实现。它们都遵循类似的架构，但是实现机制不同。你可以在 1 找到这两种 Service Mesh 实现之间非常好的对比。

Service Mesh — Pros and Cons

Let’s have a quick look at the pros and cons of service meshes.

Pros

• Commodity features are implemented outside microservice code and they are reusable.

• Solves most of the problems in Microservices architecture which we used to have ad-hoc solutions: Distributed tracing, logging, security, access control etc.

• More freedom when it comes to selecting a microservices implementation language: You don’t need to worry about whether a given language supports or has libraries to build network application functions.

Cons

• Complexity: Having a service mesh drastically increase the number of runtime instances that you have in a given microservice implementation.
• Adding extra hops: Each service call has to go through an extra hop(through service mesh sidecar proxy).
• Service Meshes address a subset of problems: Service mesh only address a subset of inter-service communication problems, but there are a lot of complex problems such as complex routing, transformation/type mapping, integrating with other services and systems, to be solved at your microservice’s business logic.
• Immature: Service mesh technologies are relatively new to be declared as full production ready for large-scale deployments.

Service Mesh — 优点和缺点

让我们来快速浏览一下 Service Meshes 的优缺点。

优点

• 通用的特性在微服务代码之外实现，使得它们可以被复用。
• 解决了过去微服务架构中大多数我们使用过临时方案解决的问题：分布式跟踪，日志记录，安全，访问控制等。
• 当选择微服务实现语言时更自由：你不需要担心给定语言是否支持或者已经有构建网络应用程序功能的库。

缺点

• 复杂度：使用 Service Mesh 会大大增加微服务实现中运行时实例的数目。
• 增加了额外的一跳：每个服务调用必须通过额外的一跳（通过 Service Mesh sidecar 代理）。
• Service Mesh 解决问题的一个子集：Service Mesh 仅仅处理了内部服务通信问题的一个子集，但是还有一些很复杂的问题诸如复杂的路由，转换 / 类型映射，与其它服务和系统集成等问题将在你微服务的业务逻辑中解决。
• 不成熟：Service Mesh 技术对大规模部署，宣布全面生产可用还相对较新。

Conclusion

In summary, service mesh addresses some of the key challenges when it comes to the realization of microservice architecture. It gives you more freedom to select a diverse set of microservices implementation technologies as well as to focus more on business logic rather investing more time on network functions between services. However, service mesh won’t solve any of the business logic related or service integration/composition related problems.

结论

总之，Service Mesh 解决了微服务架构落地的一些关键挑战。为你提供了更多自由来选择各种微服务实现技术，以及更多的专注于业务逻辑而不是在服务间网络功能上投入更多时间。但是，Service Mesh 不能解决任何业务逻辑相关或者服务集成 / 组合相关的问题。