服务网格：为什么选择Istio？

在Istio Service Mesh中，必须说一说以下基本要点：

 

• 什么是服务网格？

• 为什么我们需要服务网格？

• 可用的服务网格类型以及为什么使用Istio？

• Istio-体系结构和实现。

• Istio组件。

• Istio功能。

什么是服务网格？

在任何基于微服务的体系结构中，只要存在从一个微服务到另一个微服务的服务调用。我们无法推断或调试网络服务调用中发生的情况。 

如果无法正确诊断如果出现意外情况，那可能会导致很多问题。例如; 性能问题，安全性，负载均衡等，跟踪服务调用或服务调用的可观测性（链路追踪）。

当必须迎合更多的微服务以使任何应用程序正常运行时，此问题的严重性就会成倍增加。

服务网格是用于处理服务到服务通信的专用基础结构层。它负责通过构成现代云原生应用程序的复杂服务扩展和传递可靠请求。实际上，服务网格通常被应用在轻量级网络代理的阵列，这种轻量级网络代理与应用程序代码一起部署，而无需了解应用程序。

 

 

可用的服务网格

集群生态系统中有三个主要的竞争者争夺服务网格。所有这些解决方案都是开源的。

• Consul Connect：Consul Connect使用安装在每个节点上的代理作为后台驻留程序集，该后台驻留程序与处理流量路由和转发的Envoy Sidecar代理进行通信。它强调服务发现和服务身份管理。与Istio一样，它使用Envoy代理和sidecar模式。

• Linkerd：Linkerd设计为轻量级的服务网格，可以放置在任何现有平台的顶部。它具有非常简单的安装和CLI工具，不需要使用平台管理员。它使用RUST作为代理。它仅适用于Kubernetes。

• Istio：Istio是Kubernetes本地解决方案，最初由Lyft发布。它的功能包括针对HTTP，gRPC，WebSocket和TCP通信的自动负载平衡。它提供对流量行为的细粒度控制，提供丰富的路由规则，重试，故障转移和故障注入。Istio是第一个包含开发人员真正想要的附加功能的工具，例如深度分析。

为什么通过链接器和Consul Connect进行Istio？

到目前为止，Istio在这三个服务网格中具有最大的功能和灵活性：

• 级联故障预防（断路）。

• 身份验证和授权。服务网格可以授权和验证从应用程序外部和内部发出的请求，仅将经过验证的请求发送到实例。

• 弹性功能（重试，超时，期限等）。

• 强大的负载均衡算法。

• 控制请求路由（对于CI / CD发行模式等很有用）。

• 在通信端点之间引入和管理TLS终止的能力。

• 丰富的度量标准集，以在服务到服务层提供检测。

• 服务发现。当实例需要与其他服务进行交互时，它需要找到（发现）其他服务的可用实例。

• 容器编排框架。

架构与实现

 

 

Istio服务网格周围的流量分为两部分，分别是：

• 数据平面流量

• 控制平面交通

数据平面

Envoy：用C ++开发的高性能代理可提供动态服务发现，负载均衡，TLS终止，HTTP / 2和gRPC代理，断路器，运行状况检查，具有基于百分比的流量拆分的分阶段推出，故障注入，丰富的指标。

控制平面

Pilot：Istio中用于流量管理的核心组件是试点，它可以管理和配置部署在特定Istio服务网格中的所有Envoy代理实例。

Mixer：混合器是与平台无关的组件。Mixer跨服务网格实施访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据。代理提取请求级别属性，并将其发送到Mixer进行评估。

Citadel：Citadel通过内置的身份和凭据管理提供强大的服务和最终用户身份验证。您可以使用Citadel升级服务网格中的未加密流量。使用Citadel，运营商可以根据服务身份而不是网络控制来实施策略。

使用Istio的一些核心用例是：

• 性能调试。

• 流量管理（负载均衡和加权平均）。

• 断路器。

• 安全。

结论

到目前为止，Istio具有这三个服务网格中最多的功能和灵活性，但具有灵活性...也会产生复杂性。最好手动管理Istio，而不要依赖于云提供商的实施。它降低了成本和复杂性。

对于仅支持Kubernetes的简单用法，Linkerd可能是最佳选择。

如果一个同时包含Kubernetes和VM且不需要Istio复杂性的异构环境，那么Consul可能是最好的选择。

你需不需要一个充满技术氛围的学习交流群？扫码就行：