0
点赞
收藏
分享

微信扫一扫

下一代微服务Service Mesh原理及实践

微服务架构痛点

业务关注服务之间通信

会导致业务迭代速度变慢

​微服务架构1.0​

下一代微服务Service Mesh原理及实践_数据收集

网关层1个、业务逻辑层多个、数据访问层多个、DB/Cache多个,注册中心、配置中心

​微服务2.0架构-服务网格​

下一代微服务Service Mesh原理及实践_jar包_02

基础设施升级困难

影响基础设施团队的交付能力和交付速度
因为应用程序通过jar包方式引入通信组件
通信组件升级需要应用程序配合jar包版本升级

下一代微服务Service Mesh原理及实践_ide_03

多编程语言之间'通信'问题

业务每种语言一套基础设施 成本大

下一代微服务Service Mesh原理及实践_jar包_04

微服务架构演进

下一代微服务Service Mesh原理及实践_jar包_05

服务网格定义

下一代微服务Service Mesh原理及实践_jar包_06

服务网格架构

下一代微服务Service Mesh原理及实践_ide_07

​带来的问题-链路会变长​

性能里面的RT 平均响应延迟会变高
但本机之间即应用程序放到本机的sidecar损耗不会超过1毫秒

开源框架

最早版本linkerd

下一代微服务Service Mesh原理及实践_jar包_08

应用程序和sidecar之间通讯用tcp或http1.1以上都可以;两者需要保持长连接

istio

下一代微服务Service Mesh原理及实践_数据收集_09

  • Pilot

控制中心
1、控制proxy之间通讯
2、负载均衡

  • Mixer

数据收集服务:

proxy之间通讯完之后 要上报一些mertics信息 (耗时、请求次数)
全部同步上报
集中式 不靠谱
它的性能影响proxy本身的性能

  • Citadel

做鉴权安全相关的
proxy之间权限鉴权比如TLS、SSL

sofa mesh

蚂蚁金服开源

​架构​

下一代微服务Service Mesh原理及实践_数据收集_10

1、将istio中的proxy重写
isotio proxy是用c++写的
sofa用go重写
2、istio数据收集节点是集中式的 sofa是分布式的即每个proxy中都有一个mixer
3、目前还没有公司大规模在用 社区不活跃 建议使用istio

新浪weibo mesh

下一代微服务Service Mesh原理及实践_数据收集_11

服务网格做什么

下一代微服务Service Mesh原理及实践_jar包_12

如何选型

下一代微服务Service Mesh原理及实践_jar包_13

1、业务升级代价太高 要让业务的升级成本降低到0 要兼容所有rpc用法 所以自研
2、期望的是业务方只需要将rpc jar包换成这个rpc mesh jar包就行了

自研思路

下一代微服务Service Mesh原理及实践_数据收集_14

1、要兼容传统(物理机、虚拟机)和云
2、控制中心包括服务管理平台和数据收集中心

架构设计

下一代微服务Service Mesh原理及实践_数据收集_15

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之间的健康检查没有通过注册中心而是本身

总体流程

下一代微服务Service Mesh原理及实践_数据收集_16

​用户发起一个熔断服务B的指令​

下一代微服务Service Mesh原理及实践_ide_17

1、服务管理平台、控制中心、数据收集中心都是现成的服务(之前文章介绍过)那么自研Service Mesh只需要实现proxy就可以了
2、之前Service和Proxy是一个进程
现在需要修改成2个独立的进程即可
3、将二者放到同一个pod中

​如果sidecar挂了对整体是否有影响?​

没有影响。

下一代微服务Service Mesh原理及实践_jar包_18

​sidecar挂掉 pod如何处理?​

如果sidecar挂掉了 就会被监控到 直接把当前pod杀死就行了 k8s会自动重启一个pod

​2个应用程序放在同一个物理机上架构怎样?​

下一代微服务Service Mesh原理及实践_jar包_19

​漂移​

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

调用链路

下一代微服务Service Mesh原理及实践_jar包_20

1、做协议解析的目的是兼容老的协议
客户端发出请求后 在客户端service和服务方service要做协议解析
如果都是mesh协议 是不需要协议解析的、协议封装也不需要
2、客户端一定要做序列化、反序列化 这和通讯没啥关系 就是一个数据包

调用方时序图

下一代微服务Service Mesh原理及实践_ide_21

服务方时序图

下一代微服务Service Mesh原理及实践_数据收集_22

缓存管理 多个Map:
服务方提供哪些函数调用 通过扫描jar包 反射机制 获取服务提供的类名和方法名

协议设计

数据协议

1、Protocol Buffer
2、分割符、版本号、Mesh消息构成

下一代微服务Service Mesh原理及实践_数据收集_23

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)

​访问流程​

下一代微服务Service Mesh原理及实践_ide_24

1、在服务启动的时候 mesh服务或普通的RPC服务都会去注册中心注册 此时就知道了该节点的服务类型
2、调用方下拉服务信息 也就知道了提供方服务类型 然后选择不同的协议去调用

小细节

1、熔断放在mesh里面做 不需要业务方参与
2、下游重试次数是一样的 是服务粒度 非接口粒度
3、proxy(mesh)之间做健康检测 是分布式的 一旦发现自己的上游或下游出现了问题 就更新本地的路由表
4、负载均衡算法:Random、RR、Hash(主要用一致性hash来做)
(RR:(循环负载)
第一次请求路由到第一个节点,
第二次请求路由到第二个节点,
第三次请求路由到第三个节点,
第四次请求路由到第一个节点
....)

架构未来

2平台1中心1趋势

service mesh平台与业务解耦
容器云弹性平台
服务治理平台(控制中心、注册中心、数据收集中心)
人工智能(AI)


服务管理平台的调用关系-数据收集存储方法

服务方-调用方角度

下一代微服务Service Mesh原理及实践_数据收集_25

服务方:1分钟500万条记录
调用方:50万
共550万

存储方案

​方案1​

下一代微服务Service Mesh原理及实践_数据收集_26

​方案二​

​重复数据提取出来作为元数据​

下一代微服务Service Mesh原理及实践_jar包_27

​方案三​

实际调用流量仅为方案1的1/10

下一代微服务Service Mesh原理及实践_jar包_28



举报

相关推荐

0 条评论