什么是服务网格？

服务网格是软件应用内的一个专用基础架构层，用于处理服务之间的通信。服务网格可以处理流量路由、安全防护、可观测性和弹性功能，同时对各个服务进行抽象化处理来降低复杂性。

现代应用的运行依赖于彼此通信的服务。请回想一下您上次在线购物时的情景。您应该使用了网站上的搜索栏来浏览产品。这个搜索功能就是一项服务。您可能还查看了推荐的相关商品，或者将某款商品添加到了线上购物车中。这两者也是服务。与库存数据库通信的服务还需要与产品网页进行通信，而产品网页需要与用户的在线购物车进行通信。零售商可能还会提供在应用中为用户推荐产品的服务。要推荐产品，这项服务除了要与产品标签数据库进行通信之外，还需要与产品页面所需的同一个库存数据库进行通信。

现代应用常常以这种方式进行拆分，从而构成一个服务网络，其中每个组件分别执行特定的功能。要执行相应的功能，一项服务可能需要向其他几项服务请求数据。但如果有些服务（例如零售商的库存数据库）遇到请求超载会怎样呢？这就要靠服务网格了，它会管理服务间的通信，从而优化所有移动组件的协同工作方式。

可以将服务网格视为一种微服务架构模式。微服务则是一种应用架构，其中的一系列独立服务通过轻量级应用编程接口（API）进行通信。微服务架构是一种云原生软件构建方式，应用的每项核心功能均可独立存在。与其他架构中的应用开发不同，每个微服务都可由小型团队构建，他们可以灵活地选择自己的工具和编码语言。微服务是独立构建的，它们之间彼此通信，出现故障也只是单独情况，而不会升级为整个应用的中断。

服务间的通信，令微服务成为可能。随着微服务架构的发展，其管理变得愈发复杂。如果一个应用包含数十个乃至数百个相互交互的服务，就会在许多方面出现挑战，例如网络故障、监控和跟踪、流量负载平衡以及不同微服务间的通信安全防护。完全通过自定义代码来解决这些问题会导致效率低下。在这种情况下，服务网格提供了一致的解决方案来应对这些挑战，而无需更改各个服务的代码。

服务网格使用一个数据平面和一个控制平面来管理服务之间的通信。

服务网格不会为应用的运行时环境加入新功能，任何架构中的应用还是需要相应的规则来指定请求如何从 A 点到达 B 点。但服务网格的不同之处在于，它从各个服务中提取逻辑管理的服务间通信，并将其抽象为一个基础架构层。

要这样做，服务网格会以网络代理阵列的形式内置到应用中。代理的概念并不陌生，如果您从一台工作计算机访问网页，很可能就会使用代理。其运作方式如下：

1. 对该网页的请求发出后，会被公司的 Web 代理收到。
2. 通过了代理的安全措施检查后，它会被发送到托管此网页的服务器。
3. 接下来，该网页将返回到代理并再次进行安全措施检查。
4. 之后，网页就会从代理发送给您。

在服务网格中，每个服务实例都配有一个“边车”代理，这些代理与每个服务并行运行，并拦截所有入站和出站的网络流量。每个边车代理都与微服务并存，用于将请求路由给其他代理，或从其他代理那路由请求。代理负责处理诸如流量路由、负载平衡、安全防护策略实施以及遥测数据收集等任务。服务之间不直接通信，而是通过其边车发送请求，由边车来处理服务间通信。所有这些功能共同构成了数据平面。

控制平面不仅负责管理数据平面上的配置和策略分发，还负责分发流量路由规则、在服务之间管理安全证书、配置组件以实施策略，以及收集遥测数据。

如果没有服务网格，每项微服务都需要进行逻辑编码，才能管理服务间通信。这会导致通信故障难以诊断，因为管理服务间通信的逻辑隐藏在每项服务中。

了解微服务的更多信息

Istio 是一个开源服务网格平台，它可以控制微服务之间数据的共享方式。它在微服务环境中控制流量、实施策略并监控通信。其附带的 API 可以将 Istio 集成到任何日志记录平台、遥测或策略系统中。Istio 可以在各种本地、云、容器化和虚拟化环境中运行。

Istio 的架构分为数据平面和控制平面两部分。Istio 使用 Envoy 代理，这是一种作为边车部署的高性能代理，负责为服务网格内的所有服务调解流量。在数据平面中，开发人员可通过在环境中部署边车代理，为服务添加 Istio 支持。

Istio 的服务网格包含一种新的 Ambient 模式，该模式将在服务网格中消除对边车代理的需求，代之以节点级代理以及称为“Waypoint”的中间网关。Waypoint 代理在应用容器集之外运行，并独立于应用进行管理。

在红帽开发人员网站上了解有关 Istio 的更多信息

