注册中心与API网关不是这样用的！
之前在做顾问和咨询项目的时候，见到了一种非常经典的关于API网关和注册中心的错误用法。这个案例在我的星球里已经分享过，没想到最近又碰到了两个类似的使用姿势。也许这样的问题还存在不少团队的应用中，所以拿出来再分享一下，希望可以帮助读者更好的理解注册中心与API网关的作用，并将它们用对地方！
在微服务架构中，我们都会使用API网关来作为暴露服务的唯一出口。这样可以将与业务无关的各项控制，集中的在API网关中进行统一管理，从而使得业务服务可以更加专注于业务领域本身。
而在微服务构建的系统内部，各个服务之间的调度，我们通常采用注册中心和客户端负载均衡的方式来实现服务之间的调用。
所以，大致的结构是这样子的：
在这样的架构实践中，注册中心和API网关的功能，主要有以下两点：
- API网关通过注册中心发现所有后端服务，从来实现动态代理
- 后端服务集群间，通过注册中心互相发现对方，而实现直接调用（通常使用Ribbon、Feign这些框架）
下面就来具体说说今天的主角（错误案例），先上图：
注意图中的两个地方：
- 存在两套网关，一套对内访问、一套对外访问
- 对内访问的网关实际就是起到了一个代理作用，较之前的图对比以下，就知道，这个方案中并没有利用到服务治理机制去直接让服务A调用服务B，而是通过网关去做了一次代理。
更震惊的是，在我看到代码的时候，他们居然也是用feign来编写服务间调用的，但在配置请求路径的时候，是使用在内部API网关上配置的二级域名来实现（比如：http://service-name.didispace.com/api-path，这里service-name对应不同的服务名），而熟悉Spring Cloud的读者都知道，其实service-name.didispace.com这部分直接用服务名替代就可以了...是不是瞬间有种脱裤子放x的感觉？
如果这样来使用的话，其实引入注册中心的用处就很小了，实际上只有给两个网关提供了集中的后端服务发现功能。如果要实现这种功能，其实注册中心都可以不需要，每个服务都直接上报地址给网关就好了，架构会更加简单。
同时，在这样的实现方式之下，内部调用都要经过内部网关多一跳的调度过程，除了要多出内部网关的部署资源之外，每一次内部调用的时间开销实际上都大了。所以这样的用法是非常不推荐的！
对于API网关的定位，还是以作为对外出口的管理为最佳，内部的代理调用，均交给服务注册与发现机制 + 客户端负载均衡就ok了。没有必要再增加一层代理，不但增加部署成本，同时还会降低的性能。完全是赔了夫人又折兵的做法，非常不可取！
除非有一种情况，如果你的业务集群很大，对前端暴露用一套网关，同时后端服务有几千几万，由很多个不同的团队在维护，那么在团队的边界处设立内部的网关，那还是合理的。同时这种情况下，对于注册中心，按团队做隔离也是有必要的。因为这样可以分而治之，更好的做好接口的访问控制与管理。但是，如果你本身服务不多，团队也不大，那就别折腾这么复杂的架构了，越复杂稳定性就越难保障，这点一定要平衡好。
最后，大家结合自己团队的注册中心与API网关应用是否有犯一样的问题呢？或者如果有其他问题与疑问，不妨留言交流一下？也可以加入我们的技术交流群一起探讨技术问题！
