什么是服务网？服务网是一个系统，它承载着微服务之间的请求和响应。这些流量最终会以同样的方式从Pod传到Pod，但通过服务网层，可以实现更高级的观察和控制。将服务网视为一个更智能的网络。

服务网格处于云原生基础设施的最前沿。正如Kubernetes彻底改变了计算--服务的执行--服务网格是网络的一个巨大增值。它们还取代了许多过去发生在应用程序代码中的模板，但这些模板最好由基础设施来完成。

就像Terraform这样的项目让基础设施团队的生活变得更好一样，服务网格是微服务开发者和所有者可以用来更好地操作他们的应用程序。服务网格还能增强这些应用的功能，提供真正的顶层价值，而不仅仅是节约成本。

操作

服务网格的内部运作在概念上相当简单：每个微服务都有自己的本地HTTP代理。这些代理执行所有定义服务网的高级功能（想想反向代理或API网关所提供的那种功能）。然而，在服务网状结构中，这些功能是分布在微服务的各个代理之间的，而不是集中在一起。

在Kubernetes环境中，这些代理可以自动注入到Pod中，并可以透明地拦截所有微服务的流量；不需要对应用程序或其部署YAML（Kubernetes意义上的术语）进行修改。这些与应用程序代码一起运行的代理，被称为侧线。

这些代理构成了服务网的数据面，即数据--HTTP请求和响应--流经的那一层。但这只是难题的一半：为了让这些代理做我们想做的事，它们都需要复杂而单独的配置。因此，一个服务网还有第二部分，即控制平面。这是一个（逻辑的）组件，它计算并应用配置到数据平面的所有代理。它为我们这些终端用户提供了一个单一的、相当简单的API。我们用它来配置作为一个逻辑整体的服务网（例如，服务A可以与服务B对话，但只能在路径/foo上，而且只能以10qps的速率进行），它负责配置各个侧翼的细节（在这种情况下，识别侧翼与服务B一起，配置它以识别哪些请求来自服务A，并应用其速率限制和ACL功能）。

讯享网任何HTTP代理实现都可以用于边卡（尽管它们都有不同的功能）。然而，像Envoy这样的现代代理是非常合适的，因为它们可以通过网络API进行配置和重新配置，而不是消耗配置文件。它们还被设计成在重新配置过程中不丢弃流量，这意味着不间断的服务。

特点

可观察性

实施服务网的一个直接好处是增加集群中流量的可观察性。

Lyft是服务网格领域的先驱之一（也是Envoy的作者！），这也是他们谈到的立即获得的一个好处。

由于对我们服务的所有请求都是通过侧车运行的，他们处于一个完美的位置，可以产生日志、指标和跟踪跨度，记录他们看到的情况。当然，这不是服务不能做的事，但现在他们不必再做了。为所有的工作负载生成一致的标记的统计数据，不需要服务中的代码，所有的统计数据都被发送到同一个中央收集点（如Prometheus服务器）。这意味着，例如，现在有一个地方可以看到所有服务的p99延迟，这意味着你可以很容易地发现异常值。因为这些是HTTP代理，它们在第7层产生这些统计数据--例如，按HTTP路径和方法细分的延迟。值得一提的是，尽管HTTP是迄今为止最常用的第7层协议，而且服务网格也很好地支持它，但它不是唯一的协议。根据服务网，也就是它的代理实现，大多数可以看到HTTP的 "内部"，以提供gRPC的统计数据，以及了解其他TPC协议，如postgresql和Kafka。

Kiali软件连接到一个Istio实例，显示了几个微服务的实时调用图。在右边，你可以看到所选评论服务的流量成功和速率指标。

分布式跟踪跨度显示一个用户请求到上面显示的相同微服务的所有流量。

这第一个功能是 "免费 "的：只要注入侧边设备，让流量通过它们，就可以观察到了。尽管如此，还是有一些注意事项需要注意。

首先，跟踪事件是在每个服务的入口和出口处自动产生的，但要把它们归结为有用的跨度，服务必须转发一组跟踪头信息。这需要应用程序代码的配合，转发必要的头文件。

第二点是侧车确实对性能有一些影响，因为每一个额外的跳入和跳出侧车的请求和响应将不可避免地增加一些延迟。我不会在这里引用任何数字，因为它们都是针对具体环境的，而且很快就会过时，但关于这个问题的好的独立文章确实存在，而且你最好的选择是在你的环境中测试你的用例，并将结果与你的性能要求进行比较。

我们还应该注意到，代理的处理速度对带宽（qps）有一个理论上的限制，但这很可能不是一个问题，因为你的服务会更慢，除非它们是高度优化的（或用Rust写的😉）。

