注册中心与API网关不是这样用的！

以前在作顾问和咨询项目的时候，见到了一种很是经典的关于API网关和注册中心的错误用法。这个案例在个人星球里已经分享过，没想到最近又碰到了两个相似的使用姿式。也许这样的问题还存在很多团队的应用中，因此拿出来再分享一下，但愿能够帮助读者更好的理解注册中心与API网关的做用，并将它们用对地方！

在微服务架构中，咱们都会使用API网关来做为暴露服务的惟一出口。这样能够将与业务无关的各项控制，集中的在API网关中进行统一管理，从而使得业务服务能够更加专一于业务领域自己。

而在微服务构建的系统内部，各个服务之间的调度，咱们一般采用注册中心和客户端负载均衡的方式来实现服务之间的调用。

因此，大体的结构是这样子的：

在这样的架构实践中，注册中心和API网关的功能，主要有如下两点：

1. API网关经过注册中心发现全部后端服务，历来实现动态代理
2. 后端服务集群间，经过注册中心互相发现对方，而实现直接调用（一般使用Ribbon、Feign这些框架）

下面就来具体说说今天的主角（错误案例），先上图：

注意图中的两个地方：

1. 存在两套网关，一套对内访问、一套对外访问
2. 对内访问的网关实际就是起到了一个代理做用，较以前的图对比如下，就知道，这个方案中并无利用到服务治理机制去直接让服务A调用服务B，而是经过网关去作了一次代理。

更震惊的是，在我看到代码的时候，他们竟然也是用feign来编写服务间调用的，但在配置请求路径的时候，是使用在内部API网关上配置的二级域名来实现（好比：http://service-name.didispace.com/api-path，这里service-name对应不一样的服务名），而熟悉Spring Cloud的读者都知道，其实service-name.didispace.com这部分直接用服务名替代就能够了...是否是瞬间有种脱裤子放x的感受？

若是这样来使用的话，其实引入注册中心的用处就很小了，实际上只有给两个网关提供了集中的后端服务发现功能。若是要实现这种功能，其实注册中心均可以不须要，每一个服务都直接上报地址给网关就行了，架构会更加简单。

同时，在这样的实现方式之下，内部调用都要通过内部网关多一跳的调度过程，除了要多出内部网关的部署资源以外，每一次内部调用的时间开销实际上都大了。因此这样的用法是很是不推荐的！

对于API网关的定位，仍是以做为对外出口的管理为最佳，内部的代理调用，均交给服务注册与发现机制 + 客户端负载均衡就ok了。没有必要再增长一层代理，不但增长部署成本，同时还会下降的性能。彻底是赔了夫人又折兵的作法，很是不可取！

除非有一种状况，若是你的业务集群很大，对前端暴露用一套网关，同时后端服务有几千几万，由不少个不一样的团队在维护，那么在团队的边界处设立内部的网关，那仍是合理的。同时这种状况下，对于注册中心，按团队作隔离也是有必要的。由于这样能够分而治之，更好的作好接口的访问控制与管理。可是，若是你自己服务很少，团队也不大，那就别折腾这么复杂的架构了，越复杂稳定性就越难保障，这点必定要平衡好。

最后，你们结合本身团队的注册中心与API网关应用是否有犯同样的问题呢？或者若是有其余问题与疑问，不妨留言交流一下？也能够加入咱们的技术交流群一块儿探讨技术问题！

拓展阅读

• 不三不四的微服务改造：分布式单体
• SpringCloud专题资料
• 微服务专题资料

欢迎关注个人公众号：程序猿DD，得到独家整理的免费学习资源助力你的Java学习之路！另每周赠书不停哦～