对于传统的ESB总线我们看到实际上包括了微服务架构中的微服务注册和发现中心，微服务网关两个方面的能力，但为何在微服务架构里面会将这两个点分解为独立的两个子组件，我们通过以下分析了解一下。

首先还是要说下微服务网关，微服务网关更多是在前后端分离，或者说涉及到独立的类似手机APP等前端应用的时候使用的最多，即把内部各个微服务组件模块的API接口能力统一注册和接入到网关，对于APP也只需要访问网关暴露的接口即可，同时通过网关还可以进一步的实现安全隔离。也就是说在这种场景下，网关更多的是实现了接口服务的代理和路由转发能力，更多的是向外的一种能力发布。

我们可以想下在一个微服务架构里面，分解为了A，B，C，D四个微服务组件和模块，但是这四个模块都有各自的前端应用展现，四个模块之间本身也存在相互的接口调用，但是都在在数据中心内部调用。在这种情况下我们是否需要使用微服务网关？而实际上在这种架构下，完全可以不使用微服务网关，只需要使用服务注册和发现中心即可。

也就是我们常说的引入微服务网关后，微服务网关本身又变成为一个中心化的节点，虽然你可以对网关也进行集群部署，但是这种模式不符合我们去中心的期望。如果一个业务应用全部都是在内部使用，那么微服务模块之间的交互完全可以不接入到微服务网关进行管理。

但是微服务模块间相互调用的接口地址如何管理，微服务模块本身又集群化后如何进行负载均衡，包括微服务模块间相互点对点调用时日志如何监控和分析，服务链如何监控和管理？这些都是在去中心化后要考虑的问题，而这个在当下微服务架构下完全是可以解决的。其核心的思路就是将微服务网关的部分能力下沉到微服务模块中去完成，类似在微服务模块里面注册一个很小的SDK插件。

也就是我们常说的，微服务模块间的调用只需要服务注册和发现中心，模块A从服务注册中心获取到模块B的接口服务调用地址后，直接发起对模块B的接口服务调用。注册中心本身需要提供服务目录库和负载均衡的能力。而对于微服务模块内部SDK包仅仅是将本地SDK API调用转变为远程的Rest服务调用接口。同时在SDK代理包中可以很方便的实现日志拦截，安全管理，缓存等能力。在这种架构下，即使是服务注册中心宕机也不会影响到整个微服务架构的平稳运行。从而达到真正的去中心化的目标。

也就是说在微服务架构里面，不涉及到对外发布统一的服务接口的时候，只需要保留服务注册中心这个组件即可满足内部多个微服务模块的平稳运行。对于服务注册中心一般需要提供负载均衡的能力，比如我们可以在服务注册中心对提供同样一个服务接口的多个组件都注册进来，到时候通过服务注册中心进行动态的负载均衡。如果我们是和Docker容器和K8s结合的化，整个微服务组件都是动态部署和托管的，K8s本身就提供了负载均衡和路由分发的能力，在这种情况下实际上只需要对K8s最终发布出来的负载均衡地址进行注册即可。

但是这个外部本身又不绝对，如下图，当一个大的业务系统，分成了三组微服务模块，同时分给三个独立开发厂商开发时，那么三个开发团队间的接口交互仍然可以理解为外部，这样往往才能够确保每个开发团队的高度独立自治能力。

基于上图，再总结下在使用网关和注册中心的时候一些关键点：

1. 一个独立的开发团队，为保证独立自治，以及内部多个微服务模块间的交互集成，最好启用独立的服务注册中心实现服务注册，发现能力。即开发团队内部多个微服务模块间的集成，不需要通过网关，只需要通过服务注册中心进行集成即可。

2. 开发团队需要暴露能力给外部，包括暴露能力给其它的开发团队，需要考虑将该API接口注册到外部的网关上。在这里建议是拆分两个独立网关，一个是内部API网关，一个是放置到DMZ区面对公网访问的API网关。对于服务如果同时涉及到内部和外部使用，则两边注册。建议不要通过两次网关去路由，一个是影响性能，一个是不方便后续问题排查。

3. 构建在开发团队之外的API网关必须具备负载均衡能力，可以配置多个IP地址。通过该API网关也最好具备和Docker容器扩展后的服务自动注册和地址加入扩展能力。

4. 对于开发团队内部，如果考虑和Docker容器的进一步自动化集成，可以考虑在内部先启用微服务网关，再将微服务网关开发的API地址进一步注册到外部的API网关上面。

5. 如果内部和外部启用各自独立的网关，但是定制化SOA管控治理平台的时候只需要一个，同时适配两个网关，同时能够对两个网关进行监控和日常管理。