EdgeMesh主要用来做边缘侧微服务的互访。
service mesh是一个服务网格的概念。在传统的架构里面都是通过像Dubbo来进行服务治理，服务治理的程序和我们应用程序强耦合在一起，对程序升级和运维带来很多麻烦。service mesh通过sidecar来使我们的治理能力独立，上图中绿色和蓝色是一个业务单元，绿色是我们的应用，蓝色是专门负责服务治理的程序，比如在Istio中就是envoy。应用的流量出来先导入envoy里面，在envoy里面可以配置服务访问的策略，就可以访问到对应的服务。
带来的好处就是应用程序无感知。
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配置成网关形式）
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接耦出来。
当我们配置一个init container的时候，它就会拦截应用的请求数据，转发到EdgeMesh里面。
