Istio落地之旅 - ServiceMesh和Istio

从2021年的下半年开始,笔者所在的基础架构团队开始探索ServiceMesh及Istio在生产环境中落地,经过半年已经小有成果,仅以此系列文章,给大家介绍我们在落地过程中的一系列探索和思考。
这篇是开章,主要介绍为什么我们要做这个,以及介绍serviceMesh 和 Istio为主。

为什么我们要做ServiceMesh

微服务架构

​     在微服务架构中,一般开发会将应用程序分解为多个具有不同特性的服务,并将其分别独立部署,服务之间的交互通过网络协议通信做数据交互,如rpc协议。
​     举个例子:一个下单流程,我们可能会经过商品服务,订单服务,支付服务等等。这些服务都是通过网络相互通信,如果有一个下单,他会先去拉商品信息,然后生成订单,最后调用支付这些
demo.png

​     这种类型的架构被称之为微服务架构。这种架构有几个好处,我们可以将一个庞大的系统,拆分为一个个小的系统,每个系统由独立的人员进行开发维护,各个开发人员也可以选择各自熟悉的技术和语言,他们拥有独立部署和发布服务的自主权。
​     而要满足这种机制,背后需要依赖一套约定标准化的微服务体系架构,这些都依靠通信网络来支撑。一些业内成熟的方案如: dubbo,springCloud这些。

为什么我们需要ServiceMesh

​     上文我们简单介绍了下微服务架构。我们试想一下,当你的服务数量膨胀到一个很高的程度,他们之间的网络通信也在增加,一次简单的调用可能会跨十几个项目。

造成这个情况的原因可能会比较复杂。如业务团队过分的将粒度拆的过细,或者公司业务的增长,他们之间的服务变的非常多。笔者所在的公司,现在大概有4000多个服务在线上跑着,服务间每秒的调用量在1000W左右次。

​     这时候,我们发现服务间的管理和监控变的相当复杂。而最头疼的就是架构升级和中间件升级变的异常困难,如我们将微服务框架升级一个版本,需要考虑到低版本的应用,这样我们需要被动去做很多兼容,而去推动那么多业务团队进行升级,这也是比较困难的一件事情,耗费了大量的人力 ​

      另一个就是发布灰度,我们知道,框架中间件的升级,很依赖灰度的过程,之前我们都是找一个流量低的团队,让他们接最新的中间件进行一定程度的灰度,这种方式很依赖业务同学的观测,而对于框架中间件的同学,可观测的能力很弱。​     

     我们需要一个体系,让业务开发更关注于业务,而基础团队更关注于基础设施。这一些原因,让我们把逐渐把目光投到了ServiceMesh....

ServiceMesh概述

​     ServiceMesh(服务网格),他被定义为,一个专门的基础设施层,用于管理服务与服务之间的通信,让其可管理,可观测,可控制。官方的解释比较晦涩,在我个人的理解中,ServiceMesh就是关于服务之间的通信一套体系。

​     那么,ServiceMesh是怎么帮助通信了的呢? ​

     首先,通信是什么? 通信就是处理入站出站请求的任何代码,重试逻辑,超时,流量的路由,如微服务中我们常用的rpc模块,这些都是随着我们编译一起构建起来的。因此,当A服务调用B服务的时候,请求都要经过这块代码,这块代码决定了怎么来处理这个请求,如下
demo (1).png
​     我们会看到每个服务都会包含一个通信SDK。当我们的公司的语言都是一样的时候,这没什么,只需要包一个专门的通信包,并让各个团队接入就行了。但当我们无法控制各个团队的语言的时候呢,这时候我们需要被动的去兼容各个团队的语言体系。而如果,我要升级通信包的话,需要全链路的升级,或者我们要去做兼容。这也就是我上面说的弊端。

ServiceMesh做了什么

​     ServiceMesh 将通信,重试,超时等等从服务SDK中剥离出来,并将其移到了一个单独的基础设施层。在ServiceMesh下,基础设施层是一个网络代理的阵列,这些网络代理的集合处理服务之间的所有通信逻辑。我们称这些代理为sideCar,因为他与每个服务并存。
demo (2).png

   以前我们让product和order之间直接通信,现在我们会发现他们之间走了一层代理,ServiceMesh就是以这样一种方式控制了每一次出入站的请求。这种代理的集合形成的网格,称为ServiceMesh(服务网格) ​ 将通信逻辑从业务应用中剥离出来,可以使业务开发人员更关注于业务,而基础设施的开发更关注网格管理就行了。 ​

    ServiceMesh 为我们提供了一种一致的方式来连接,管理,观测微服务。网格内的代理捕获了网格内所有的请求,我们可对其进行流量监控,指标埋点,高可用熔断限流,等等之前在客户端SDK做的事情,都可以迁移至代理层。

Istio

​    Istio是ServiceMesh的开源实现。从宏观上看他支持以下几个主要功能

1. 流量管理

​    利用配置,我们可以控制服务之间的流量。设置短路器,超时和重试都可以通过简单的配置改变并完成。

2. 可观测性

​    Istio通过跟踪,监控和记录让我们能更好的监控服务,并能快速的发现问题,解决问题

3. 安全性

​     Istio可以在代理层面做管理认证,授权和加密等,并快速的配置到各个服务

核心组件

​     Istio核心组件有两个:控制平面和数据平面 ​ 一般在构建大型分布式系统的时候,将控制面和数据面分离开是一种常见的模式。数据面会直接和具体的应用交互,而控制面的组件会下发一系列的配置和指令,帮助数据面完成具体的工作。 ​ 我们看下Istio的架构: demo (3).png

Envoy (数据平面)

​     Envoy是C++开发的高性能代理。在ServiceMesh中,Envoy代理作为一个sidecar容器注入到应用容器旁。然后拦截该服务的所有进出口流量。注入的代理一起构成ServiceMesh的数据平面 ​ Envoy也是唯一和流量进行交互的组件。我们可以借助他做到负载均衡,故障注入等等。另外Envoy也支持比较好的扩展,基于WebAssembly(WASM),这样我们可自定义执行策略,也基于此做监控埋点等等。

阿里也推出了自研的数据面MOSN

Istiod (控制平面)

​     Istiod 是控制面的组件,他提供服务发现,配置下发等管理功能。Istiod一般采用YAML文件编写高级规则,将其转化为Envoy可操作的配置,并将其下发给网格中所有的sidecar ​ Piolt 组件就是Istio内部抽象出特定平台的服务发现机制,并将其转化为sidecar 可以使用的标准格式 ​    另外Istiod也可以做身份认证,权限管理等TLS的功能

总结

​     今天简单和大家介绍了一下我们选择ServiceMesh的背景和Istio的组件介绍,后面会逐步的和大家介绍Istio的相关使用,并结合具体的场景和大家分享。

 


关于作者

silen
三流码农
获得点赞
文章被阅读