服务网格

微服务的自然演进

引言

服务网格是当前最热门的技术之一，服务网格代表了从集中式架构向分布式架构过渡的下一个创新飞跃。尽管如此，我们认为服务网格的相关新技术可能是以新颖的方式包装了现有技术。借助服务网格，我们将采用传统 API 网关的功能，并以全新的模式进行部署。

随着微服务、容器化和 serverless 的发展，我们可能都已经非常熟悉了从大型整体服务，到更小的、更敏捷的服务的转变。尽管如此，对于我们大多数人而言，要准确地了解什么是服务网格，以及它如此令人兴奋的原因，可能是一个挑战。在适当的上下文中理解服务网格需要了解从单体应用到微服务的演变。

从单体应用到现代架构

为了解决这个问题，我们中许多人开始解耦单体应用，转而使用以 API 为中心的企业架构，公共和私有服务的粒度也变的越来越小。容器的兴起使我们可以将服务抽象到距离虚拟机更高一层的位置，这更加加速了这种趋势，服务的粒度变的更小。最终的结果是我们将单体应用解耦为可独立运行的小组件。

服务网格1.png

随着 Docker 和 Kubernetes 等工具的日益普及，我们看到容器化的进程越来越快。

这些工具使分离服务变的更加容易，有了它们，我们可以分离服务的运行，并将它们隔离开。本质上，Docker 和 Kubernetes 提供了足够的工具支持主流实现，尽管像 Netflix 和 Amazon 这样的公司在没有这些工具的情况下进行了转型，它们解耦单体应用的过程更具挑战。

服务网格2.png

从南北向到东西向

在老的单体应用架构中，我们几乎只处理南北流量，但是对于微服务，我们必须越来越多地处理数据中心内部的流量。对于单体应用来说，不同的组件之间通过调用应用内部的方法来通信。边缘网关（Edge gateways）抽象了常见的流量协调功能，例如身份验证，日志记录和限流，但是在单体应用范围内进行的通信不需要这些活动。

服务网格3.png

由于现在的方法调用通过网络通信完成，东西向流量带来了更大的挑战。我们可以使用所需的任何传输方法进行通信，架构内的不同服务彼此间不必了解，服务间充满了很大的灵活性。这提供了很大的优势，例如，我们是一个大型组织，假设收购了另一个团队，我们就不必担心他们使用的编程语言和他们的工作方式。但是，由于网络具有延迟并且本质上不可靠，因此，网络比方法调用会产生更多的问题。

传统网关的挑战

随着微服务产生的东西量流量逐次增加，我们需要具备编排它的能力，这与我们解决单体应用的边际问题类似，我们需要有效地路由流量，但是现在所有常用功能（如路由、身份验证和日志记录）都是菊花链（daisy-chained）式的。这种复杂性导致传统网关无法很好地处理东西向流量，必须使用粒度更细，更灵活的网关。

服务网格4.png

对于微服务而言，每个服务有多个实例，这导致我们必须在服务发现处理更大的复杂性。我们的服务需要知道在哪里发送请求，网络是否可靠，如何处理过多的延迟，错误处理以及其他问题。我们需要确定我们可以有效地解决这些问题，因为随着服务数量增加，挑战将变得更加复杂。

代理、网关和服务网格的基础

为了使我们的服务粒度越来越细，我们增加了对东西向流量的需求，从业人员开始寻找解决方案。最初，我们许多人认为可以为每个微服务使用相同的客户端库，但是，这个方案很快就放弃了，该解决方案失败的主要原因是，它大大削减了微服务的内在价值。使用客户端库，每次更新服务时都需要重新部署服务，这降低了部署速度并增加了故障风险。更糟糕的是，我们需要限制每个团队使用的技术栈，因为我们只使用单个客户端库。可以想象，我们也可以使用其他语言构建客户端库，但这很快就变的不切实际，因为这会相当难以维护。
由于高延迟会导致体系结构失败，所以但客户端解决方案不可行。
为了解决这些问题，我们可以简单地添加一个代理。该解决方案将关注点从工程转移到了 DevOps，这样工程团队可以专注于改善服务。代理进程与每一项服务同时运行，并抽象出关键的流量管理功能，每当我们发出请求时，请求都会通过我们的代理，并且代理会处理可能出现的任何问题。如果我们的网络不可靠或延迟太高，代理将确保我们可以重试或修复不起作用的服务。
这使我们可以从代码库和开发团队中抽象出流量路由和管理功能。而服务开发团队不需要担心网络问题，因为代理可以处理这些问题，在部署代码时，需要将代理注入我们的服务中。

