Service Mesh 的未来在于网络

长期以来，服务网格（Service Mesh）一直被认为是云原生的未来，能够实现一些新的特性，比如金丝雀部署、故障转移和 mTLS，同时还能支持一些“传统的”网络特性，如流量路由、可观测性、错误处理和故障排查等。

服务网格承诺将网络安全、服务发现和渐进式的交付实践（如蓝 / 绿和金丝雀部署）转变成开发人员的自助服务接口。但是，当我们从营销炒作转到实际实现时，会发现完全不同的情况。

在最近的 CNCF 服务网格调查中，人们反映采用它的主要障碍在于缺乏工程专业知识和经验、架构和技术的复杂性，以及缺少指导、蓝图和最佳实践。

为了辅助理解新技术，通常更容易的做法是将新模式与现有的特性和功能关联起来，以构建一个共同的词汇表和起点。在服务网络中，可以类比的就是网络。

如果将服务网格看做分布式计算中的网络层，那么我们就可以从传统网络的建立、实施和采用中学到很多经验。

以此作为跳板，我将深入介绍我们在构建 Cilium 服务网格时的经验，以及服务网格嵌入到网络栈中之后会如何演进的启示。

我们将会发现，正如 David Mooter 所言，“服务网格的未来会作为一种网络特性，而不是一类产品，并尽可能远离开发人员的视线和思维，这会是一件好事儿”。

图 1：服务网格将会成为网络栈的另一部分

在深入介绍未来之前，我们先跳回过去，了解分布式网络是如何形成的。在分布式网络中，最大和最著名的例子是 TCP/IP。虽然我们今天已经对此习以为常，但是情况并非总是如此的。

在它成为互联网的基石之前，TCP/IP 最初是作为 DARPA 的一个附属项目开始的。在“协议大战（Protocol Wars，TCP/IP 与 OSI）”期间，众多的工程师、公司，甚至国家都在争论使用哪种通信协议来连接计算机网络。OSI 被很多组织实现了“标准化”，包括美国国防部（DoD）。但是，随着越来越多的公司开始连接网络，TCP/IP 快速成为人们连接计算机和网络的新兴标准，因为它早就已经实现了（包括 BSD 中的开源实现），并且业已可以使用。人们优先考虑的是可用的技术，并采用今天就能实现的技术，而不是所谓的“选定”的解决方案。

这些相互竞争的用户空间（user-space）实现，最终让位于内核中的 TCP/IP 栈的实现。现在，如果给大多数的运维团队提供一个不包含 TCP/IP 的内核，那将是一件非常离谱的事情，因为 TCP/IP 已经被视为网络的基础组成部分，任何人都可以依赖它。因为它在数以亿计的设备上运行着，Linux 内核 实现已经发现并修复了在用户空间重写自己的 TCP/IP 时可能遇到的边缘情况。人们再一次选择了可行并且能够理解的技术。

即便是一些特殊的使用场景，如延迟或性能敏感的工作负载，实现自己的 TCP/IP 栈也没有了足够的动力。你可以在 Cloudflare 的博客中看到这种进展，他们从编写“内核旁路（kernel bypass）” 转变成了 “我们为何使用 Linux 内核的 TCP 栈”。Linux TCP 栈有很多关键特性和非常好的调试能力。要想和这个丰富的生态系统进行竞争，还需要很多年时间。由于这些原因，用户空间的网络不太可能成为主流。

人们对于像网络这样的关键应用，始终希望有可靠的技术，而且在任何地方均可使用。

图 2：TCP/IP 之所以能够获胜，是因为它已经实现了

Cloudflare 并没有停留在仅仅使用 Linux TCP/IP 栈上。“eBPF 正在吞噬软件”似乎成为了新的格言。而且，他们并不是独行者。自 2017 年以来，进入 Facebook 数据中心的所有流量均要经过 eBPF，而谷歌的大部分流量也是如此。实际上，如今有大量的公司正在生产环境中使用 eBPF。如果我们说，人们想要稳定的技术，那么他们为何转向 eBPF 来满足其网络需求呢？

由于 Linux 内核在数以亿计的设备中被广泛采用，因此，进行变更，尤其是像对网络这样的核心功能进行变更，是不能掉以轻心的。一旦做出变更，供应商还需要数年的时间来测试和采用新的内核版本，才能投入面向终端用户的生产环境。但是，向 iptables 这样的传统网络技术并不能满足动态云原生环境的需求。

