Service Mesh实战（Istio）

01 介绍

• 构建微服务是每个开发者都会面对的问题
• 如何管理好服务间的网络通信？
• 云原生架构三架马车

1. Kubernetes：云原生操作系统
2. Service Mesh：应用的网络通信层，让应用与服务通信解耦，让开发者只关注业务
3. Serverless：让应用不用关注机器与实例

• 学完收获

1. 深入地理解 Service Mesh技术的概念、核心功能、实践方法
2. 熟练掌握istio在流量控制、安全、服务可观测性等方面的功能
3. 将Service Mesh技术应用到项目中，解决现有系统服务通信方面的痛点
4. 理解系统要点、技术发展趋势，并学会技术选型

02 综述

目录

1. 概念篇：Service Mesh相关概念（起源、演进过程、核心功能、产品对比）
2. istio入门篇：各个功能模块详细介绍（流量控制、安全、可观测性）
3. 实验篇：将大的模块分解成一个个功能点，每个功能点对应一个任务；首先从istio安装与部署开始，以做任务的方式学习核心的知识点，如流量控制中的路由、熔断、超时重试等常见功能，在可观测性方面，介绍如何事例Prometheus实现指标收集，并用Grafana进行展示 ，以及用jeager完成分布式追踪
4. 实战篇：通过几个最佳实践让你能把Service Mesh应用到自己的项目，并解决实际出现的问题

03 Service Mesh的起源：为什么会出现Service Mesh技术？

• 有些人把Service Mesh称为第二代微服务

微服务架构的特性

围绕业务构建团队

• 单体应用典型模式：左边是人员分工，右边是应用的样子

• 微服务：整个开发团队会围绕着业务去构建，所以它的结构跟单体是不太一样的

康威定律：一个团队的结构会决定这个团队最终开发的产品的结构

去中心化的数据管理

• 微服务：不同业务持有不同的数据库

• 微服务架构优势

1. 团队层面：内聚，独立开发业务，没有依赖，沟通成本低
2. 产品层面：服务彼此独立、独立部署、没有依赖

• 微服务是软件架构的银弹吗？

银弹理论：没有任何一种技术和管理上的进步，可以极大的提升生产效率

软件开发的本质就是取舍，总是在天平的两端不断地摇摆，去寻找其中的平稳点。如算法中很重要的一个原理就是用空间换时间，或者用时间换空间

曾经一个笑话：程序员有50%的时间都是在给函数起名上

微服务面临什么样的问题？

• 服务间调用中断了怎么办？随着服务越来越庞大、系统功能越来越多，像下图所示，如何找到问题的节点呢？——服务间网络通信

为什么网络通信是微服务架构的痛点？

• 分布式计算的8个谬论（Fallacies of Distributed Computing Explained）

1. 网络是可选的
2. 网络延迟是0
3. 带宽是无限的
4. 网络是安全的
5. 网络拓扑从不改变
6. 只有一个管理员
7. 传输成本是0
8. 网络是同构的

在分布系统中，网络问题是经常出现的，是一个主要出现问题。而微服务这种架构因为服务变得越来越多，变得更离散，交互也越来越多，所以网络问题出现概率会更大，因此这就是微服务架构最大的一个痛点

如何管理和控制服务间的通信？

1. 服务注册/发现
2. 路由、流量转移
3. 弹性能力（熔断、超时、重试）
4. 安全（如何授权、身份认证）
5. 可观察性

04 Service Mesh的发展：Service Mesh技术是如何演进的？

参考阅读：《Pattern: Service Mesh》，介绍Service Mesh如何从最初形态演变成现在的形态的

Service Mesh的演进过程

第一阶段：控制逻辑和业务逻辑耦合

• 得在业务代码中加入熔断和服务发现功能

第二阶段：公共库

• 把这些逻辑封装成工具包，把业务和工具分离开。比如说Twitter的Finagle、Spring Cloud的一些组件、Netflix开源的一些产品
• 公共库最大的好处就是解耦、消除重复
• 最大的问题是成本问题（人力、时间），其次是语言绑定的，然后代码是有侵入的

第三阶段：代理

• 把公共库做成代理 ，如nginx
• 但是中间件需要做一些硬编码

第四阶段：边车模式（Sidecar）

• 由sidecar处理所有的网络请求，处理完成后再把请求转发给应用本身

第五阶段：Service Mesh的出现

• 一个pod由两个container组成

1. 微服务
2. sidecar

• 一个应用中包含很多微服务，而这些微服务都伴有这些sidecar，这些 sidecar组合起来的一个网络就是Service Mesh

Service Mesh演进总结

• Service Mesh V2：增加了控制平面

05 微服务通信的济世良方：什么是Service Mesh？它能帮你做什么？

Service Mesh的定义

• 2017年4月份首次提出

• Service Mesh是一个基础设施层，用来处理服务与服务之间的通信，它主要的功能是在云原生应用这种复杂的服务拓扑情况下进行可选地请求分发，一般情况下它会实现为一组轻量化的网络代理 ，部署在你的应用代码的旁边，并且跟你的应用是完全透明
• 四个关键点

1. 本质：基础设施层
2. 功能：请求分发
3. 产品形态：一组网络代理
4. 特点：完全和你的应用透明

Service Mesh：一个用来进行请求转发的基础设施层，它通常是以Sidecar形式部署，并且对你的应用透明

Service Mesh的产品形态

• 下图所示，左边是第一代服务网格，右边是第二代服务网格（多了控制平台）

1. 数据平面：Sidecar组合
2. 控制平面：进行总体的控制

