SOFA-MOSN源码解析—配置详解

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配置详解

Mosn中的配置包括两大类: listener(servers)配置和cluster(cluster_manager)配置。

Listener配置

Mosn的每个server均可配置多个listener以实现复杂的代理逻辑。listener每每包含一组filter依次对数据流进行处理。

咱们看到例子中，由sofa-rpc的client端发起了请求，请求的是127.0.0.1:2045。而咱们能够发现config.json中配置的clientListener恰好监听的地址是127.0.0.1:2045。它主要包含了如下一些配置

• name: 监听器名称
• address: 监听的地址
• filter_chains：一些列过滤器链 mosn的过滤器有不少种类，按照配置的顺序依次处理数据，在这个例子中，配置了两个过滤器，proxy和connectionManager。

proxy主要是指定了上下游的协议，便于进行协议转换:

• downstream_protocol: 下游协议，当前例子采用了sofa-rpc
• upstream_protocol：上游协议，当前例子采用了http2 connectionManager则主要用于配置匹配规则，路由规则等，即virtual_hosts配置。而 virtual_hosts 配置中必须包含如下几项配置：
• name：服务名称
• domains：DNS 域名，必须能跟 virtual_host 的 URL 匹配
• routes：路由列表 每一个路由中还能够包含如下配置：
• match：匹配规则，例如header中须要包含特定的key等
• cluster：路由处处理该请求的 mosn cluster 在当前例子中，即为URL为*的请求，而且headers中包含key为service的header，均交于名为clientCluster的cluster处理。

Cluster配置

在clientListener配置的最后，讲道将请求交于clientCluster处理。那么咱们接下来看cluster的相关配置。cluster的配置中主要包含了服务发现和负载均衡方式配置。

咱们在config.json中找到clientCluster的配置，发现其主要包含如下几项:

• name: cluster名称
• lb_type: 负载均衡方式
• hosts: 在当前例子中，SIMPLE模式的cluster，直接配置了服务发现的主机列表

在当前例子中，负载均衡方式为随机，而且主机列表仅仅只有一台，那么意味着请求将转发到127.0.0.1:2046。

服务端mosn配置

当前咱们的流转过程是从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代理流量的流转过程

由以上配置分析后，咱们能够获得整个mosn的流转过程以下：

至此SOFAMosn就完成了数据面SideCar转发流量的工做。