简介
蚂蚁金服基于Istio&Envoy的一套ServiceMesh框架,首先看一下Istio&Envoy的架构
Istio
Envoy
- Listener->LDS
- Routes->RDS
- Clusters->CDS
- Endpoints->EDS
1 | 一是Listener:也即envoy既然是proxy,专门做转发,就得监听一个端口,接入请求 |
配合上这份配置的话,Envoy大致处理流程如下图
清晰架构图
Envoy的另一特点是支持配置信息的热更新,其功能由XDS模块完成,XDS是个统称,具体包括ADS(Aggregated Discovery Service)、SDS(Service Discovery Service)、EDS(Endpoint Discovery Service)、CDS(Cluster Discovery Service)、RDS(Route Discovery Service)、LDS(Listener Discovery Service)。
XDS模块功能是向Istio的Pilot获取动态配置信息,拉取配置方式分为V1与V2版本,V1采用HTTP,V2采用gRPC。
Envoy还支持热重启,即重启时可以做到无缝衔接,其基本实现原理是:
- 将统计信息与锁放到共享内存中。
- 新老进程采用基本的RPC协议使用Unix Domain Socket通讯。
- 新进程启动并完成所有初始化工作后,向老进程请求监听套接字的副本。
- 新进程接管套接字后,通知老进程关闭套接字。
- 通知老进程终止自己。
Envoy同样也支持Lua编写的Filter,不过与Nginx一样,都是工作在HTTP层,具体实现原理都一样
内部结构图
SOFAMosn
简介
蚂蚁金服自创数据平面组件替代Envoy
,把Istio
的Mixer
沉淀到了SOFAMosn
的位置上,还会增加Dubbo
的接入支持
基本架构
0.1.0 版本的 SOFAMosn 支持了 xDS V0.4 api 核心能力,重点支持了 SOFARPC 协议,并在蚂蚁内部在生产环境使用;同时支持了HTTP/1.1,HTTP/2.0的基本功能,但目前暂未在生产环境使用。
SOFAMosn 作为代理处理的数据流划分为4层,在入方向数据依次经过网络 IO 层,二进制协议处理层,协议流程处理层,转发路由处理层;出向与入向过程基本相反。
了解了分层的基本思路,具体介绍一下各层的具体职能:
- IO 层提供了 IO 读写的封装以及可扩展的 IO 事件订阅机制
- PROTOCOL 层提供了根据不同协议对数据进行序列化/反序列化的处理能力
- STREAMING 层提供向上的协议一致性,负责 STREAM 生命周期,管理 Client / Server 模式的请求流行为,对 Client 端stream 提供池化机制等
- Proxy 层提供路由选择,负载均衡等的能力,让前后端 stream 流转起来。大家可以从这张图清晰的看到单向请求流转的过程。
线程模型
0.1.0 版本的线程模型,可以看到每个链接的 IO 协程是成对出现的,读协程负责读取,事件机制及 Codec 逻辑,数据上升到 steam 层,具体的 stream 事件由独立的常驻 worker 协程池负责处理。
在 0.2.0 版本中我们将会进行多核优化,读协程将不再负责 codec 逻辑,将转发由 codec worker pool 来进行。从发展方向上看,我们会借鉴 SEDA 的思路,将转发流程中每一阶段的处理抽象为一个 stage,通过 task queue,worker 协程池,controller 的机制来对每一个阶段进行处理。从技术实现上看,Golang 实现 SEDA 机制的组件也更简单。
国内查看评论需要代理~