服务网格架构设计与实践

老李说架构之道 2021-06-22

1610

发展历程

最早开发linkerd的Buoyant公司提出，并在内部使用；

2016年09月29日第一次公开使用

2017年初，service mesh进入国内技术社区视野

服务网格是一个基础设施层，用于处理服务间通信，云原生应用有着复杂的服务拓扑，服务网格复杂在这些拓扑中实现请求的可靠传递，在实践中，服务网格通常实现在为一组轻量级网络代理，它们与应用程序部署在一起，而对应用程序透明。

解决了什么问题？

业务团队和基础设施团队完全解耦，避免系统升级带来的耦合度问题；

业务团队只关注于业务开发逻辑本身；

一套基础设施语言支持多语言，而避免多套治理平台开发；

service mech 独立部署，对立升级；

Service Mesh架构？

Service Mesh Open Source Framework

解耦之道：让基础架构下沉，独立进程运行，由原来单进程变转双进程运行。思考：涉及到进程协作模型交互问题，下面会时序图形式讲解到。

如何选型？

开源成熟度，遇到问题能否快速搞定

已有RPC，直接使用开源方案，业务侧升级成本高

自研 RPC---->Mesh

现状：已有RPC，直接用开源方案，业务侧升级成本太高。目前很多公司都是RPC转Mesh的过程，针对大部分场景，自研总体架构思路如下：

Mesh实践：

总体架构思路：

运行在容器云原生，Docker+K8S

Stateless Service(无状态服务)/Stateful Service(有状态服务)支持

数据平面和控制平面 SideCar+控制中心

兼容所有的RPC所有用法，降低业务升级成本

顶层架构设计：

SideCar 数据面板

Service Manager 服务管理平台

Control Center 控制中心

Collector 数据收集中心

总体交互流程：

总体交互---调用链路：

调用方时序图：

服务方时序图：

协议设计：

数据协议：protocol buffer

通讯协议：

Tcp/IP HTTP2.0

Service mesh 架构全貌：

‍

文章转载自老李说架构之道，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。