服务网格那些事

最近，服务网格（Service Mesh）在开发人员中越来越受欢迎，特别是在希望解决横切关注点的Spring和Java开发人员中。但是，您是否想知道什么是服务网格？有哪些流行的类型？最重要的是，它们到底解决了哪些问题？别担心，本文将为您提供答案。

什么是服务网格？

服务网格是一个专用的基础架构层，用于管理分布式应用程序中各个微服务之间的通信。它充当透明且分散的代理网络，这些代理部署在应用服务旁边。这些代理通常被称为sidecar，它们处理服务之间的通信，提供诸如服务发现、负载均衡、流量路由、身份验证和可观测性等关键功能。

通过将网络通信的复杂性抽象化，服务网格使开发人员能够专注于应用程序逻辑，而不必处理网络代码的复杂性。它提供了一种一致且灵活的处理跨服务通信的方式，并允许实现高级的流量管理策略、安全策略和可观测性机制。它们提供了一种标准化的方法来管理微服务之间的通信，使得在复杂的分布式系统中更容易监控、保护和控制流量。

服务网格的组件

服务网格架构通常涉及以下组件及其相互作用：

数据平面（Data Plane）：数据平面指的是部署在每个服务实例旁边的一组sidecar代理组成的网络，用于与系统中的其他服务进行通信。它充当服务与网络的中间人。Sidecar代理处理入站和出站流量，拦截通信并提供其他功能。

• Sidecar（旁车）：它基于Envoy代理。它是在同一Kubernetes POD中运行的另一个容器，负责处理所有的横切关注点。它基于旁车容器设计模式。
• 应用程序流量：微服务通过使用sidecar容器连接到其他微服务。应用程序流量基本上是Envoy sidecar代理容器之间的通信。
• 命名空间（Namespace）：它是Kubernetes POD上的一个隔离空间，其中同时运行旁车和微服务应用程序。

控制平面（Control Plane）：控制平面是服务网格的集中管理和配置层。它负责控制和协调sidecar代理的行为。它提供了一个控制平面API，允许管理员配置流量管理、安全性和可观测性的策略、规则和设置。

• API端点（API Endpoints）：API端点是网格中的服务之间进行通信的入口点。
• 控制器（Controllers）：控制器是负责管理和控制网格行为的组件。它通常是一个软件组件，用于监视服务的状态和健康情况、配置流量路由和负载均衡规则、实施安全策略，并处理网格内服务之间通信的其他方面。
• 服务发现（Service Discovery）：服务发现是服务网格架构中的一个重要组件。它使得服务能够动态地定位和连接到彼此，而无需硬编码的地址。
• 证书授权机构（Certificate Authority）：它提供和管理根证书和中间证书，并执行证书签名操作。

应用程序微服务（Application Microservices）：这些是组成应用程序的各个服务或微服务。它们负责处理特定的功能或任务。

用例：电子商务应用程序

以电子商务应用程序为例，服务网格将有助于管理负责不同功能的各种微服务之间的复杂网络。

• Sidecar代理将处理负载均衡，确保流量在每个服务的多个实例之间高效分配。
• 此外，服务网格将通过强制使用TLS加密和身份验证来提供服务之间的安全通信。这有助于在传输过程中保护敏感的客户信息，并防止对关键服务的未经授权访问。
• 流量管理功能将允许操作员控制和监控请求的流动，使他们能够执行诸如将某些请求路由到服务的新版本进行测试，或者限制传入请求的速率以防止过载等任务。
• 服务网格的可观测性和监控功能将为操作员提供应用程序性能的实时洞察，使他们能够及时发现和解决问题。
• 他们可以分析指标、日志和跟踪以优化应用程序的性能，排除问题，并确保顺畅的客户体验。

总而言之，服务网格简化了分布式应用程序的管理，并增强了应用程序的弹性、安全性和可观察性，成为现代微服务架构中的重要组件。

服务网格解决了哪些问题？

服务网格在现代应用程序架构的背景下解决了几个问题。以下是服务网格解决的一些关键问题：