路由

如果说之前的Observability功能是 "被动 "的，那么现在我们要做的是 "主动 "的Service Mesh功能。这些动作默认不采取，因为它们会干扰流量，但如果你选择配置它们，在构建微服务系统时，它们可以提供巨大的力量和灵活性。

由于每一跳流量都会通过其数据平面，服务网可以以复杂的方式在微服务之间路由流量。例如，下面的YAML将配置Istio服务网，拦截所有前往service-b的流量，将90%发送到现有的版本，10%发送到新的测试版本（destination.host项是Kubernetes服务）。

 apiVersion: networking.istio.io/v1beta1 kind:虚拟服务元数据： 名称：服务-b 规格： 主机： - 服务-b http： - 路由： - 目的：主机：服务-b-v1 重量： 90 - 目的：主机：服务-b-v2 重量： 10

这些百分比可以按你的要求精确：例如，运行1个v2 Pod和99个v1 Pod以获得1%/99%的比例，这种原始的Kubernetes "黑客 "是不需要的。有了第7层路由，就有了无数的可能性。其他例子包括

• 检查HTTP头并发送，例如，只发送带有Accept-Language: en-GB的人到v2，因为也许我们还没有机会翻译我们的新版本，只想把它发布给讲英语的人。
• 将某一HTTP路径的GET请求路由到缓存服务层

弹性

随着从单体到微服务的转变，过去的简单函数调用现在变成了网络请求。函数调用实际上是无懈可击的，而且是即时的。另一方面，网络请求可能失败，部分成功，和/或非常缓慢。由于级联故障会带来巨大的问题，我们的服务需要能够应对和控制这些问题，而不是在整个系统中级联故障。理想情况下，事情会在微观和宏观层面上优雅地退化。有了服务网，这就不需要在每个微服务中编码了--这不是一个业务逻辑问题，所以把它推迟到基础设施中是最好的，我们可以简单地配置服务网，使微服务在面对故障时表现正确。例如，这个Istio配置片段在 "service-c "上执行了1s的超时：如果 "service-c "在1秒内没有回复其调用者，服务网将进行干预，中止请求并向调用者返回HTTP 504（表明作为网关的代理已代表调用者对请求进行了超时）。这使调用的应用程序代码不必管理自己的请求超时和最后期限。

讯享网 apiVersion: networking.istio.io/v1beta1 kind:VirtualService元数据：名称：service-c规格：hosts：-service-c http：- route：- destination：host：service-c timeout。1s

应对超时和来自服务的错误（faults）的反面是注入它们。这听起来很奇怪，但是当我们把单体分割成微服务时，我们把一个自成一体、可能是同步的系统变成了一个分布式系统。分布式系统是很难的，保证其可靠性的方法之一是测试可能发生在它们身上的各种问题，现在包括对网络调用的错误（HTTP状态500）、丢失或延迟的响应。服务网可以注入这些故障，使我们能够在受控条件下测试系统对故障的反应。比方说，我们想发布一个新版本的服务：我们可以让它发出的请求有50%的时间返回错误，另外50%的时间超时。它所调用的服务并没有那么多的错误（我们希望如此！），但是我们可以模拟一下，看看我们的新版本在一个非常糟糕的日子里会如何应对。我们还可以通过设置头信息x-testing: true，只为选择测试的请求注入故障。同样，可能性几乎是无穷的。我们甚至可以一直以较低的速率向生产环境网络注入故障，类似于为计算工作负载运行一个混沌猴子。这里的想法是，如果一个服务的下游太可靠，它的作者就会对处理错误感到自满，所以我们要确保他们永远不会看起来100%完美，无论他们的团队做得多好。

安全性

最后，但绝对不是最不重要的，服务网格可以大大改善你的网络和服务的安全性。虽然HTTPS对于客户通过互联网连接到我们面向外部的服务是无处不在的，但我们大部分的内部网络（包括Kubernetes集群）都使用明文HTTP。这是基于这样的假设，即我们不需要在我们的周边地区的安全，因为它是不可穿透的。这其中隐含的假设是，我们集群中的所有Pod也是100%可信的，不会试图访问任何他们不应该访问的东西。随着供应链攻击所带来的威胁越来越大，这种情况比以前要少得多。解决方案是一种叫做 "零信任"的方法，这基本上说明内部服务被视为不受信任的客户，就像互联网上的任何随机设备一样；它们不会因为在我们的网络上而获得特殊的权限。服务网可以执行零信任所需的安全策略。