每向应用中添加一项新服务或为容器中运行的现有服务添加一个新实例，都会让通信环境变得更加复杂，并可能埋入新的故障点。在复杂的微服务架构中，如果没有服务网格，几乎不可能找到哪里出了问题。

使用服务网格可获得以下几个优势：

• 提升安全性。服务网格使用双向传输层安全性（mTLS）来确保服务之间的通信经过加密且安全无虞，并保护敏感的用户数据。它增加了一层额外的安全保护，而无需手动为每项服务添加额外加密措施。服务网格不仅可以改进基于角色的访问权限控制（RBAC）以及用于保护 API 的策略，还能自动执行证书管理和密钥轮换。
• 策略实施。服务网格包含用于服务策略（如配额、速率限制以及身份验证和授权）的集中式配置。它通过访问策略提供针对服务交互的控制。策略在代理级别实施，这有助于实现服务之间的一致性。
• 流量管理。服务网格可帮助应用根据负载情况、版本和特定于用户的规则来管理流向各个服务的流量。例如，如果您要推出库存服务的新版本，可以采用金丝雀部署，仅将 5% 的流量发送至新服务。（金丝雀部署是一种小规模测试部署。）如果一切正常运行，您可以增加流量。
• 健康检查和可观测性。实时查看微服务之间的交互情况可能比较困难，但借助服务网格，您可以实施分布式跟踪和指标收集等内置可观测性工具。服务网格中的边车会收集指标（请求计数、延迟、错误率等），并将它们发送至控制平面或监控工具。
• 容错能力和提升弹性。当微服务发生故障时，服务网格可以通过自动重试和回退来提供帮助。如果某项服务出现故障或无响应，服务网格将根据预定义规则进行重试，并可以将流量重新路由至备用服务。这意味着，当某项服务不可用时，应用可以灵活地处理故障，确保用户保持良好体验。服务网格还会收集重试成功前的耗时数据。未来制定关于最佳等待时间的规则时，可将这些数据作为依据，确保系统不会因为不必要的重试而负担过重。

借助服务网格，开发和运维团队可以更好地应对从单体式应用向云原生应用（一组小型、独立且松散耦合的微服务应用）的迁移。 

在实施服务网格时，企业组织可能会遇到以下挑战：

• 复杂性以及与现有系统的集成。服务网格的设置、管理以及与现有系统的集成可能比较困难。如果企业组织在多云和本地系统构成的大型分布式环境中工作，或者之前在其环境中未曾使用过服务网格，那么可能会遇到挑战。
• 资源要求和运维开销。服务网格可能会增加管理应用的运维开销，因为每个服务实例现在都有一个边车代理，这会增加 CPU 和内存的使用。管理和故障排除（尤其是在大规模部署中）可能会变得复杂，导致性能维护和扩展也更加困难。
• 技能差距。团队需要通过培训来了解服务网格的功能、配置和最佳实践。调试故障可能非常棘手，特别是当复杂的路由规则或 mTLS 配置错误导致问题时。许多企业组织会发现其现有团队缺乏服务网格技术专业知识，这可能会让他们难以上手并有效使用服务网格。

API 网关是位于客户端与后端服务集之间的 API 管理工具。在这种情况下，客户端是指用户设备上的应用，后端服务则是指企业服务器上的服务。API 网关是一种将客户端接口与后端实现分离的方式。当客户端发出请求时，API 网关会将其分解为多个请求，然后将它们路由到正确的位置，生成响应，并跟踪所有内容。

服务网格可保障内部服务通信安全，同时允许外部流量通过 API 网关。将服务网格与 API 网关结合使用，可确保在内部服务中一致地应用策略。

了解有关红帽 3scale API 管理的更多信息

红帽提供集成式 API 管理、服务网格和基础架构平台产品，帮助用户构建全面的服务管理架构。使用红帽® OpenShift® 服务网格，能够以统一的方式连接、管理和查看基于微服务的应用。它能为用户提供关于服务网格中联网的微服务的行为分析，并能让用户进行控制。

OpenShift 服务网格基于开源 Istio 项目构建，并纳入了 Kiali（Istio 控制台）和 Jaeger（分布式跟踪）等其他开源项目，以提供额外的功能，支持与 Istio 社区中的主要成员展开协作。OpenShift 服务网格可以通过集成通信策略来帮助开发人员提高生产力，无需更改应用代码，也不必集成特定语言的库。

红帽 OpenShift 服务网格已针对红帽 OpenShift 进行了预安装、测试和优化。它与特定于 OpenShift 的功能（如 Operator 以及持续集成/持续交付（CI/CD）管道）兼容。它附带红帽的企业级支持，并会定期更新和修补，以确保安全性和稳定性。OpenShift 服务网格可以跨多个红帽 OpenShift 集群运行，从而跨混合云或多云环境实现一致性。