谷歌、Facebook、Cloudflare 和其他公司转向 eBPF，这是因为它有助于解决他们大规模网络的问题。从增加数据包的吞吐量，到 DDoS 缓解和持续采样（profiling），eBPF 使他们能够几乎实时地将所有功能添加到内核网络中。他们现在可以同时为数十亿用户提供服务，缓解每秒钟 2600 万次的 DDoS 攻击，而无需手动设置服务器名称和 iptables 规则。现在，它随着 Cilium 得到了广泛采用，Cilium 是一个基于 eBPF 的容器网络接口（CNI，Container Network Interface），成为了所有主流云供应商的默认 CNI。

eBPF 已经成为了内核网络的新标准，因为它带来了超强的能力，使网络能够动态增加新的特性，并支持扩展以满足用户的需求。

图 3：网络转移到了内核中

到目前为止，我们已经阐明，人们采用某项技术是因为它解决了一个直接的需求，而不是从上到下的需求。这自然会引出一个问题，服务网格解决了什么问题？

简而言之，服务网格就相当于现在分布式计算中的动态链接器。在传统的编程中，要包含另外一个模块，将会涉及到将一个库导入到 IDE 中，在部署时，操作系统的动态链接器在运行时会将我们的程序与这个库连接在一起。链接器还会处理库发现、安全验证和建立连接等问题。

在云原生环境中，我们如今的“库”就是一个对其他微服务的网络跳转。寻找“库”并建立安全连接就是服务网格的问题。与之类似，对于动态链接器，只有一份库的副本，对于服务网格，每个节点只有一个 Envoy 或 eBPF 程序。对开发或运维团队来说，考虑动态链接器是没有太大意义的，那么他们为何要关心复杂的服务网格呢？

服务网格已经成为了一流的基础设施，因为它们有助于在应用层解决动态分布式计算环境中长期存在的复杂问题。但是，服务网格并不应该因此就固步自封。

即便不深入研究上面调查所列出的问题，服务网格也有额外的问题，它们只能通过网络来解决。由于服务通常使用应用层（OSI 第 7 层）协议，如 HTTP，可观测性数据往往被限制在该层。然而，问题的根本原因可能在另外一层，而这层通常对可观测工具是不透明的。我们赖以连接基础设施的服务网格突然看不到发生了什么。它必须做出改变。

图 4：将服务网格转移到内核中

服务网格是为了解决云原生领域的网络问题而创建的，但是正如前文所述，它也有自己的问题。我们想要的是两全其美的效果，“传统网络”为我们提供第 3-4 层的可观测性、上下文和控制，服务网格则处理第 7 层的 API 通信。

幸运的是，我们已经看到这两个层正在逐渐走到一起，而且随着 eBPF 的出现，这种趋势只会加速实现。如果将服务网格连接至网络中，那么我们就能够在所有的网络层上拥有完整的上下文和控制，并改善环境搭建、运维和问题排查。我们以 Isitio 和 Cilium Service Mesh 为例，深入了解它们是如何实现这一目标的。

Istio 正在实现服务网格向网络方向发展。借助 Merbridge 和 Ambient Mesh，Istio 正在努力增加更多的网络功能，并减少对 sidecar 实现网络功能的依赖。

Merbridge 通过使用 eBPF 取代 iptables 来加速 Istio 的网络。“使用 eBPF 能够极大的简化内核对流量的处理，使服务间的通信更加高效”。Merbridge 没有依赖 sidecar 的网络栈，而是使用 eBPF 将数据包从 sidecar 传递到 pod，以及从 sidecar 传递到 sidecar，而不需要经过它们的整个网络栈。Merbridge 通过将网络从服务网格转移到内核来加速网络传输。

Istio 最近还推出了 Ambient Mesh，这是一个无 sidecar 的服务网格，目的是减少 sidecar 造成的运维复杂性、资源利用率低和流量中断。Ambient Mesh 将 L7 的处理转移到每个命名空间的“waypoint proxy”，并尽可能利用第 4 层处理。这会将“服务网格功能”转移到更低的网络层，只有在其他方式不可行的情况下，才会依赖服务网格。将服务网格添加到网络中减少了资源和运维的开销。

