微服务架构痛点
业务关注服务之间通信
会导致业务迭代速度变慢
微服务架构1.0
网关层1个、业务逻辑层多个、数据访问层多个、DB/Cache多个，注册中心、配置中心
微服务2.0架构-服务网格
基础设施升级困难
影响基础设施团队的交付能力和交付速度
因为应用程序通过jar包方式引入通信组件
通信组件升级需要应用程序配合jar包版本升级
多编程语言之间'通信'问题
业务每种语言一套基础设施 成本大
微服务架构演进
服务网格定义
服务网格架构
带来的问题-链路会变长
性能里面的RT 平均响应延迟会变高
但本机之间即应用程序放到本机的sidecar损耗不会超过1毫秒
开源框架
最早版本linkerd
应用程序和sidecar之间通讯用tcp或http1.1以上都可以；两者需要保持长连接
istio
- Pilot
控制中心
1、控制proxy之间通讯
2、负载均衡
- Mixer
数据收集服务：
proxy之间通讯完之后 要上报一些mertics信息 （耗时、请求次数）
全部同步上报
集中式 不靠谱
它的性能影响proxy本身的性能
- Citadel
做鉴权安全相关的
proxy之间权限鉴权比如TLS、SSL
sofa mesh
蚂蚁金服开源
架构
1、将istio中的proxy重写
isotio proxy是用c++写的
sofa用go重写
2、istio数据收集节点是集中式的 sofa是分布式的即每个proxy中都有一个mixer
3、目前还没有公司大规模在用 社区不活跃 建议使用istio
新浪weibo mesh
服务网格做什么
如何选型
1、业务升级代价太高 要让业务的升级成本降低到0 要兼容所有rpc用法 所以自研
2、期望的是业务方只需要将rpc jar包换成这个rpc mesh jar包就行了
自研思路
1、要兼容传统(物理机、虚拟机)和云
2、控制中心包括服务管理平台和数据收集中心
架构设计
1、数据收集中心：
a、Metric:收集耗时、响应情况
b、Trace:分布式请求跟踪系统APM
c、Alarm：报警功能
2、Protocol
a、RPC:兼容老的RPC协议
b、mesh包括通讯协议(http1.1和2.0)和数据协议(protobuff)
（注：http1.0不支持 因为是短连接;http1.1和http2.0支持keep alive长连接;tpc是长连接;连接还在 server短可以直接推送消息给client）
2、sidecar之间的健康检查没有通过注册中心而是本身
总体流程
用户发起一个熔断服务B的指令
1、服务管理平台、控制中心、数据收集中心都是现成的服务（之前文章介绍过）那么自研Service Mesh只需要实现proxy就可以了
2、之前Service和Proxy是一个进程
现在需要修改成2个独立的进程即可
3、将二者放到同一个pod中
如果sidecar挂了对整体是否有影响?
没有影响。
sidecar挂掉 pod如何处理？
如果sidecar挂掉了 就会被监控到 直接把当前pod杀死就行了 k8s会自动重启一个pod
2个应用程序放在同一个物理机上架构怎样？
漂移
1、日志漂移
服务器1上有服务1生成日志1
如果服务器1上面的服务1挂了
在服务器2上启动服务2生成日志2
如果日志1和日志2有强依赖关系
那么必须得在服务器1上启动服务1继续在日志1的基础上生成日志
2、重试漂移
pod如果挂了 再次重启 那么ip就会改变
重试漂移到云上任何节点都没有关系
完整流程图
这个完整的流程图涵盖了
DNS、CDN、Nginx、FastDFS（或Ceph）、
LVS、ServiceMash、数据收集中心、
注册中心、控制中心、网关、业务逻辑层、
数据访问层、存储层等数据交互过程
价值不菲 想要的话
可以添加我微信15900411193
调用链路
1、做协议解析的目的是兼容老的协议
客户端发出请求后 在客户端service和服务方service要做协议解析
如果都是mesh协议 是不需要协议解析的、协议封装也不需要
2、客户端一定要做序列化、反序列化 这和通讯没啥关系 就是一个数据包
调用方时序图
服务方时序图
缓存管理 多个Map:
服务方提供哪些函数调用 通过扫描jar包 反射机制 获取服务提供的类名和方法名
协议设计
数据协议
1、Protocol Buffer
2、分割符、版本号、Mesh消息构成
1、一次传输协议中有版本号
比如 版本号1表示rpc协议
版本号2表示mesh协议
通过版本号可以区分兼容老协议还是新协议
2、多个数据包之间通过头和尾分割符分开
3、分割符占5个字节
Mesh通讯协议
1、TCP长连接
2、Http1.1或2.0
混合云部署
1、调用方
a、SideCar+Service(Mesh)
b、Service(RPC)
2、服务方
a、SideCar+Service(Mesh)
b、Service(RPC)
访问流程
1、在服务启动的时候 mesh服务或普通的RPC服务都会去注册中心注册 此时就知道了该节点的服务类型
2、调用方下拉服务信息 也就知道了提供方服务类型 然后选择不同的协议去调用
小细节
1、熔断放在mesh里面做 不需要业务方参与
2、下游重试次数是一样的 是服务粒度 非接口粒度
3、proxy(mesh)之间做健康检测 是分布式的 一旦发现自己的上游或下游出现了问题 就更新本地的路由表
4、负载均衡算法:Random、RR、Hash(主要用一致性hash来做)
（RR：(循环负载)
第一次请求路由到第一个节点，
第二次请求路由到第二个节点，
第三次请求路由到第三个节点，
第四次请求路由到第一个节点
....）
架构未来
2平台1中心1趋势
service mesh平台与业务解耦
容器云弹性平台
服务治理平台(控制中心、注册中心、数据收集中心)
人工智能(AI)
服务管理平台的调用关系-数据收集存储方法
服务方-调用方角度
服务方:1分钟500万条记录
调用方:50万
共550万
存储方案
方案1
方案二
重复数据提取出来作为元数据
方案三
实际调用流量仅为方案1的1/10
、
