EdgeMesh主要用來做邊緣側微服務的互訪。
ServiceMesh
service mesh是一個服務網格的概念。在傳統的架構里面都是通過像Dubbo來進行服務治理，服務治理的程序和我們應用程序強耦合在一起，對程序升級和運維帶來很多麻煩。service mesh通過sidecar來使我們的治理能力獨立，上圖中綠色和藍色是一個業務單元，綠色是我們的應用，藍色是專門負責服務治理的程序，比如在Istio中就是envoy。應用的流量出來先導入envoy里面，在envoy里面可以配置服務訪問的策略，就可以訪問到對應的服務。
帶來的好處就是應用程序無感知。
EdgeMesh
EdgeMesh架構
EdgeMesh在EdgeCore里面也是一個獨立的Moudul，負責邊緣側流量的轉發，已經把CNI的東西做好了，支持跨節點流量轉發。APP的流量出來一個會導入到EdgeMesh里面，EdgeMesh里面有Listener負責監聽；Resolver負責域名解析,它里面實現了一個DNS server；Dispatcher負責轉發流量。RuleMgr作用是把endpoint、service、pod的信息通過MetaManager從數據庫里取出來。
為什么域名解析會放到邊緣？我們知道在原生k8s里面，域名解析是放在coreDNS活kubeDNS里面的做的，一般部署在master或一個單點生。這樣會有一個問題：邊緣和雲的鏈接會經常斷開，在這種情況下，域名解析服務就不能用了，因此需要把域名解析放到邊緣，而不應該在master里面去解析，這時就需要把雲上的service、endpoint、pod信息都同步到邊緣。（后續會做一個優化，不獲取全量信息，只把有效信息同步過來）
目前的設計主要致力於邊和邊的服務互訪，雲和邊還有點問題，如果雲和邊要傳一個數據還是推薦使用其他的數據通道。未來會做的工作是使用標准的istio進行服務治理控制，現在支持的是雲上k8s的api，以后會考慮把istio集成進來，基於istio那一套規則來做。
目前邊邊的節點是在同一子網，本身就是互通的，未來考慮跨子網通信，可以通過cloudhub或者某一個中心點去轉。（我們思路是通過在邊緣動態配置一個envoy來統一接收需要代理的邊緣節點服務的入口和出口流量，相當於把envoy配置成網關形式）
EdgeMesh原理
- edgemesh通過kubeedge邊緣側list-watch的能力，監聽service、endpoints等元數據的增刪改，再根據service、endpoints的信息創建iptables規則
- edgemesh使用域名的方式來訪問服務，因為fakeIP不會暴露給用戶。fakeIP可以理解為clusterIP，每個節點的fakeIp的CIDR都是9.251.0.0/16網段(service網絡)
- 當client訪問服務的請求到達節點后首先會進入內核的iptables
- edgemesh之前配置的iptables規則會將請求重定向，全部轉發到edgemesh進程的40001端口里（數據包從內核台->用戶態）
- 請求進入edgemesh程序后，由edgemesh程序完成后端pod的選擇（負載均衡在這里發生），然后將請求發到這個pod所在的主機上
EdgeMesh轉發流程
client pod是請求方，service pod是服務方。client pod里面有一個init container，類似於istio的init container。client先把流量打入到init container，init container這邊會做一個流量劫持，它會把流量轉到edge mesh里面去，edge mesh根據需要進行域名解析后轉到對應節點的pod里面去。
這里有一個優化的點是：init container現在在每一個client pod里面都有一個，而它的功能作用在每一個pod里面都是一樣的，后續會考慮把init container接耦出來。
EdgeMesh配置方式
當我們配置一個init container的時候，它就會攔截應用的請求數據，轉發到EdgeMesh里面。
EdgeMesh用戶價值
對於資源受限的邊緣設備，提供了一個輕量化且具有高度集成的服務發現軟件；
在現場邊緣的場景下，相對於coredns+kube-proxy+cni這一套服務發現機制，我們只需要簡單的部署一個edgemesh就能完成目標