服务网格：微服务的下半场

如今，云原生应用程序通常被设计为一组在容器中运行的分布式微服务(请参见--https://www.compunneldigital.com/infographic/how-to-modernize-your-legacy-systems-here-are-the-best-practices/)，因此人们往往将其称为容器化的应用程序。这些容器应用主要是基于Kubernetes--这一容器化编排的实际标准。但是随着微服务的指数级增长，我们很难在多种服务、加密、身份验证、授权、以及Kubernetes集群的负载平衡之间，实施和标准化路由。为此，我们需要用到“服务网格(service mesh)”。就像容器是从应用程序中抽象出了操作系统那样，服务网格则抽象出了如何处理进程之间的通信。

什么是服务网格?

服务网格是一个专用的基础架构层，它可以被用于处理服务与服务(service-to-service)之间的通信。通过构建云原生的现代化应用，服务网格能够使用复杂服务拓扑，来可靠地传递各种请求。服务网格的实现，实际上是与应用代码一起部署的轻量级网络代理阵列。换句话说，它是由附加到应用程序中所有pod的sidecar代理所组成。服务网格的概念，随着与之相连接的云原生应用的迭代，而不断进化。值得注意的是：服务与服务之间的通信不仅十分复杂，而且涉及到运行时(runtime)行为的基本方面，因此服务网格能对它们进行管理，进而有效地确保端到端的性能与可靠性。

除了为Kubernetes提供服务，服务网格还包括安全性、可视性、以及路由等功能。许多人普遍认为：如果本组织需要实现集中化的控制，那么服务网格就是确保内部平台能够统一执行治理策略的唯一方法。

下面，让我们来看看企业是如何通过使用服务网格，配合Kubernetes，来有效地控制服务的安全性、可视性、路由、以及负载平衡。

透明度提高

在一个杂乱且密集的云原生环境中，要遵循复杂的路由规则与流程管理着实不易。各种数据消息在不同的拓扑结构、以及在基础架构的不同层次之间，沿着既定的轨迹从一个pod传递到另一个pod。而服务网格恰好能为现代化应用程序的服务交付方式(请参见--https://www.compunneldigital.com/blog/modernizing-legacy-systems-with-cloud-native-serverless/)，带来更好的透明性，以方便用户有效地跟踪消息的流转过程。

安全性增强

安全性是服务网格主要关注的一个方面。它能够确保以集中控制的方式，在整个组织中实现加密、以及细粒度的访问控制规则。相对于传统的单点控制，服务网格能够全面地控制各种网络流量，进而提供更好的安全态势。

此外，随着微服务数量的增加，网络流量也会随之增多。这在无形中也方便了攻击者轻松地攻击各种通信流。因此，为了确保网络中流量交互的安全性，服务网格通过提供双向传输层安全(mutual TLS，Transport Layer Security)，来提供验证服务、执行安全策略、以及加密服务间流量的全栈式解决方案。

加密

由于微服务之间的通信需求不断地增加，我们需要通过可靠的加密服务来为其保驾护航。服务网格能够协助实现密钥、证书、以及针对持续加密的TLS配置管理，因此用户不再需要手动执行加密或证书管理。同时，服务网格提供了基于策略的身份验证，可以在两个服务之间建立双向的TLS配置，以实现服务之间(service-to-service)的安全加密通信，和最终用户的身份验证。

可视性

尽管Kubernetes能够帮助我们有效地保持Pod的运行、以及节点的CPU和内存利用率处于良好状态，但它无法告知我们到底是谁部署了何种应用程序，以及该应用的性能如何。而服务网格可以通过其提供的服务级别可见性，跟踪和监控功能，来提高分布式服务的可视性。它是目前能够提供应用级可用性状态信息的最佳方法。此外，服务网格还能让开发运维团队了解每个服务在第三、四层以下的运行状况，以及应用的整体表现。

您可以通过这些可见性，来更好地响应事件和排除故障。例如：如果应用架构中的某项服务出现了性能瓶颈，那么服务网格就可协助您轻松地切断某个故障服务，禁用那些无法正常运行的副本，进而保持API的正常响应速度。

路由

过去，在没有服务网格之前，管理各层的路由和负载平衡责任，都是由应用程序开发人员所负责的。如今，除了安全性和可视性，企业还可以通过服务网格的智能路由来控制流量，进而实现服务之间的API调用。此外，它还可以协助执行蓝绿部署，即：在不中断任何服务类型的情况下，安全地推送新的应用升级。

此外，过去在Kubernetes中，那些由side-car代理所控制的内容，如今则由一个中心的团队，来统管安全性、可视性、以及路由规则等多项服务。

总结