• 服务之间的通信 在微服务架构中，应用程序由多个独立的服务组成，这些服务需要彼此进行通信。服务网格提供了一个专用的基础架构层来处理服务之间的通信，使得管理和保护这些交互变得更加容易。
• 服务发现和负载均衡 随着服务数量的增加，跟踪它们的位置并有效地分发流量变得具有挑战性。服务网格提供了服务发现和负载均衡的功能，允许服务动态地发现和连接到彼此，并自动将流量负载分布到多个实例上。
• 流量管理和路由 服务网格实现了复杂的流量管理和路由功能，例如基于服务版本、路径、标头或其他属性的请求路由。它允许进行流量转移、金丝雀部署和A/B测试，使团队能够轻松实施复杂的部署策略。
• 弹性和容错性 服务网格提供了实现弹性和容错性模式的机制，例如重试、超时、断路和负载限制。这些功能帮助服务优雅地处理故障，隔离问题，并防止系统中的级联故障。
• 可观察性和调试 服务网格为开发人员提供了强大的可观察性功能，例如分布式跟踪、指标收集和日志记录。这些功能帮助开发人员了解其服务的行为和性能，可以调试问题、跨服务边界跟踪请求，并优化应用程序的性能。
• 安全性和身份验证 服务网格通过提供传输层加密（TLS）、相互身份验证和授权策略等功能来增强微服务架构的安全性。它允许进行细粒度的访问控制和身份管理，提高系统的整体安全性。
• 源代码的紧密耦合 云配置通常与业务逻辑源代码紧密耦合，这使得管理和调试任何代码问题都会变得繁重。这可能使得添加新的业务功能、插入附加代码和解决问题变得困难。然而，采用服务网格架构可以将横切关注点与业务逻辑源代码分离。通过采用这种方法，服务网格通过DevOps平台/基础架构团队的协作，独立处理所有应用程序配置。
• 横切配置关注点的测试负担 在集成、回归和负载测试期间测试新功能，需要额外的测试工作量。对于业务逻辑的微小变更，即使是交叉配置代码，也需要测试整个代码库。通过采用服务网格的方法，业务逻辑代码变得更加简洁和简化，从而实现更轻松、更快速的测试。此外，开发人员发现编写较少的JUnit和集成测试用例更加简单。
• 应用程序性能问题 当业务逻辑和交叉配置组合在一起时，它们需要额外的时间来加载、部署和在应用容器上运行。即使是业务特定的API调用也会消耗额外的CPU和内存，这可能导致性能问题。相比之下，服务网格利用一个专门的旁车容器来运行交叉配置关注点的配置代码。这减轻了主应用容器的负荷，从而提高了应用程序的性能。通过仅运行精简的应用业务逻辑，可以增强性能。

在选择服务网格时应关注哪些关键特性？

• 连接Kubernetes集群：如果与Google Anthos、Azure Arc、AWS Outpost、VMware Tanzu Mission Control（TMC）等混合云技术一起使用，它可以在两个或多个Kubernetes集群之间提供连接。它可以跨本地、私有和公共云提供商进行扩展。
• 带有Ingress Controller和Ingress资源的服务发现：它提供了动态的服务发现和路由，可以在具有不同动态IP地址的多个云上的K8s集群之间分发分布式微服务REST API。它通过Ingress Controller和Ingress资源公开服务名来暴露服务，这些服务可以被任何客户端或消费者使用。Ingress资源提供了对各种服务的路由详细信息，Ingress控制器使用Ingress资源将传入请求路由到API。
• 断路器弹性：如果依赖的服务没有响应第一次尝试，断路器提供了重试机制。服务网格通过断路器提供了强大的功能，当依赖的服务在给定的估计时间内没有响应时。由于这个机制，微服务对停机时间更具弹性，因为服务网格可以通过重新路由请求，使其远离失败的服务。
• 微服务之间的API跟踪：它提供了微服务的API跟踪（API到API的交互）功能，跟踪请求和响应的交互日志。这种跟踪有助于改善API的性能和SLA，并帮助开发人员调试和诊断错误。
• 可观测性：它提供了强大的机制来检查应用程序的健康状况和基础资源使用情况，如CPU和内存使用情况。它还收集应用程序性能指标，并在Web仪表板上可视化。性能指标可以提供在运行时环境中优化通信的方式。还可以监视基础架构和应用程序。
• 数据有效负载安全性：它通过应用双向强大的mTLS安全加密技术，在微服务API通信中提供数据传输时的数据加密。
• API限流：它提供了一种机制来限制后端API调用的数量，防止分布式拒绝服务（DOS/DDOS）攻击。在此类攻击中，数千甚至数百万个请求随机命中后端API，导致整个后端软件系统和基础设施崩溃。
• 负载均衡：它通过使用内置的Ingress Controller机制，将微服务暴露在Kubernetes集群上，作为通过Ingress控制器负载均衡器公开的外部服务。Ingress控制器可以根据Ingress资源将客户端请求映射和路由到分布式微服务。