首先要做的是对网络上的所有流量进行加密，这样它就不会被一个被破坏的工作负载所嗅到。我们可以通过使用HTTPS来做到这一点。这在概念上很简单，我们只需要每个服务有一个TLS证书，这样它就可以提供TLS服务，而客户需要一个证书授权的副本，这样他们就可以验证它。然而，如果你曾经试图在你的服务中推广这一点，你就会知道，向服务分发和轮换单个证书是一场噩梦，但在服务网中，这并不是应用程序必须管理的事情。他们可以谈论纯文本的HTTP（作为客户和服务器），挎包代理将升级为HTTPS，即服务器端代理通过提供TLS证书提供HTTPS服务，客户端代理在进行连接时验证。服务网的控制平面负责生成、分发和旋转这些证书。有了像Envoy这样的现代代理，证书可以通过API调用进行即时更新，这意味着没有停机时间来旋转证书。我们还可以将访问控制委托给服务网。假设你正在运行一个网络商店：订单微服务是至关重要的--它可以用来创建和操作订单，将你的股票发送到世界上任何地方。你还有一个小服务，可以查找用户的个人资料图片，在他们登录时显示出来。这个个人资料图片服务与订单服务没有任何关系；任何试图这样做的行为都是一个错误，或者更糟的是一个安全漏洞。为了防止这种情况的发生，我们可以对两者进行防火墙。与其使用KubernetesNetworkPolicy（它适用于钝的Pod-to-Pod级别），我们可以让profilepicture从orders的计数端点GET，例如，在订购了10件或更多东西的人的照片上显示一个金环。同时，我们可以防止读取任何其他路径，或对任何路径的POST访问。

不仅仅是调用工作负载的身份决定了是否应该授予访问权；我们还想看看是哪个终端用户在试图提出请求。当我们的用户登录到我们的移动应用时，发送的每个API请求在HTTP授权头中都有一个JWT。如果我们的服务转发这个字段，那么我们集群中的每个服务都可以知道这个请求是代表哪个终端用户的。JWTs需要验证（它们由私钥签署），我们可以将其推迟到服务网--用相应的公钥配置它--无效的JWTs请求将根本不会到达服务。

由于所有的JWTs都被保证是有效的，它们的声明可以被用来进行访问控制。就像profilepicture不能访问订单的大部分API一样，我们可以防止不在gold_member组的人向订单的/discount路径发出请求。这是另一个例子，我们的应用程序不必包含模板代码来执行JWT验证和访问控制等常见操作，尤其是众所周知的安全代码的微妙之处。

其他用例

上述服务网状结构的功能往往可以满足我们的用例，直接解决可观察性、流量控制、弹性和安全性的要求。此外，许多Service Mesh产品都有一些额外的功能，并不那么容易归类，而且几个功能可以组合起来做更多有用的事情。这方面的一些例子有。

• 协议规范化：有一个gRPC服务需要被一个只能说 "REST"（JSON/HTTP）的web应用调用？服务网可以透明地将一种编码转换为另一种编码。
• 拓扑感知路由：想通过将请求发送到物理上离发起者最近的部署中的Pod来节省云成本和延迟？服务网的控制平面知道所有事情最终安排在哪个节点上，以及这些节点彼此之间的关系（通过查询Kubernetes的API）。利用这些数据，它可以配置所有的侧车，使其更喜欢他们试图调用的任何服务的本地实例，在出现错误的情况下回落到更远的实例。
• 流量镜像：面对不可预测的现实世界的用户流量，不确定一个新版本的服务会做什么？配置服务网，将每个前往当前版本的请求的副本也发送给这个新版本。来自新版本的响应将被丢弃，以防它们仍有错误，但你可以观察新代码的日志、错误率和性能指标。

除了这些，还有很多例子，创新一直在发生。一个值得快速提及的大领域，尽管不在本文的范围内，是传统工作负载的迁移。服务网的侧翼很容易注入Kubernetes Pods--既可以钩住Pods的启动，让它也运行代理，也可以让它拦截所有流量。对于仍在原始虚拟机上运行的工作负载（如在systemd或原始Docker下），也可以这样做。设置起来比较麻烦，但是当你设置好之后，基于虚拟机的工作负载就会 "加入网状结构"，提供我在本文中谈到的所有优势。虽然这看起来很反常，但传统工作负载迁移的一个好方法是首先将它们加入到网状结构中，然后利用其提供的可观察性和路由控制来帮助迁移到Kubernetes。

