Service Mesh
微服务(架构风格) -> service mesh（基础设施）
SpringCloud Dubbo 等微服务框架的痛点：
- 侵入性强 业务代码与框架代码混合在一起
- 升级成本高 一旦框架升级，就需要重新进行测试 重新部署上线而跟业务没有太大的关系
- 版本碎片化严重 服务自己独立演化 线上中间件或者框架版本不一，难以统一治理
- 中间件演变困难 由于需要兼容老版本 历史包袱沉重
- 学习曲线不够平滑 单单一个SpringCloud就有大大小小几十个组件
- 功能不全 一些功能现有的微服务框架并没有
从容器到服务网格，一个原因就是因为环境的异构性
痛点往往是技术发展到一定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进
基本概念
Service Mesh 是一个专门处理服务通讯的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，并且对应用服务透明
服务网格带来的变革：
- SDK轻量化
- 由于只需要少量的SDK 微服务治理与业务逻辑的解耦
- 同样由于SDK轻量 异构系统的统一治理，编写不同语言的SDK更加轻松
服务网格相比传统微服务框架的优势：
- 由于服务网格是一个基础设施层 所有的服务间通信都要通过它 所以带来了良好的可观察性
- 通过服务网格 可以很好地通过这个基础设施来对服务间的流量进行控制或者进行故障模拟
- 服务网格提供了保护网络调用的能力和基础设施
- 应用层可以更专注于业务逻辑
服务网格带来的问题：
- 复杂度更高
- 对运维要求更高
- 增加了一个中间层 肯定会有延迟问题
- 平台适配的侵入性
透明通讯
分布式通讯的演化
第一阶段：控制逻辑和业务逻辑耦合
第二阶段：将控制逻辑抽取到独立的库中
第三阶段：抽离出进程外的网络代理
第四阶段：将网络代理以边车的形式注入到应用容器
第五阶段：服务网格
数据平面
- 直接处理入站（业务应用）和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等
- 对应用透明
代理注入
- 基座模式：对应用程序不透明 至少需要一个SDK
- 注入模式：通过在pod注入一个辅助容器实现
流量劫持
- iptables拦截流量交给sidecar处理
- eBPF：在Socket层面直接完成数据转发
- CNI插件
可靠通讯
Envoy在这方面进行了创新，它将代理的转发的行为规则抽象成Listener、Router、Cluster三种资源
控制平面
- 不直接解析数据包
- 与控制平面中的代理通信，下发策略和配置
- 负责网络行为的可视化
- 常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署
ServiceMesh K8S Istio
Kubernetes vs Service Mesh
- K8S通过kube-proxy组件进行流量转发
- Istio Service Mesh 可以沿用 Kubernetes 中的 service 做服务注册，还可以通过控制平面的平台适配器对接其他服务发现系统
Service Mesh的劣势：为了细粒度地进行流量管理，必将添加一系列新的抽象，从而会进一步增加用户的学习成本
Service Mesh的优势：kube-proxy 的设置都是全局生效的，无法对每个服务做细粒度的控制， Service Mesh 通过 sidecar proxy 的方式将 Kubernetes 中对流量的控制从 service 一层抽离出来，可以做更多的扩展
xDS 协议
Envoy
Envoy 是 Istio Service Mesh 中默认的 Sidecar
Istio Service Mesh
Istio
它是一个完全开源的服务网格，以透明的方式构建在现有的分布式应用中。它也是一个平台，拥有可以集成任何日志、遥测和策略系统的 API 接口。Istio 多样化的特性使你能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。
负载均衡
故障注入
数据包重放