• 这两个平面组合在一起就是现在Service Mesh的技术形态

• Service Mesh是Sidecar的网络拓扑模式

Service Mesh的主要功能

流量控制

最重要功能

1. 路由（蓝绿部署、灰度发布、A/B测试）
2. 流量转移
3. 超时重试
4. 熔断
5. 故障注入
6. 流量镜像

策略

1. 流量限制
2. 黑白名单

网络安全

1. 授权及身份认证

可观测性

1. 指标收集和展示
2. 日志收集
3. 分布式追踪

Service Mesh和Kubernetes的关系

• Kubernetes：相当于操作系统
• Service Mesh：网络通信层

Service Mesh和API网关的异同点

Service Mesh

• 由Sidecar完全接管发送到应用的请求，处理完之后再发送到另外的微服务
• 对应用网络细节进行描述

API网关

• API网关实际上是部署在应用的边界的，并没有侵入到应用内部，主要功能是对内部的API进行聚合和抽象，以方便外部进行调用
• 附着在应用的边界，对流量进行一个抽象

两者异同

1. 功能有重叠，但角色不同
2. Service Mesh在应用内，API网关在应用之上（边界）

Service Mesh技术标准

UDPA：统一的数据平面API

• 目的是为不同的数据平面提供一个统一的API，方便进行无缝接入，由云原生基金会提出来的，背后公司是google以及envoy数据平面的开发者lyft

SMI（Service Mesh Interface）

• 目标和UDPA类似，不过它侧重的是控制平面，希望为用户提供一个统一的使用体验，通过这样一个标准去接入你的控制平面，而不用关心控制平面具体的实现细节，最初是微软作为发起人，几乎所有玩家都参与进来了，唯一缺失了google和亚马逊

06 列王的纷争：市面上有哪些主流的Service Mesh产品

有哪些主流的Service Mesh产品？

1. Linkerd（第一次Service Mesh产品）
2. envoy
3. Istio
4. 亚马逊
5. 微软

Service Mesh产品发展史

LINKERD

• 失败最主要问题

1. 作为一个数据平面，对比envoy没有什么优势
2. 开发语言选择了Rust，得不到社区支持力量支持
3. 作为独立的产品，背后没有云厂商支持

Envoy

Istio

AWS App Mesh

• 最大特点是支持自家的多种计算资源部署

国内发展情况

1. 蚂蚁金服：SOFA Mesh，MOSN数据平面；基于istio开发，主要使用了istio内部的Pilot控件，弃用envoy，使用自研的MOSN作为数据平面，双11已经落地，支持集群几十个，pod数达到了数十万个，是目前世界上最大的一个Service Mesh落地的案例
2. 几大云厂商（腾讯、阿里、百度）
3. 华为、微博

Service Mesh市场竞争

07 王者的诞生：为什么istio有如此高的呼声？

什么是istio？

• 官方定义：它是一个完全开源的服务网格，作为透明的一层接入到现有的分布式应用中。它也是一个平台，可以与任何日志、遥测和策略系统进行集成。Istio多样化的特性让你能够成功且高效地运行微服务架构，并提供保护、连接和监控微服务的统一用法

• 要点

1. 是服务网格产品
2. 拥有服务网格的基本特性
3. 服务微服务架构
4. 功能：连接、控制、保护、观测微服务系统

• istio来源于希腊语，意思是扬帆起航。Kubernetes也来源于希腊语，意思是舵手。google给istio起名是具有深意的，不仅有kubernetes这个舵，还有istio这个帆，由它们一起驾驶着你的云原生应用扬帆起航，驶向彼岸

为什么istio能C位出镜？

1. 出击及时（2017年5月发布0.1版本）
2. 三巨头光环加身（两巨头+独角兽）
3. 第二代Service Mesh
4. Envoy的加入让Istio如虎添翼
5. 功能强大

为什么使用istio？

优势

1. 轻松构建服务网格
2. 应用代码无需更改
3. 功能强大

Istio核心功能

流量控制

1. 路由（灰度发布、蓝绿部署、AB测试）
2. 流量转移
3. 弹性（超时、重试、熔断）
4. 测试（故障注入、流量镜像 ）

安全

1. 认证
2. 授权

可观察性

1. 指标
2. 日志
3. 追踪

策略

1. 限流
2. 黑白名单

Istio的发布历程

Istio会成为下一个Kubernetes吗？

Istio的意义

• istio的出现实际上重新定义了微服务的开发方式，可以轻松地在微服务架构中植入Service Mesh技术
• 大幅降低微服务应用的开发门槛，只关注业务本身
• 统一运维和开发方式来简化微服务的开发流程

Istio的战略使命

• 会为google/ibm提供一个杀手级的特性
• 延续google在云原生市场上的战略布局

08 Istio的自我救赎：为什么Istio发生了两次重大的架构变更？

架构1.0版本

1. Pilot：配置分发组件，把控制平面的信息转化成数据平面识别的格式，然后分发给所有sidecar
2. Citadel：负责安全相关功能，比如授权、认证
3. Mixer：两部分功能，一部分是遥测，从数据平面进行指标数据的收集；另外一部分功能就是设置策略，如限流和黑白名单。Mixer是个插件模型，可以扩展后端不同基础设施，并添加到这个模型中，如后端日志、配额等组件。存在以下两个主要问题：第一是性能，需要和数据平面进行两次通讯，而这个组件又是单独部署的，每次请求都需要和进程外进行通讯，降低整个请求的效率；第二个问题是插件模型产生了耦合，如果要添加新插件或对已有插件进行修改时，不得不重新部署mixer