SOFAMosn是基于Go开发的sidecar,用于service mesh中的数据面代理。官方文档见 SOFAMosn ,基本架构如下:
一个简单的结合sofa-rpc的例子可参考 SOFAMosn代理SOFARPC 。
观察到启动mosn形似./main start -c config.json
,那么我们可以先从分析配置入手,看看mosn作为数据代理的整个流转过程。
config.json的配置如下:
{ "servers": [ { "default_log_path": "stdout", "listeners": [ { "name": "serverListener", "address": "127.0.0.1:2046", "bind_port": true, "log_path": "stdout", "filter_chains": [ { "tls_context": {}, "filters": [ { "type": "proxy", "config": { "downstream_protocol": "Http2", "upstream_protocol": "SofaRpc", "router_config_name": "server_router" } }, { "type": "connection_manager", "config": { "router_config_name": "server_router", "virtual_hosts": [ { "name": "serverHost", "domains": [ "*" ], "routers": [ { "match": { "headers": [ { "name": "service", "value": ".*" } ] }, "route": { "cluster_name": "serverCluster" } } ] } ] } } ] } ] }, { "name": "clientListener", "address": "127.0.0.1:2045", "bind_port": true, "log_path": "stdout", "filter_chains": [ { "tls_context": {}, "filters": [ { "type": "proxy", "config": { "downstream_protocol": "SofaRpc", "upstream_protocol": "Http2", "router_config_name": "client_router" } }, { "type": "connection_manager", "config": { "router_config_name": "client_router", "virtual_hosts": [ { "name": "clientHost", "domains": [ "*" ], "routers": [ { "match": { "headers": [ { "name": "service", "value": ".*" } ] }, "route": { "cluster_name": "clientCluster" } } ] } ] } } ] } ] } ] } ], "cluster_manager": { "clusters": [ { "Name": "serverCluster", "type": "SIMPLE", "lb_type": "LB_RANDOM", "max_request_per_conn": 1024, "conn_buffer_limit_bytes": 32768, "hosts": [ { "address": "127.0.0.1:8080" } ] }, { "Name": "clientCluster", "type": "SIMPLE", "lb_type": "LB_RANDOM", "max_request_per_conn": 1024, "conn_buffer_limit_bytes": 32768, "hosts": [ { "address": "127.0.0.1:2046" } ] } ] } }
这里的配置非常多,并且有很多的概念及术语。其实mosn概念大多继承于Envoy,所以相关概念可以参考 Envoy的官方文档 。
我们就config.json中出现的概念做一些解释。
Host/主机:能够进行网络通信的实体(如移动设备、服务器上的应用程序)。
Downstream/下游:下游主机连接到 Mosn,发送请求并接收响应。
Upstream/上游:上游主机接收来自 Mosn 的连接和请求,并返回响应。
Listener/监听器:监听器是命名网地址(例如,端口、unix domain socket等),可以被下游客户端连接。Mosn 暴露一个或者多个监听器给下游主机连接。
Cluster/集群:集群是指 Mosn 连接到的逻辑上相同的一组上游主机。Mosn 通过服务发现来发现集群的成员。Mosn 通过负载均衡策略决定将请求路由到哪个集群成员。
Mosn中的配置包括两大类: listener(servers)配置和cluster(cluster_manager)配置。
Mosn的每一个server都可配置多个listener以实现复杂的代理逻辑。listener往往包含一组filter依次对数据流进行处理。
我们看到例子中,由sofa-rpc的client端发起了请求,请求的是127.0.0.1:2045。而我们可以发现config.json中配置的clientListener刚好监听的地址是127.0.0.1:2045。它主要包含了以下一些配置
mosn的过滤器有很多种类,按照配置的顺序依次处理数据,在这个例子中,配置了两个过滤器,proxy和connectionManager。
proxy主要是指定了上下游的协议,便于进行协议转换:
connectionManager则主要用于配置匹配规则,路由规则等,即virtual_hosts配置。而 virtual_hosts 配置中必须包含以下几项配置:
每个路由中还可以包含以下配置:
在当前例子中,即为URL为*的请求,并且headers中包含key为service的header,均交于名为clientCluster的cluster处理。
在clientListener配置的最后,讲道将请求交于clientCluster处理。那么我们接下来看cluster的相关配置。cluster的配置中主要包含了服务发现和负载均衡方式配置。
我们在config.json中找到clientCluster的配置,发现其主要包含以下几项:
在当前例子中,负载均衡方式为随机,并且主机列表仅仅只有一台,那么意味着请求将转发到127.0.0.1:2046。
当前我们的流转过程是从clientListener到clientCluster,而这两者其实都包含在了client端的mosn中。clientCluster将请求转发到了127.0.0.1:2046,先由serverListener监听到请求,再交由serverCluster处理,这两者属于server端的mosn,处理逻辑与之前描述的client端的mosn一致,在此不做展开。最后,serverCluster将请求通过服务发现与负载均衡后,转发到了真正的服务端sofa-rpc,即127.0.0.1:8080。
也许有人会有疑问,原先client的请求是直接发给server端的,现在怎么会发给mosn,被clientListener监听到,从而完成整个转发过程呢,难道需要client端知道client mosn的地址?再改写目的地址?
这就涉及到流量劫持了,一个通用的解决方案是iptables,可参考 理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持 。除此之外还有IPVS、Cilium + eBPF等方案,在此就不展开了。
由以上配置分析后,我们可以得到整个mosn的流转过程如下:
至此SOFAMosn就完成了数据面SideCar转发流量的工作。