1、微服务治理层分析

目前实现微服务治理主要有两种方式，第一种以SDK的方式侵入业务代码中，第二种以进程外方式(sidercar)代理。其中第一种方式已有很多成熟方案，如Dubbo；而第二种即为当前火爆的Service Mesh，如Istio。本文主要针对第二种方式中的envoy谈谈个人理解。

若要自己实现微服务治理层(代理)，该如何设计呢？

首先，需要找准最核心、最基础的功能，其他的功能均是在其基础上扩展而来。故首先需要解决服务间通信功能，或者说是服务与代理以及代理与代理间的通信。那么代理该如何拦截被代理人接受的请求与发出的请求呢？---通过iptable，然后在代理应用程序中对相关请求进行处理。

其次，服务间通信时，必须知道对方IP和Port，一种方式是直接在本地配死，显而易见，该类方式能满足基本要求，但是却很不方便。目前比较成熟的方案即为从服务注册中心获取，即以某一标识为参数，调用第三方接口，获取IP和Port。此处即考验服务注册与发现的设计，一是每次都调用第三方接口，获取当前有效IP和Port；另外一种方式即在本地缓存第三方的配置，然后当变更时，实时同步，如目前比较成熟的组件ZooKeeper。

最后，在解决了核心的服务间通信以及服务注册与发现后，如负载均衡、熔断等功能，实现会简单很多。

2、envoy流程

3、参考文献

1、Istio 中的 Sidecar 注入及透明流量劫持过程详解