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轉發流量的工作。