ServiceMesh&Istio入门

参考：微信公众号:架构师之路

 

 ServiceMesh(1)

ServiceMesh究竟解决什么问题？

服务网格（ServiceMesh）这两年异常之火，号称是下一代微服务架构，接下来两个月，准备系统性的写写这个东西，希望能够让大家对最新的架构技术，有个初步的了解。

画外音：我的行文的风格了，“为什么”往往比“怎么样”更重要。

 

互联网公司，经常使用的是微服务分层架构。

画外音：为什么要服务化，详见《服务化到底解决什么问题？》。

 

随着数据量不断增大，吞吐量不断增加，业务越来越复杂，服务的个数会越来越多，分层会越来越细，除了数据服务层，还会衍生出业务服务层，前后端分离等各种层次结构。

画外音：分层的细节，详见《互联网分层架构演进》。

 

不断发现主要矛盾，抽离主要矛盾，解决主要矛盾，架构自然演进了，微服务架构，潜在的主要矛盾会是什么呢？

 

引入微服务架构，一般会引入一个RPC框架，来完成整个RPC的调用过程。

如上图粉色部分所示，RPC分为：

• RPC-client，它嵌在调用方进程里

• RPC-server，是服务进程的基础

画外音：《离不开的微服务架构，脱不开的RPC细节》。

 

不只是微服务，MQ也是类似的架构：

如上图粉色部分所示，MQ分为：

• MQ-send-client

• MQ-server

• MQ-recv-client

画外音：《MQ，互联网架构解耦神器》。

 

框架只是第一步，越来越多和RPC，和微服务相关的功能，会被加入进来。

 

例如：负载均衡

如果要扩展多种负载均衡方案，例如：

• 轮询

• 随机

• 取模

• 一致性哈希

RPC-client需要进行升级。

 

例如：数据收集

如果要对RPC接口处理时间进行收集，来实施统一监控与告警，也需要对RPC-client进行升级。

画外音，处理时间分为：

• 客户端视角处理时间

• 服务端视角处理时间

如果要收集后者，RPC-server也要修改与上报。

 

又例如：服务发现

服务新增一个实例，通知配置中心，配置中心通知已注册的RPC-client，将流量打到新启动的服务实例上去，迅猛完成扩容。

 

再例如：调用链跟踪

如果要做全链路调用链跟踪，RPC-client和RPC-server都需要进行升级。

 

下面这些功能：

• 负载均衡

• 数据收集

• 服务发现

• 调用链跟踪

• …

其实都不是业务功能，所以互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能，而业务线的技术部门直接使用相关框架、工具与平台，享受各种“黑科技”带来的便利。

 

完美！！！

 

理想很丰满，现实却很骨感，由于：

• RPC-client，它嵌在调用方进程里

• RPC-server，是服务进程的基础

 

往往会面临以下一些问题：

• 业务技术团队，仍需要花时间去学习、使用基础框架与各类工具，而不是全心全意将精力花在业务和产品上

• client要维护m个版本， server要维护n个版本，兼容性要测试m*n个版本

• 如果要支持不同语言，往往要开发C-client，Python-client，go-client，Java-client多语言版本

• 每次“黑科技”的升级，都需要推动上下游进行升级，这个周期往往是以季度、半年、又甚至更久，整体效率极低

画外音：兄弟，贵司推广一个技术新产品，周期要多长？

 

这些耦合，这些通用的痛点，有没有办法解决呢？

一个思路是，将服务拆分成两个进程，解耦。

• 一个进程实现业务逻辑（不管是调用方，还是服务提供方），biz，即上图白色方块

• 一个进程实现底层技术体系，proxy，即上图蓝色方块

画外音：负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现。

• biz和proxy共同诞生，共同消亡，互为本地部署，即上图虚线方框

• biz和proxy之间，为本地通讯，即上图黑色箭头

• 所有biz之间的通讯，都通过proxy之间完成，proxy之间才存在远端连接，即上图红色箭头

 

这样就实现了“业务的归业务，技术的归技术”，实现了充分解耦，如果所有节点都实现了解耦，整个架构会演变为：

• 绿色为biz

• 蓝色为proxy

整个服务集群变成了网格状，这就是Service Mesh服务网格的由来。

 

架构演进，永无穷尽，痛点多了，自然要分层解耦。希望大家有收获，后续再细聊SM的设计与架构细节。

 

思路比结论更重要。

 

 

 

 

ServiceMesh(2)

Istio究竟是干嘛的？

上一篇介绍了《ServiceMesh究竟解决什么问题？》，当微服务架构体系越来越复杂的时候，需要将“业务服务”和“基础设施”解耦，将一个微服务进程一分为二：

