「TMV」- Service Mesh | 服务网格

该部分笔记将记录：Service Mesh 是什么，以及相关问题的解决方案。

认识

已知问题

应用的每个部分——即“服务”，都要与其他服务相互协作，来为用户提供所需的内容。如果在线零售应用的用户想购买什么东西，他们得知道该商品是否有货。因此，负责与公司库存数据库通信的服务需要与产品网页进行通信，而产品网页本身，也需要与用户的在线购物车通信。为了增加业务价值，该零售商之后可能会推出一项新服务：在应用中为用户提供产品推荐。要推荐产品，这项新服务除了要与产品标签数据库进行通信外，还需要与产品页面所需的同一个库存数据库进行通信，因此这涉及到大量可重复使用的移动组件。

微服务架构可让开发人员更改应用的服务，而无需全部重新部署。与其他架构的应用开发不同，每个微服务都是由小型团队来构建，他们可以灵活地选择自己的工具和编码语言。总体而言，微服务是独立构建的，它们之间彼此通信，出现故障也只是单独情况，而不会升级为整个应用的中断。

服务间的通信，令微服务成为可能。逻辑管理的通信可以编码到每个服务中，但随着通信变得越来越复杂，服务网格的价值也就愈发显著。

解决方案

对于以微服务架构构建的云原生应用而言，利用服务网格，可以将大量离散服务整合为一个功能应用。

服务网格是一种专门处理服务间通信的基础设施层，通常以轻量级网络代理（Sidecar模式）的形式部署在每个微服务旁，负责服务发现、负载均衡、流量管理、安全通信（如mTLS）、熔断、监控等能力，将通信逻辑从业务代码中解耦。

服务网格（例如开源项目 Istio）用于控制应用的不同部分之间如何共享数据。与用于管理此类通信的其他系统不同，服务网格内置于应用程序中的专用基础架构层。这个可见的基础架构层可以记录应用的不同部分是否能正常交互。因此，随着应用的不断发展，它在优化通信和避免停机方面就显得更加有用。

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

组成

服务网格是如何运作的？

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

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

对该网页的请求发出后，首先会被公司的 Web 代理收到……

通过了代理的安全措施检查后，它会被发送到托管此网页的服务器……

接下来，该网页将返回代理并再次进行安全措施检查……

之后，网页就会从代理发送给您。

在服务网格中，请求将通过所在基础架构层中的代理在微服务之间路由。正因如此，构成服务网格的各个代理有时也被称为“sidecar”，这是因为它们与每个服务并行运行，而非在内部运行。总之，这些“sidecar”代理（与每项服务分离）构成了网格式网络。

sidecar 代理与微服务并肩协作，用于将请求路由给其他代理。这些 sidecar 共同构成了网格式网络。

如果没有服务网格，每项微服务都需要进行逻辑编码，才能管理服务间通信，这会导致开发人员无法专注于业务目标。同时，这也意味着通信故障难以诊断，因为管理服务间通信的逻辑隐藏在每项服务中。

服务网格是如何优化通信的？

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

这是因为服务网格还会以性能指标的形式，捕获服务间通信的一切信息。随着时间推移，服务网格获取的数据逐渐累积，可用来改善服务间通信的规则，从而生成更有效、更可靠的服务请求。

例如，如果某个服务失败，服务网格可以收集有关在重试成功前所花时间的数据。随着某服务故障持续时间的数据不断积累，开发人员可编写相应的规则，以确定在重试该服务前的最佳等待时间，从而确保系统不会因不必要的重试而负担过重。

构建

服务网格实现（产品）

这里仅列举部分（我们熟知的）服务网格工具：

参考

微服务/什么是服务网格？
Service Mesh Ultimate Guide: Managing Service-to-Service Communications in the Era of Microservices

Filed under: K4NZDROID - @ 2:02 AM