微服务的服务网格

文章译者：suren

在过去几年内，微服务架构已经发展了很多，而且有很多新的概念和模式融合进来。”服务网格”的概念变得流行起来。在本文中，我计划介绍服务网格相关的概念，以及如何用在真实的微服务中。

为什么要有“服务网格”？

正如很多融合技术，微服务架构周围有很多是炒作。大多数人认为微服务是所有问题的答案，之前的架构包括：SOA/ESB。

然而，当我们观察真实世界中的微服务实现，我们可以看到大多数功能的支持现在已经在微服务层面实现，例如：总线（ESB）。所以，我们或多或少都在解决相似的基础问题，但是，我们是在微服务的不同方面来解决的。

图1：从集中集成/ESB到微服务

例如：让我们来看一个场景，你需要以弹性的方式来调用多个下游服务，并作为一个组合服务把这个功能暴露。

如图1所示,通过ESB架构，你可以轻松地发挥ESB内在的能力，对于构建虚拟、组合服务和功能，例如断路器、超时和服务发现等等，在内部服务通信中是很有用的。

当你用微服务实现相同的场景时，你不再需要一个集中集成、ESB，而是一套组合、原子微服务。因此，你不得不在微服务层面实现所有的这些功能。

图2：微服务组件和服务间通信

因此，一个给定的微服务与其他服务（图2），包括：

• 业务逻辑 实现业务功能，计算和服务组合、集成逻辑。
• 网络功能 处理内部服务通信机制（通过给定的协议启用基本服务，实现弹性、稳定、服务发现等）。这些网络功能是基于操作系统层面的网络。
• 现在想一下要实现这样的一个微服务需要付出的工作。从头开始实现面向服务通信这样的功能简直就是个噩梦。你将会不得不话大量的时间来维护面向服务通信功能，而不是关注在业务逻辑上。
• 而且，如果你使用了多种技术（例如图1中显示的多种语言）来构建微服务的话，甚至会更糟糕。 因为，你需要在不同语言上付出相同的精力（例如：熔断器不得用Java、Node、Python等语言来实现）。

实现微服务架构过程中最复杂的挑战不是构建服务本身，而是服务之间的通信。

由于大部分内部服务之间的通信需要是通用的，我们可以考虑把这种任务抽离到一个层上，我们就可以保证这个服务代码的独立性。这就是“服务网格”的由来。

什么是“服务网格”？

简单来说，服务网格也就是内部服务通信框架。在服务网格中，

• 在微服务中，不会直接和其他服务通信。
• 所有服务间的通信将会取代软件组件之间的调用成为服务网格（或 side－car 代理）。
• 服务网格默认提供部分网络功能，例如：弹性、服务发现等。
• 因此，服务开发者可以更多地关注业务逻辑，而大部分网络通信相关的工作交给来服务网格。
• 例如：当你的微服务调用其他的服务时，不用再担心断路器问题。那已经是服务网格的一部分了。
• 服务网格是语言无关的：服务网格代理通信对微服务来说建立在标准的协议之上，例如：HTTP1.x/2.x, gRPC等,你可以用任何技术来写你的微服务，都是可以兼容服务网格。

图3：通过服务网格实现服务间通信

让我们进一步了解图3所展示的服务交互和责任。

业务逻辑

服务的实现应该包含业务功能。这包括：业务相关的逻辑，计算，和其他服务、系统或者服务的集成，复杂的路由逻辑，不同消息类型间的映射逻辑等。

原始网络功能

尽管我们把大部分网络功能都交给了服务网格，但服务还是必须包含和服务网格或者 side-car 代理之间基本的高级网络交互。

因此，服务的实现必须使用特定的网络库来初始化网络（只是对服务网格的）调用。大多数情况下，微服务开发框架都嵌入了必要的网络库。

应用网络功能

还有一些应用功能和网络紧耦合，例如：断路器、超时、服务发现等。那些已经明确地从服务代码、业务逻辑中分离，并且服务网格使得这些功能开箱即用。

大多数初期的微服务实现简单地忽略了从中央 ESB 层提供的网络功能，他们从服务层面粗糙地实现了这些功能。现在他们已经开始意识到有一个类似网格这种分享功能的重要性。

服务网格控制层面

所有服务网格代理都是由控制面板集中管理。当需要支持访问控制、服务发现等能力时，这就是很有用的。

正如我们之前看到的，服务网格提供了一套应用网络功能，一些（原始的）网络功能依然是作为微服务本身实现的。

没有固定和快速的规则来说明哪些功能应该由服务网格提供。大多数通用的特性是由服务网格提供的。

• 内部服务间的弹性通信：断路器、重试和超时、故障注入、故障处理、负载均衡和故障切换。
• 服务发现：通过服务注册表发现服务断点。
• 路由：原始的路由功能，没有业务相关的路由逻辑。
• 可观测性：指标、监控、分布式日志、分布式跟踪。
• 安全：传输层安全（TLS）和 key 管理。
• 访问控制：基于访问控制的简单的黑名单和白名单。
• 部署：原生支持容器。Docker 和 Kubernetes。
• 服务间通信协议：HTTP1.x，HTTP2，gRPC

服务网格实现

Linkerd 和 Istio 是两个流行的开源服务网格实现。它们的架构相似，但实现机制不同。你可以在这两个服务网格的实现上做个比较。

服务网格 － 赞成和反对

让我们快速地对比下对服务网格的两个观点。

赞成

• 特点是在微服务代码之外实现，具有可重用性。
• 解决了我们过去在微服务架构中的点对点方案：分布式跟踪、日志、安全、访问控制等等。
• 在选择微服务实现语言上有了更多的自由：你不用担心是否选择的语言是否支持或者是否有构建网络应用功能的库。

反对

• 复杂：在微服务实现中，如果有服务网格的话会增加很多运行实例。
• 增加了额外的跳跃点：每个服务调用不得不通过一个额外的跳跃点（通过服务网格 sidecar 代理）。
• 服务网格解决了一部分问题：服务网格仅仅解决了内部服务通信的一部分问题，但要解决你的微服务中的业务逻辑，还有很多复杂的问题，例如：复杂路由、类型转换映射、于其他服务和系统的集成。
• 不成熟：要作为产品进行大规模部署的话，服务网格技术相对较新。

总结

总体来说，服务网格在微服务架构中解决了一些关键的挑战。它让你在选择微服务实现技术上有了更多的自由，让你可以更多地关注在业务逻辑上，而不是服务间的网络通信上。然而，服务网格解决不了任何业务逻辑相关的问题，或服务集成、组合的相关的问题。