服务网格是一个软件层,用于处理应用程序中服务之间的所有通信。该层由容器化微服务组成。随着应用程序的扩展和微服务数量的增加,监控服务的性能变得越来越困难。为了管理服务之间的连接,服务网格提供了监控、记录、跟踪和流量控制等新功能。它独立于每项服务的代码,这使它能够跨网络边界和多个服务管理系统工作。
在现代应用程序架构中,您可以将应用程序作为可独立部署的小型微服务的集合来构建。不同的团队可以构建单独的微服务并选择其编程语言和工具。但是,微服务必须进行通信,应用程序代码才能正常运行。
应用程序性能取决于服务之间通信的速度和弹性。开发人员必须跨服务监控和优化应用程序,但由于系统的分布性质,他们很难获得可见性。随着应用程序的扩展,管理通信变得更加复杂。
随着部署的工作负载和服务越来越多,开发人员发现很难理解所有服务是如何协同工作的。例如,服务团队想知道他们的下游和上游依赖关系是什么。他们希望更清楚地了解服务和工作负载在应用程序层的通信方式。
管理员希望控制哪些服务相互通信,以及它们执行哪些操作。他们希望对微服务架构中服务的行为、策略和交互进行精细的控制和治理。强制执行安全策略对于监管合规至关重要。
服务网格提供了一个集中的专用基础设施层,用于处理分布式应用程序中复杂的服务到服务通信。
服务网格提供自动服务发现,可以减少管理服务端点的运维负担。它们使用服务注册表来动态发现和跟踪网格中的所有服务。无论服务位于何处或底层基础设施如何,都可以无缝地相互查找和通信。您可以根据需要部署新服务来快速扩展。
服务网格使用各种算法(例如循环算法、最少连接或加权负载均衡)在多个服务实例之间智能地分配请求。负载均衡可提高资源利用率并确保高可用性和可扩展性。您可以优化性能并防止出现网络通信瓶颈。
服务网格提供高级流量管理功能,可对请求路由和流量行为进行精细控制。下面是几个示例。
您可以将传入流量划分到不同的服务版本或配置中。网格将一些流量引导到更新后的版本,从而以受控方式逐步推出变更。这样可以实现平稳过渡,并最大限度地降低变更的影响。
您可以将流量复制到测试或监控服务进行分析,而不影响主请求流。镜像请求时,您可以深入了解服务如何在不影响生产流量的情况下处理特定请求。
您可以将一小部分用户或流量引导到新的服务版本,而大多数用户则继续使用现有的稳定版本。在有限的接触范围内,您可以在现实环境中试验新版本的行为和性能。
服务网格提供安全通信功能,例如双向 TLS(mTLS)加密、身份验证和授权。双向 TLS 支持服务间通信中的身份验证。它通过加密流量来帮助确保数据的机密性和完整性。您还可以强制执行授权策略,以控制哪些服务访问特定端点或执行特定操作。
服务网格提供全面的监控和可观测性功能,可深入了解服务的运行状况、性能和行为。监控还支持故障排除和性能优化。以下是您可以使用的监控功能示例:
收集延迟、错误率和资源利用率等指标,以分析整体系统性能
执行分布式跟踪,查看多个服务中请求的完整路径和时间
在日志中捕获服务事件,用于审计、调试和合规目的
服务网格从单个服务中移除控制服务间通信的逻辑,并将通信抽象到自己的基础设施层。它使用多个网络代理来路由和跟踪服务之间的通信。
代理充当组织网络和微服务之间的中间网关。所有进出该服务的流量都通过代理服务器路由。单个代理有时被称为 sidecar,因为它们是分开运行的,但在逻辑上位于每个服务旁边。这些代理一起构成了服务网格层。
服务网格架构中有两个主要组成部分:控制面板和数据面板。
数据面板是服务网格的数据处理组件。它包括所有 sidecar 代理及其功能。当一个服务想要与其他服务通信时,sidecar 代理会采取以下操作:
sidecar 拦截请求
它将请求封装在单独的网络连接中
它在源代理和目标代理之间建立安全的加密通道
sidecar 代理处理服务之间的低级消息传递。它们还会实施断路和请求重试等功能,以增强弹性并防止服务降级。服务网格功能(例如负载均衡、服务发现和流量路由)在数据面板中实施。
控制面板充当服务网格的中央管理和配置层。
使用控制面板,管理员可以在网格内定义和配置服务。例如,他们可以指定服务端点、路由规则、负载均衡策略和安全设置等参数。定义配置后,控制面板将必要信息分发到服务网格的数据面板。
代理使用配置信息来决定如何处理传入的请求。它们还可以接收配置更改并动态调整其行为。您可以实时更改服务网格配置,而无需重新启动或中断服务。
服务网格实现通常在控制面板中包括以下功能:
用于跟踪网格内所有服务的服务注册表
自动发现新服务并删除非活动服务
收集和聚合遥测数据,例如指标、日志和分布式跟踪信息
Istio 是一个开源服务网格项目,设计为主要与 Kubernetes 配合使用。Kubernetes 是一款开源容器编排平台,用于大规模部署和管理容器化应用程序。
Istio 的控制面板组件本身作为 Kubernetes 工作负载运行。它使用 Kubernetes 容器组(一组共享一个 IP 地址的紧密耦合的容器)作为 sidecar 代理设计的基础。
Istio 的第 7 层代理在与主服务相同的网络环境中作为另一个容器运行。从这个位置,它可以拦截、检查和操作所有通过容器组的网络流量。但是,主容器不需要任何改动,甚至不需要知道这种情况正在发生。
以下是与 Istio、Linkerd 和 Consul 等开源平台相关的一些常见服务网格挑战。
服务网格引入了其他基础设施组件、配置要求和部署注意事项。它们的学习曲线很陡峭,这要求开发人员和操作人员获得使用特定服务网格实施方面的专业知识。培训团队需要时间和资源。组织必须确保团队具备必要的知识,以了解服务网格架构的复杂性并对其进行有效配置。
服务网格会带来部署、管理和监控数据面板代理和控制面板组件的额外开销。例如,您必须执行以下操作:
确保服务网格基础设施的高可用性和可扩展性
监控代理的运行状况和性能
处理升级和兼容性问题
必须仔细设计和配置服务网格,以最大限度地减少对整个系统的性能影响。
服务网格必须与现有基础设施无缝集成,才能执行其所需的功能。这包括容器编排平台、网络解决方案和技术堆栈中的其他工具。
在复杂多样的环境中,要确保与其他组件的兼容性和顺利集成可能具有挑战性。要更改 API、配置格式和依赖关系,需要进行持续的规划和测试。如果您需要在堆栈中的任何位置升级到新版本,也是如此。