在为 Cilium 工作时，我们也看到了将服务网格转移至网络中的趋势。Cilium 的“第一个服务网格”只是与 Istio 的集成。Cilium 实现了 CNI 第 3-4 层的网络和网络策略，而 Istio 处理第 7 层的功能。基于这些经验，我们意识到，Cilium 对网络实际发生的情况能够有更多的了解，并且有更好的原语（primitive）来控制网络，因为它在内核中运行，能够看到机器上发生的所有事情。

同时，终端用户的请求也能看到 Cilium 增加的一些特性，而这些特性通常是关联到服务网格上的，比如多集群网格和 egress 网关，因为网络团队认为它们只是应用程序联网的方式而已。当整体来看的时候，我们发现 Cilium 已经建成了 80% 的“服务网格”。只不过，它们是 Cilium 已包含的网络的一些常规组成部分。

内核中唯一缺少的部分是更高级的第 7 层功能，如 HTTP 解析和 mTLS，这些功能目前被委托到了用户空间中。然而，eBPF 可以将更多的这种特性转移到内核中。Cilium 的下一个发布版本将会包含 mTLS，并且业界已经有多个使用 eBPF 的 HTTP 解析的实现。虽然不是所有的功能都能在 eBPF 中实现，Cilium 将继续为第 7 层场景的子集提供 Envoy，但是有了 eBPF 之后，很多服务网格的特性现在已经转移到了各种网络中。

图 5：从第 1 层到第 7 层的 eBPF 服务网格

随着服务网格成为网络的一部分，合并后的优势主要体现在标准化、集成和运维方面。

首先，我们可以通过将服务网格和网络结合在一起，实现标准化和跨层的传播上下文。在 Kubernetes 中，通过 Gateway API，我们可以看到这一点正在变成现实。OCI 为容器运行时提供了一个标准，并能根据需要互换容器运行时，与之类似，Gateway API 提供了一个标准的方式来实现 Kubernetes 中的网络。标准化允许消费者为自己选择最好的实现方式，在这种情况下，将网络和服务网格结合到一个连接层将会更加容易。

其次，一旦实现标准化，一个集成的生态系统就可以开始成长起来。对于增加新的或额外的特性，生态系统是一种很好的方式，因为它们提供了一致的集成点。更重要的是，标准化会推进与传统工作负载环境的集成，特别是与网络的集成。根据我们与客户合作的经验，企业会需要企业级的网络。这意味着，除了简单的 HTTP 请求之外，还需要额外的协议和复杂的网络拓扑结构。能够集成到这些具有不同要求的环境中，是确保服务网格在未来的网络中还能长足发展的重要原因。

最后，没有人喜欢调试网络。为什么要将它分为两个独立的层，而且在出错时，这两个层以及它们之间的接口都需要进行调试呢？将服务网格与网络结合起来，这会使得运行、运维和调试都更加容易，因为所有的上下文和问题都在同一个地方，而不是泄露到其他抽象层中。我认为，我们可以确信地说，平台连接的管理和运维将会完全由平台和网络团队负责。在网络连接的每一层都能讲述一个完整的连接故事，这对于网络和服务网格未来的组合将会至关重要。

虽然关于组合网络和服务网格的最佳实施方案依然还在争论中，但是当它实现后，将会有许多令人兴奋的机会出现在我们面前。使用 OCI 将容器标准化之后，我们就可以创建新的运行时、将容器添加到注册中心以供发现，并且能够在生产环境中编排它们。今天，运行容器并没有什么特别之处，仅仅是计算的一部分而已。

我期待同样的事情也能发生在服务网格上。它是网络的另一个组成部分，使我们能够为微服务、应用程序和工作负载提供从第 1 层到第 7 层的完整连接，它只需完成自己的工作就可以。作为网络的一部分，服务网格会有一个光明的未来，尽可能远离开发人员的视线和思维，这是一件好事儿。

原文链接：

The Future of Service Mesh Is Networking(https://www.infoq.com/articles/service-mesh-networking/)

相关阅读：

Service Mesh 的演化与未来|InfoQ 大咖说 (https://www.infoq.cn/video/fi42NCGpVkJSDm2MXUbB)

Service Mesh 发展趋势：云原生中流砥柱 (https://www.infoq.cn/article/Q0e8wDgwRNTcmNb2PDJo)

美团点评的 Service Mesh 实践及落地难点解析 (https://www.infoq.cn/article/MVdj3mA9oY85je8Zymi6)

声明：本文为 InfoQ 翻译，未经许可禁止转载。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！