最后一个创新领域是建立在服务网格之上的解决方案--是的，它们甚至不再是最先进的栈顶了！在这个领域中，我们可以看到一些新的解决方案。例如，结合在不同服务版本之间分配任意百分比的流量的能力，以及为每个版本产生的错误率和性能的详细指标，服务网是实现金丝雀推出的理想选择。将1%的流量发送到vNext，检查指标。一切顺利吗？发送2%，再次检查指标，重复。现在有更多的负载，指标看起来不好？立即将100%的流量引导回稳定版本。这完全可以用手来做，但非常繁琐。通过使用控制平面的统一的高级API（基本上是给它提供我们上面看到的相同的YAML文档），这个过程可以被自动化。诸如Weaveworks Flagger和ArgoCD等项目就是这样做的。这些API也被Meshery等超网格 "管理平面 "所使用。实现 现在我希望你已经对服务网的梦想深信不疑了！那么你该去哪里获得一个服务网呢？那么，你要到哪里去获得一个呢？有几种实现方式可以选择。我不打算在这里做推荐，但我将对主要的参与者做一个简单的介绍。

回顾一下数据平面、拦截和处理流量的代理和控制平面之间的分离，控制平面是指从我们这里获取高级配置并提供每个代理需要的所有复杂的单独配置的服务。高性能、安全的HTTP代理并不容易编写，所以大多数项目都不会重新发明这个轮子。很多服务网格都使用我说过的Envoy代理，它是一个独立的开源项目，用于他们的数据平面。差异化体现在控制平面上。

Istio是最著名和最流行的服务网格。它的控制平面是用Go编写的，使用Envoy作为代理。与Kubernetes类似，它可能更像是一个平台，而不是一个成熟的产品，所以学习曲线可能很陡峭，安装可能很棘手，但它在最近的版本中已经有了很大的改善。Istio是一个开源项目，拥有最大的支持，包括社区和第三方的商业产品。现在甚至还有来自Tetrate和Solo等供应商的Istio "发行版"。

Linkerd是另一个历史悠久的服务网格。请注意，最初有一个Linkerd 1，它在架构上非常不同，有一些严重的缺陷。目前的Linkerd 2（neé Conduit）是一个坚实的现代产品，有一个Go控制平面和一个定制的Rust代理。它是开源的，由供应商Buoyant提供商业支持。

除此之外，还有很多服务网格，请不要因为我在这里没有提到某个特定的网格而读出什么。第5层制作了一个伟大的景观指南和比较。

不过，我还是要提到两个具体的Service Meshes。Isovalent的Cilium是一个Kubernetes集群网络（CNI插件），相当于Calico和Flannel这样的东西。他们有一个测试版的服务网格产品，与他们的集群网络垂直整合。集群网络和服务网状网层都大量使用了eBPF，它执行了我谈到的很多第7层操作。Pods不需要侧车，因为内核中的eBPF承担了以前由代理完成的大部分工作，这提高了性能并减少了资源的使用。Cilium目前在每个节点上运行一个Envoy，如果需要eBPF不能提供的处理，流量就会被发送到这个Envoy，因为它不是无限灵活的。原始图片来自 https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta - 经许可使用。

AWSAppMesh是一个使用Envoy代理的专有产品。它与CloudWatch等其他AWS服务紧密集成，能够为ECS/Fargate工作负载以及Kubernetes Pods提供侧车，尽管目前还没有lambdas。

这种情况可能看起来很大，也很不协调，但有一些共同的主题。正如我所提到的，这些服务网格中很多都使用Envoy作为代理。Envoy是可扩展的，这意味着它可以加载新的负载平衡策略，或者被教导去解析新的第7层协议。扩展是以Web Assembly二进制文件的形式提供的，因此它们可以用多种语言编写，并编译成WASM。因此，这些扩展可以在许多网络中重复使用（尽管不同的网络中加载这些扩展的难易程度不同），而且正在进行的核心Envoy开发也使所有人受益。服务网格API也有一个标准，即服务网格接口（SMI），它与供应商无关，允许Flagger等产品与任何实现它的网格一起工作，而不需要额外的代码，也允许个人开发者使用服务网格技术而不锁定于特定的实现。一些大型网格实现了SMI，但值得注意的是Istio并没有。

结论

服务网格为Kubernetes集群中一个经常不被考虑的部分增加了强大的功能：网络。第7层的可观察性、复杂的流量路由和可靠的安全性都可以从应用程序的微服务中剥离出来，而被配置为网络功能。或者，也许更现实的是，服务网可以很容易地将它们添加到一开始就没有的应用中。新的创新，如WASM Envoy插件和无挎斗的eBPF网状结构，正在不断推动这个空间向前发展。然而，现在已经有几个成熟的服务网状结构项目为所有这些好处提供了一个简单的途径。部署一个服务网，可以释放出更多建立在它们之上的项目的价值，比如Flagger渐进式交付运营商。它们可以被逐步采用（Kubernetes标签被用来选择一个命名空间，甚至只是一个工作负载），这意味着你今天就可以开始安全地进行试验。