在前面谈微服务架构的时候，已经有多篇文章都谈到过微服务网关，由于微服务网关本身也是提供代理，路由，安全，日志，负载均衡，流量控制等能力，因此我谈的最多的就是可以将微服务网关理解为轻量的ESB服务总线，通过微服务网关来实现SOA特性中的位置透明，实现统一的接口服务目录发布，即从1对N变化到1对1。
对于传统的ESB总线我们看到实际上包括了微服务架构中的微服务注册和发现中心，微服务网关两个方面的能力，原来也一直没很好的理解为何在微服务架构里面会将这两个点分解为独立的两个子组件。今天经过思考，基本上进一步了解了这样做的原因。
首先还是要说下微服务网关，微服务网关更多是在前后端分离，或者说涉及到独立的类似手机APP等前端应用的时候使用的最多，即把内部各个微服务组件模块的API接口能力统一注册和接入到网关，对于APP也只需要访问网关暴露的接口即可，同时通过网关还可以进一步的实现安全隔离。也就是说在这种场景下，网关更多的是实现了接口服务的代理和路由转发能力，更多的是向外的一种能力发布。
我们可以想下在一个微服务架构里面，分解为了A，B，C，D四个微服务组件和模块，但是这四个模块都有各自的前端应用展现，四个模块之间本身也存在相互的接口调用，但是都在在数据中心内部调用。在这种情况下我们是否需要使用微服务网关？而实际上在这种架构下，完全可以不使用微服务网关，只需要使用服务注册和发现中心即可。
也就是我们常说的引入微服务网关后，微服务网关本身又变成为一个中心化的节点，虽然你可以对网关也进行集群部署，但是这种模式不符合我们去中心的期望。如果一个业务应用全部都是在内部试用，那么微服务模块之间的交互完全可以不接入到微服务网关进行管理。
但是微服务模块间相互调用的接口地址如何管理，微服务模块本身又集群化后如何进行负载均衡，包括微服务模块间相互点对点调用时候日志如何监控和分析，服务链如何监控和管理？这些都是在取中心化后要考虑的问题，而这个在当下微服务架构下完全是可以解决的。其核心的思路就是将微服务网关的部分能力下沉到微服务模块中去完成，类似在微服务模块里面注册一个很小的SDK插件。
也就是我们常说的，微服务模块间的调用只需要契约服务注册和发现中心，模块A从服务注册中心获取到模块B的接口服务调用地址后，直接发起对模块B的接口服务调用。注册中心本身需要提供服务目录库和负载均衡的能力。而对于微服务模块内部SDK包仅仅是将本地SDK API调用转变为远程的Rest服务调用接口。同时在SDK代理包中可以很方便的实现日志拦截，安全管理，缓存等能力。在这种架构下，即使是服务注册中心宕机也不会影响到整个微服务架构的平稳运行。从而达到真正的去中心化的目标。
也就是说在微服务架构里面，不涉及到对外发布统一的服务接口的时候，只需要保留服务注册中心这个组件即可满足内部多个微服务模块的平稳运行。
对于服务注册中心一般需要提供负载均衡的能力，比如我们可以在服务注册中心对提供同样一个服务接口的多个组件都注册进来，到时候通过服务注册中心进行动态的负载均衡。如果我们是和Docker容器和K8s结合的化，整个微服务组件都是动态部署和托管的，K8s本身就提供了负载均衡和路由分发的能力，在这种情况下实际上只需要对K8s最终发布出来的负载均衡地址进行注册即可。
这篇文章还存在一些具体思考的点，需要进一步在我们的微服务架构支持平台中落地验证。