• 一个进程实现业务逻辑，biz，即上图白色方块

• 一个进程实现底层技术体系，proxy，即上图蓝色方块，负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现

 

如此解耦之后：

• biz不管是调用服务，还是提供服务，都只与本地的proxy进行本地通信

• 所有跨网的通信，都通过proxy之间进行

 

要聊ServiceMesh，就不得不提Istio，它是ServiceMesh目前最流行的实践，今天说说Istio是干啥的。

画外音：不能落伍。

 

什么是Istio？

 

Istio是ServiceMesh的产品化落地，它的一些关键性描述是：

• 帮助微服务之间建立连接，帮助研发团队更好的管理与监控微服务，并使得系统架构更加安全

画外音：Istio helps you to connect, secure, control, and observe microservices.

 

• 帮助微服务分层解耦，解耦后的proxy层能够更加专注于提供基础架构能力，例如：

（1）服务发现(discovery);

（2）负载均衡(load balancing);

（3）故障恢复(failure recovery);

（4）服务度量(metrics);

（5）服务监控(monitoring);

（6）A/B测试(A/B testing);

（7）灰度发布(canary rollouts);

（8）限流限速(rate limiting);

（9）访问控制(access control);

（10）身份认证(end-to-end authentication);

画外音：佩服，硬是凑齐了十条，其实SM还能提供更多基础服务功能。

 

• 使得业务工程团队与基础架构团队都更加高效的工作，各自专注于自己的工作，更好的彼此赋能

画外音：说的还是解耦。

 

Istio官网是怎么吹嘘自己的？

画外音：这个问题的另一个问法是“为什么大家要来用Istio”。

 

Istio非常牛逼，如果要实施ServiceMesh，必须用Istio，因为：

• 可以通过，在现有服务器新增部署边车代理(sidecar proxy)，应用程序不用改代码，或者只需要改很少的代码，就能实现上述N项基础功能

画外音：你信了么？

 

 

• 可以通过，控制后台，简单改改配置，点点按钮，就能管理和查看上述N项基础功能

 

• 以下特性，Istio在这个环节里进行了附加说明：

（1）负载均衡支持多协议，HTTP, gRPC, WebSocket, TCP；

（2）通过路由、重试、故障转移对流量进行细粒度流控；

（3）通过可插拔策略层以及可配置API，能够支持流量访问控制、限速、配额管理；

（4）自动度量、日志收集、调用跟踪；

（5）服务到服务的身份认证；

 

Istio的核心特性是什么？

 

Istio强调了它提供的五项关键特性：

• 流控(traffic management)

画外音：断路器(circuit breakers)、超时、重试、高可用、多路由规则、AB测试、灰度发布、按照百分比分配流量等。

 

• 安全(security)

画外音：加密、身份认证、服务到服务的权限控制、K8S里容器到容器的权限控制等。

 

• 可观察(observability)

画外音：追踪、监控、数据收集，通过控制后台全面了解上行下行流量，服务链路情况，服务运行情况，系统性能情况，国内微服务架构体系，这一块做得比较缺乏。

 

• 平台无关系(platform support)

画外音：K8s，物理机，自己的虚机都没问题。

 

• 集成与定制(integration and customization)

画外音：可定制化扩展功能。

 

Istio的吹嘘与特性，对于国外很多通过RESTful提供内网服务的公司，很有吸引力，但相对于国内微服务架构，未必达到了很好的拉拢效果：

（1）国内基本都是TCP的RPC框架，多协议支持未必是必须的；

（2）RPC框架里，路由、重试、故障转移、负载均衡、高可用都是最基础的；

（3）流控、限速、配额管理，是服务治理的内容，在微服务架构初期是锦上添花；

（4）自动度量，系统入口出口数据收集，调用跟踪，可观察和可操控的后台确实是最吸引人的；

（5）服务到服务的身份认证，微服务基本是内网访问，在架构初期也只是锦上添花；

 

另外一个花边，为什么代理会叫sidecar proxy？

看了上图就容易懂了，biz和proxy相生相伴，就像摩托车(motor)与旁边的车厢(sidecar)。未来，sidecar和proxy就指微服务进程解耦成两个进程之后，提供基础能力的那个代理进程。

 

Istio这么牛逼，它的核心架构如何呢？

且听下回分解。

 

 

 

 

ServiceMesh(3)

Istio分层架构？80%的人有误解

前篇：

《ServiceMesh究竟解决什么问题》

《什么是Istio，ServiceMesh最流行落地》

 

Istio是ServiceMesh的产品化落地：