流行的服务网格

Istio（开源服务网格）

Istio是一个开源的服务网格平台，提供了一组工具和功能，用于管理和保护基于微服务的应用程序。它旨在解决复杂分布式系统中与服务之间通信、可观察性、安全性和流量管理相关的常见挑战。在其核心，Istio在应用程序中的每个微服务旁边部署一个称为Envoy的sidecar代理。这个sidecar代理拦截和管理服务的所有入站和出站流量，使得Istio可以控制和监控服务之间的通信。

优点：

• Istio拥有庞大的在线服务网格社区，并且在互联网上备受赞誉和讨论。其GitHub的贡献者远远超过Linkerd，数量上占据优势。
• 此外，它支持Kubernetes和VM模式。

缺点：

• Istio并非免费提供，使用它需要相当大的时间投入，包括阅读文档、设置、确保正常功能和持续维护。
• 在生产环境中实施和集成Istio可能需要几周甚至几个月的时间，这取决于基础架构的复杂性。
• 使用Istio需要相当大的资源开销。
• 与Linkerd不同，它缺乏内置的管理仪表板。
• 此外，Istio要求使用其自己的入口网关。
• lstio控制平面仅在Kubernetes容器中受支持，没有可用于Istio数据平面的VM模式。

Linkerd

Linkerd是一个开源的服务网格平台，旨在为微服务架构提供可观察性、可靠性和安全性。它由云原生计算基金会（CNCF）开发，注重简单性、性能和易用性。

优点：

• Linkerd借鉴了其创作者的经验，他们是Twitter的前工程师，曾开发过内部工具Finagle。他们从Linkerd v1的开发经验中获得了宝贵的见解，这有助于改进服务网格。
• 作为最早的服务网格之一，Linkerd拥有一个活跃而充满活力的社区，在Slack上拥有超过5000名用户，以及一个活跃的邮件列表和Discord服务器。
• 详尽的文档和教程的可用性进一步增强了它的吸引力。
• Linkerd通过Buoyant提供付费的企业级支持，确保专业帮助随时可得。

缺点：

• 充分发挥Linkerd服务网格的潜力需要相当大的学习曲线。需要注意的是，Linkerd仅在Kubernetes容器中受支持，不提供VM模式或“通用”模式。
• 与Envoy不同，Linkerd的sidecar代理有所不同，这使得Buoyant能够根据自己的需求进行优化。然而，这种定制化是以失去Envoy提供的内在可扩展性为代价的。
• 因此，Linkerd不支持关键功能，如断路、延迟注入和速率限制。此外，它没有直接暴露用于轻松控制Linkerd控制平面的API，尽管可以找到一个gRPC API绑定。

除了上述比较，市场上还有许多选项供您选择，例如：

• NGINX
• Tanzu Service Mesh（TSM）
• Tetrate Service Bridge（TSB）
• Google Anthos
• Azure Mesh
• AWS App Mesh
• HAProxy
• Envoy
• Traefik

结论

服务网格技术对开发人员来说是一个福音。它通过将横切关注点从应用程序源代码委派给内部DevSecOps，提高了开发人员的生产力。服务网格为解决开发人员的挑战和提高开发人员的生产力提供了大量更多的功能。对于在Kubernetes上构建云原生微服务应用程序来说，服务网格现在是一种事实上的标准。