主持人 > 博客 > 管理 > 什么是服务网格？

什么是服务网格？

再次大家好！...在课程开始前夕 《软件架构师》 我们准备了另一个有用的翻译。

什么是服务网格？

服务网格是一个可配置的、低延迟的基础设施层，需要处理应用程序编程接口 (API) 之间大量基于网络的进程间通信。 服务网格可以在容器化且通常是临时的应用程序基础设施服务之间实现快速、可靠和安全的通信。 Service Mesh 提供服务发现、负载均衡、加密、透明、可追溯、身份验证和授权以及自动关闭模式支持等功能（断路器).
服务网格通常是通过为每个服务实例提供一个代理实例来实现的，称为 边车。 边车 处理服务之间的通信，监视和解决安全问题，即可以从各个服务中抽象出来的所有内容。 这样，开发人员可以在服务中编写、维护和提供应用程序代码，系统管理员可以使用 Service Mesh 并运行应用程序。

来自Google、IBM和Lyft的Istio是目前最著名的服务网格架构。 而最初由 Google 开发的 Kubernetes 现在是 Istio 支持的唯一容器编排框架。 供应商正在尝试创建 Istio 的商业支持版本。 看看他们能为开源项目带来哪些新东西将会很有趣。

然而，Istio 并不是唯一的选择，因为其他服务网格实现正在开发中。 图案 sidecar proxy 是最受欢迎的实现，可以通过 Buoyant、HashiCorp、Solo.io 等项目来判断。 还有替代架构：Netflix 技术工具包是通过 Ribbon、Hysterix、Eureka、Archaius 库以及 Azure Service Fabric 等平台实现 Service Mesh 功能的方法之一。

Service Mesh 对于服务组件和功能也有自己的术语：

  • 容器编排框架。 随着越来越多的容器被添加到应用程序基础设施中，需要一个单独的工具来监控和管理容器——容器编排框架。 Kubernetes 牢牢占据了这一利基市场，甚至其主要竞争对手 Docker Swarm 和 Mesosphere DC/OS 也提供与 Kubernetes 的集成作为替代方案。
  • 服务和实例（Kubernetes Pod）。 实例是微服务的单个运行副本。 有时一个实例就是一个容器。 在 Kubernetes 中，一个实例由一小组称为 pod 的独立容器组成。 客户端很少直接访问实例或 Pod；更常见的是，他们访问服务，这是一组相同、可扩展且容错的实例或 Pod（副本）。
  • 边车代理。 Sidecar Proxy 适用于单个实例或 Pod。 Sidecar 代理的目的是路由或代理来自它所使用的容器的流量并返回流量。 Sidecar 与其他 Sidecar 代理交互，并由编排框架管理。 许多 Service Mesh 实现使用 Sidecar Proxy 来拦截和管理进出实例或 Pod 的所有流量。
  • 服务发现。 当一个实例需要与另一个服务通信时，它需要找到（发现）另一个服务的健康且可用的实例。 通常，实例执行 DNS 查找。 容器编排框架维护准备好接收请求的实例列表，并提供用于 DNS 查询的接口。
  • 负载均衡。 大多数容器编排框架在第 4 层（传输）提供负载平衡。 Service Mesh在第七层（应用层）实现了更复杂的负载均衡，算法丰富，流量管理更有效。 可以使用 API 更改负载平衡设置，从而允许您编排蓝绿或金丝雀部署。
  • 加密。 服务网格可以加密和解密请求和响应，从而消除服务的这种负担。 服务网格还可以通过优先考虑或重用现有持久连接来提高性能，从而减少创建新连接所需的昂贵计算。 流量加密最常见的实现是 相互 TLS (mTLS)，其中公钥基础设施 (PKI) 生成并分发证书和密钥以供 Sidecar 代理使用。
  • 认证与授权。 服务网格可以对来自应用程序外部或内部的请求进行授权和身份验证，仅向实例发送经过验证的请求。
  • 自动关机模式支持。 服务网格支持 自动关机模式，它会隔离不健康的实例，然后在需要时将它们逐渐返回到健康实例池中。

Service Mesh 应用程序中管理实例之间网络流量的部分称为 数据平面。 创建和部署控制行为的配置 数据平面，使用单独的执行 控制平面. 控制平面 通常包括或设计用于连接到 API、CLI 或 GUI 以控制应用程序。

什么是服务网格？
服务网格中的控制平面在 Sidecar 代理和数据平面之间分配配置。

Service Mesh 架构通常用于使用容器和微服务来解决复杂的操作问题。 该领域的先驱 微服务 Lyft、Netflix 和 Twitter 等公司为全球数百万用户提供稳定的服务。 （以下详细介绍了 Netflix 面临的一些架构挑战。）。 对于要求较低的应用程序，更简单的架构可能就足够了。

服务网格架构不太可能成为所有应用程序操作和交付问题的答案。 建筑师和开发人员拥有庞大的工具库，但其中只有一把锤子，而在众多任务中，锤子必须解决的只有一个——锤钉子。 NGINX 的微服务参考架构例如，包括几种不同的模型，它们提供了使用微服务解决问题的连续方法。

服务网格架构中汇集的元素（例如 NGINX、容器、Kubernetes 和微服务）作为一种架构方法，在非服务网格实现中也可以同样高效。 例如，Istio 被设计为完整的服务网格架构，但其模块化意味着开发人员可以仅选择和实现他们需要的技术组件。 考虑到这一点，即使您不确定是否能够在应用程序中完全实现服务网格概念，清晰地理解它也很重要。

模块化单体和 DDD

来源： habr.com

添加评论