• 它帮助微服务之间建立连接，帮助研发团队更好的管理与监控微服务，并使得系统架构更加安全

 

• 它帮助微服务分层解耦，解耦后的proxy层能够更加专注于提供基础架构能力，例如：

（1）服务发现(discovery)

（2）负载均衡(load balancing)

（3）故障恢复(failure recovery)

（4）服务度量(metrics)

（5）服务监控(monitoring)

（6）A/B测试(A/B testing)

（7）灰度发布(canary rollouts)

（8）限流限速(rate limiting)

（9）访问控制(access control)

（10）身份认证(end-to-end authentication)

等功能。

 

• 它使得业务工程团队与基础架构团队都更加高效的工作，各自专注于自己的工作，更好的彼此赋能

 

今天来说一下Istio的核心架构设计。

 

关于Istio的架构设计，官网用了这样一句话：

逻辑上，Istio分为：

• 数据平面(data plane)

• 控制平面(control plane)

这两个词，是Istio架构核心，但又是大家被误导最多的地方。

 

数据平面和控制平面，不是ServiceMesh和Istio第一次提出，它是计算机网络，报文路由转发里很成熟的概念：

• 数据平面(data plane)：一般用来做快速转发

• 控制平面(control plane)：为快速转发提供必要的信息

 

画外音：上两图为路由器架构。

 

它的设计原则是：

• 在一个路由设备里，转发是最重要的工作，它具备最高的优先级，数据平面(data plane)的设计核心就是高效转发，如何在最短的时间里处理最多的包，往往使用高效内存管理、队列管理、超时管理等技术实现在硬件里

• 控制平面(control plane)则不然，它要实现路由协议，设备管理，IGMP，ARP协议的，它更偏向于控制与应用，往往由软件实现

画外音：

IGMP（Internet GroupManagement Protocol），一个组播协议；

ARP（Address ResolutionProtocol），这个大家比较熟悉，根据IP地址获取MAC地址；

 

Istio的架构核心与路由器非常类似：

• 服务（最上面的小红框），通过本地通讯与proxy交互

• 数据平面，由一系列proxy组成（中间一层的两个小红框），核心职责是：

（1）高效转发；

（2）接收和实施来自mixer的策略；

• 控制平面（底下的大红框），核心是控制与应用，核心职责是：

（1）管理和配置边车代理；

（2）通过mixer实施策略与收集来自边车代理的数据；

画外音：

（1）sidecar proxy，原文使用的是envoy，后文envoy表示代理；

（2）mixer，不确定要怎么翻译了，有些文章叫“混音器”，后文直接叫mixer；

（3）pilot，galley，citadel，不敢翻译为飞行员，厨房，堡垒，后文直接用英文；

 

如架构图所示，该两层架构中，有五个核心组件。

 

数据平面，有一个核心组件：

Envoy (proxy)

Envoy的核心职责是高效转发，更具体的，它具备这样一些能力：

（1）服务发现

（2）负载均衡

（3）安全传输

（4）多协议支持，例如HTTP/2，gRPC

（5）断路器(Circuit breakers)

（6）健康检查

（7）百分比分流路由

（8）故障注入(Fault injection)

（9）系统度量

 

大部分能力是RPC框架都具备，或者比较好理解的，这里面重点介绍下断路器和故障注入。

 

断路器设计

它是软件架构设计中，一个服务自我保护，或者说降级的设计思路。

 

举个例子：当系统检测出某个接口有大量超时时，断路器策略可以终止对这个接口的调用（断路器打开），经过一段时间后，再次尝试调用，如果接口不再超时，则慢慢恢复调用（断路器关闭）。

 

故障注入设计

它是软件架构设计中，一种故意引入故障，以扩大测试覆盖范围，保障系统健壮性的方法，主要用于测试。

 

国内大部分互联网公司，架构设计中不太会考虑故障注入，在操作系统内核开发与调试，路由器开发与调试中经常使用，可以用来模拟内存分配失败、磁盘IO错误等一些非常难出现的异常，以确保测试覆盖度。

 

控制平面，有四个核心组件：

Mixer

Mixer的一些核心能力是：

（1）跨平台，作为其他组件的adapter，实现Istio跨平台的能力；

（2）和Envoy通讯，实时各种策略

（3）和Envoy通讯，收集各种数据

 

Mixer的设计核心在于“插件化”，这种模型使得Istio能够适配各种复杂的主机环境，以及后端基础设施。

 

Pilot

Pilot作为非常重要的控制平面组件，其核心能力是：

（1）为Envoy提供服务发现能力；

（2）为Envoy提供各种智能路由管理能力，例如A/B测试，灰度发布；

