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轉發流程
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裡面。