服务网格的构成 - Sidecar

为了降低将代理注入到服务的复杂性，即创建了 sidecar 模式。Sidecar 利用了由容器编排工具（如 Kubernetes）创建的抽象层，这个抽象层存在于我们的容器与运行容器的虚拟机之间，它使我们的虚拟机看起来像一个单一的结构，使用 Kubernetes 时，我们可以让一个容器成为另一个容器的 Sidecar 代理，从而使 Sidecar 能够独立与运行服务的容器处理网络通信，这构成了我们服务网格的基础。

服务网格5.png

随着网格不断增长，Sidecar 代理可以随着我们不断增长的微服务数量一同有效扩展显得至关重要。在容器化的世界中，我们正在不断缩小服务粒度，这要求 Sidecar 代理必须轻巧和快速。由于我们迫使 Kubernetes 将两个容器都推送到同一台主机上，以最大程度减少服务容器与 Sidecar 代理之间发生通信问题的可能性。如果代理服务太大，则将使基础虚拟机负载过重，如果代理服务太慢，则会带来延迟的风险，过渡到服务网格需要进行微调优化性能，因此我们必须能够准确诊断可能出现潜在问题的位置，

了解服务网格

随着服务之间东西向 API 调用的数量呈指数级增长，我们了解延迟性能的能力变的至关重要。幸运的是，服务网格的体系结构非常适合跟踪性能。每个 Sidecar 代理都充当代理和反向代理，分别是用于主站通信的代理和用于入站的反向代理，由于我们的 Sidecar 同时具有两种功能，因此它知道何时发送通信以及何时接收通信，从而为我们提供了开箱即用的遥测技术。这使我们能够在流量离开或者进入某一项服务时对其进行筛选。

控制服务网格

与任何架构创新一样，服务网格在尽显优势的同时也带来了新的挑战。我们必须解决的第一个问题是如何配置所有代理，例如我们想将订单与发票之间的服务通信时间从10秒改为5秒，我们如何在不重新部署 Sidecar 代理的每个实例的情况下做到这一点，答案在于我们如何分离数据层（data plane）和控制层（control plane）。

服务网格6.png

以最简单的形式说明，数据层和控制层可以这么理解：数据层是在服务执行路径上，服务至服务请求间的任何内容；控制层将配置推送到数据层。就我们的服务网格而言，我们将在控制层对给定的配置进行更改，并且将更改推送到我们的 Sidecar 代理中。由于我们的控制层可以识别与每一项服务相关联的代理实例，因此我们可以快速对我们的每一个代理配置进行大规模的更改，但不会中断我们的服务。

总结

服务网格为我们提供了与传统部署方式的子集，使我们可以更好地处理微服务架构中所产生的东西向流量。我们的服务网格代理可以收集遥测，处理路由和错误处理，并以传统网关多年来处理南北流量的方式来限制对我们的访问。本质上，我们使用的是相同的技术和功能，只是部署在不同的实现中。

服务网格7.png

对于传统企业来说，不可能有一个单一的主导实施范例。过渡到新架构模式有固有的风险和破坏性，不是瞬间就能切换到共有云，或者采用服务网格的。但是，随着分布式的场景越来越多，网格网格的泛用性越来越高。尽管如此，最有可能发生的情况是，当我们过渡到分布式体系结构时，我们仍将依靠使用传统体系结构构建的应用程序来提供服务。这使得打造一个旧式架构和现代架构有效结合的 API 管理平台成为数字化转型过程中的关键一步。