（3）为Envoy提供各种弹性管理能力，例如超时，重试，断路策略；

 

Pilot的设计核心在于“标准化”，它会将各种流控的控制命令转化为Envoy能够识别的配置，并在运行时，将这些指令扩散到所有的Envoy。Pilot将这些能力抽象成通用配置的好处是，所有符合这种标准的Envoy都能够接入到Pilot来。

 

潜台词是，任何第三方可以实现自己的proxy，只要符合相关的API标准，都可以和Pilot集成。

 

Citadel

Citadel组件，它提供终端用户身份认证，以及服务到服务的访问控制。总之，这是一个和安全相关的组件。

 

Galley

Gally组件，它是一个配置获取、校验、处理、分发的组件，它的设计核心在于“解耦”，它将“从底层平台（例如：K8S）获取用户配置”与Istio解耦开来。

 

花边：为什么80%的中文用户对Istio的二层架构的了解是错的？

很多朋友问我，通过什么渠道学习最新的技术知识，我的回答一直是，英文官网。

画外音：本文所有信息来源于Istio1.1英文官网。

 

我在百度搜了下Istio，80%的资料，将二层架构翻译为：

• 数据面板

• 控制面板

画外音：大家可以百度搜一下“istio 控制面板”

 

一开始我极其蒙圈，因为“数据平面”和“控制平面”是非常成熟的翻译，路由器就是使用这个二层架构，ServiceMesh使用相同的架构设计进行解耦，应该不需要创造性翻译呀。

 

后来，我懂了：

• 控制平面(control plane)

• 控制面板(control panel)

半吊子英语的程序员，二手的技术文档，真害人，唉。

 

总结

Istio采用二层架构，五大模块，进行微服务ServiceMesh解耦：

• 数据平面，主要负责高效转发

（1）envoy模块：即proxy；

• 控制平面，主要负责控制与应用

（2）mixer模块：支持跨平台，标准化API的adapter；

（3）pilot模块：控制与配置envoy的大部分策略；

（4）citadel模块：安全相关；

（5）galley模块：与底层平台（例如：K8S）配置解耦；

 

实施与控制分离，经典的架构设计方法，GOT？

思路比结论重要。

 

 

 

 

Istio，灰度发布从未如此轻松

三个问题，回顾前情提要。

 

ServiceMesh解决什么问题？

SM本质是业务服务与底层技术体系的解耦：

• 一个进程实现业务逻辑（不管是调用方，还是服务提供方），biz，即上图白色方块

• 一个进程实现底层技术体系，proxy，即上图蓝色方块

画外音：负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施，都放到这一层实现。

 

什么是Istio？

Istio是ServiceMesh的产品化落地。

 

Istio的分层架构设计如何？

Istio采用实施与控制分离的数据平面与控制平面两层架构。

 

数据平面

• envoy(proxy)：负责高效转发与策略落地[核心]

 

控制平面

• mixer：适配组件，数据平面与控制平面通过它交互

• pilot：策略配置组件[核心]

• citadel：安全组件

• galley：底层平台（例如：K8S）解耦组件

 

整个架构的核心是envoy与pilot。

 

今天起，聊聊Istio的流控，典型如灰度发布。

 

就如同ServiceMesh的设计初衷，是技术体系与业务服务解耦一样，Istio流控模型的本质，是流量控制与服务实例扩展的解耦，更具体的：

• 用户只需要通过控制平面中的Pilot设定期望流量要以什么规则进行路由

• 不需要规定服务实例(service pods)如何接收

• 数据平面Envoy将从Pilot中获取规则和命令，然后落地各类分流策略

 

如上图所示，最开始时，ServiceA访问旧版的ServiceB。

画外音，业务与底层解耦：

（1）灰色圆形为业务Svc服务；

（2）紫色六边形为Envoy代理；

（3）服务与代理之间都是本地访问；

（4）跨网段之间都是Envoy代理交互（蓝色箭头）；

 

如何进行灰度发布呢？

如上图所示，服务A调用服务B，服务B要发布一个灰度版本，需要5%的流量打到服务B的新版本，只需要：

（1）部署服务B的新版本；

（2）控制平面Pilot上进行策略配置，策略同步到Envoy；

（3）数据平面Envoy接收到策略配置，实时分流策略；

画外音：图形上没有画出Pilot和Envoy的交互。

 

搞定，这个过程业务服务与流量控制策略完全解耦，完美！

 

除了基于按流量比例分流的灰度发布，基于应用层的灰度发布通过Istio也非常容易实现。

如上图所示，服务B要发布一个灰度版本，需要把iPhone的流量打到B的新版本，操作流程完全一样（部署服务，Pilot控制，Envoy实施），非常方便。

 

