一盏茶的时间初探网格服务架构Istio

前言

微服务架构2.0 Service Mesh架构框架方面，业内陆续开源了不少优秀框架，主流两个：Service Mesh产品Istio 和 AWS App Mesh，我们将从多角度探索与实践Istio。

什么是Istio?

由官网定义如下：云平台令使用它们的公司受益匪浅。但不可否认的是，上云会给 DevOps 团队带来压力。为了可移植性，开发人员必须使用微服务来构建应用，同时运维人员也正在管理着极端庞大的混合云和多云的部署环境。Istio 允许您连接、保护、控制和观察服务。

我们可以看到Istio主要做微服务治理，并且主要分为四个功能： 1、服务之间建立一个连接 2、连接通信之间整数等安全性 3、连接进行流量管理等控制 4、服务连接监控、日志等观察服务

为了保证数据不丢，我们尽可能的设置较大的重试次数（参数是retries），如果重试失败了，对异常进行处理，可以把消息保存到另外安全到地方。

K8s、Istio相辅相成

下图可以看出，Istio可以解决Kubernetes的服务治理缺陷，功能上两者进行了一个互补的结合，解决了云原生服务治理、云原生基础设施。

Istio的架构

网格服务，通常和一系列网络代理组成，其主要在于代码无侵入、网络代理，与应用程序部署在一起，但是应用程序却不知情。

主要架构在于数据平面（Data Plane）和控制平面（Control Plane），

• 数据平面：由一组和业务服务（如下图ServiceA 和 ServceB）成对出现的Sidecar代理（Envoy）构成，它的主要功能是接管服务的进出流量或服务转发，并且与控制平面的 Mixer 通讯，接受调度策略。
• 控制平面：主要包括了Pilot、Mixer、Citadel和Galley共4个组件，主要功能是通过管理和配置 Envoy 来管理流量，此外，控制平面配置 Mixers来实施路由策略并收集检测到的监控数据。

Istio核心组件

• Envoy 是一个用 C ++开发的高性能代理、CNCF第三个毕业项目，所以性能和可用性都是比较好的，对于Envoy有四个概念【LDS（监听器发现服务）、RDS（路由发现服务）、CDS（集群发现服务）、EDS（服务发现服务）】,每一个 pod 中都必须要部署一个 Sidecar。

ps: 之后会在代码配置中重新标志这块知识点。

• Pilot 主要的作用是配置和管理Envoy代理，为高级路由（例如，A / B 测试，金丝雀部署等）提供流量管理功能，以及异常控制，如：超时，重试，断路器等。 下图是Pilot的原理图，主要的规则数据来源于用户手动配置（路由规则）以及k8s（pod等信息）、Mesos来的一些元数据，通过proxy（Envoy）进行流量转发。

• Mixer 是一个独立于平台的组件，负责在整个 Service Mesh 中执行访问控制和使用策略，并从 Envoy 代理和其他服务收集监控到的数据。 提供APi服务，可以自研监控分析PAM平台对接Mixer。

• Citadel 通过内置身份和凭证管理，提供强大的服务到服务和最终用户身份验证。我们可以使用 Citadel 升级 Service Mesh 中的未加密流量。我们可以使用 Istio 的授权功能来控制谁可以访问服务。

• Galley 负责配置的获取、处理和分发。Gally使用了一种叫作MCP（Mesh Configuration Protocol，网格配置协议）的协议与其他组件进行通信。

Bookinfo微服务源码分析

理解上述概念后，大家可以拿Istio官网提供的一个微服务Book项目进行上手操作，项目地址：https://istio.io/zh/docs/examples/bookinfo

bookinfo 应用一共包含四个微服务：Productpage、Details、Reviews、Ratings。

• Productpage 使用 Python 开发，负责展示书籍的名称和书籍的简介。
• Details 使用 Ruby 开发，负责展示书籍的详细信息。
• Reviews 使用 Java 开发，负责显示书评。
• Ratings 使用 Node.js 开发,负责显示书籍的评星。

Service Mesh 的应用难点

企业是在原有技术栈的基础上引入 Service Mesh，从实际的应用实践情况来看，往往会存在以下 4 种问题： 1、Service Mesh 模式在业务每次远程调用，通信链路会变长，必将增加请求的响应延迟，性能损耗会被明显放大。 2、基础设施与业务解耦带来的复杂性对运营系统的易用性和 Service Mesh 的稳定性要求极高，否则排查问题时很可能会面临根本无从下手的情况。 3、服务通信框架及治理系统技术栈往往不是云原生优先支持的 GRPC 和 HTTP，在 RPC 框架不兼容的背景下改造成本和挑战非常大。 4、增加基础设施团队的运维成本，并且遇到业务问题，定位问题涉及到业务研发团队和基础设施研发团队频繁沟通交互，自然成本也会相应增加。

小结及预告

通过本文，相信读者对微服务的概念和 Istio 的架构有了一定程度的理解。在微服务领域，它最大的优势是解耦应用业务，企业能够彻底从业务角度考虑问题，同时还可以与容器编排部署平台的集成，成为企业级应用编排部署和服务治理的标准形态。

读者有兴趣可持续关注，下面将持续更新Istio应用及剖析

·END·