如果Envoy原来只支持按照流量比例分流，不支持基于应用层协议分流，此时只需要：

（1）升级Envoy的分流策略，以及策略控制端Pilot；

（2）调用方服务A不需要升级；

（3）服务方服务B也不需要升级；

 

业务与底层基础设施完全解耦，完美！

画外音：这是Service Mesh的核心理念之一，详见《ServiceMesh究竟解决什么问题》。

 

如果是用传统微服务框架的方式，需要框架升级，调用方与服务方均需要配合升级与重启。

 

最近下班都比较晚，今天先写到这里。Pilot的分层架构如何，它又是如何与Envoy配合实现流控的，且听下回分解。

 

 

 

Istio流控，服务发现，负载均衡，核心流程是如何实现的？

前情提要：

《ServiceMesh究竟解决什么问题？》

《Istio究竟是什么？》

《Istio分层架构设计？》

 

Istio架构体系中，流控(Traffic Management)虽然是数据平面的Envoy Proxy实施的，但整个架构的核心其实在于控制平面的Pilot。

 

灰度发布的过程在《Istio，灰度发布》一文中已经有过描述，今天重点说说Pilot和Envoy的交互流程与内部结构。

 

一、通用交互流程

图示：

• 灰色圆形，为业务服务

• 紫色六边形，为Envoy代理

二者相生相伴。

 

起初，上游调用方ServiceA访问下游服务提供方ServiceB的V1版本，在ServiceB的V2版本部署好之后，调用方如何知道“SvcA切分1%的流量至SvcB的V2版本”这个指令的呢？

 

整个过程主要分为三大步骤：

（1）用户在控制平面的后台，通过Pilot的API，修改A到B的路由策略（标号1）；

（2）Pilot将路由策略固化存储，以便未来新注册的调用方A能够知道当前最新的路由策略；对于已经存在的调用方A，Pilot则通过主动通知的方式告之调用方A对应的Envoy（标号2）；

（3）Envoy作为数据平面，实施最新的路由策略（标号3），在本例中，即将1%的流量导给灰度版本Bv2；

 

二、服务发现与负载均衡

讲了通用的流控策略实施通用流程，而服务发现与负载均衡，只是一个种策略实施的特例：

（1）提供服务的SvcB新增一个Pod（标号1）；

（2）在Pilot后台修改SvcB的集群配置（标号2）；

（3）Pilot将SvcB的最新信息同步给该配置的订阅方（标号3），即SvcB的调用方SvcA对应的Proxy；

（4）SvcA对应的Proxy增加到SvcB的链接（标号4），并实施负载均衡；

画外音：实际是链接到SvcB对应的Proxy。

 

整个过程，与使用配置中心来实施服务发现基本类似。

 

三、请求的入口及出口

ServiceMesh的核心，是技术基础设施与业务服务的解耦，服务A调用服务B，再次强调：

• 一个容器Pod内的一个服务，服务进程（SrvA/SrvB）和边车进程（Proxy）是相生相伴的，他们之间的交互是本地交互（标号1）

• 跨容器Pod之间的远程调用，必须通过Proxy进行（标号2）

 

言下之意，服务A调用服务B，请求的流程是：

SvcA -> SvcA Proxy -> SvcB Proxy -> SvcB

 

响应的流程则反过来：

SvcB -> SvcB Proxy -> SvcA Proxy -> SvcA

 

跨网之间调用，请求的入口和出口，都是Proxy。

 

四、Pilot内部结构

Pilot它的内部结构并不复杂：

（1）Pilot的核心，是各种流控策略的维护，Abstract Model；

（2）必然，Pilot需要提供接口给用户，增删查改这些策略，Rules API；

（3）一方面，Pilot需要保持各类底层基础设施的兼容性，Platform Adapter；

（4）另一方面，Pilot又需要保持不同Proxy实接口的兼容性，Envoy API；

 

这么设计的好处是：

• Istio设计时已经考虑了异构的基础设施，不管底层是K8s还是其他体系，都可以兼容

• 任何第三方可以实现自己的proxy，只要符合相关的API标准，都可以和Pilot集成

 

Pilot与Envoy的配合，是Istio的核心，如此一来：

• 服务发现(discovery)

• 负载均衡(load balancing)

• 故障恢复(failure recovery)

• 服务度量(metrics)

• 服务监控(monitoring)

• A/B测试(A/B testing)

• 灰度发布(canary rollouts)

• 限流限速(rate limiting)

等很多能力都可以实现了。

 

MerviceMesh并没有大家想的复杂。