vlambda博客
学习文章列表

之前在做顾问和咨询项目的时候，见到了一种非常经典的关于API网关和注册中心的错误用法。其实在我的星球（https://t.zsxq.com/eA2bMBA）里已经分享过这个案例，没想到最近又碰到了两个类似的使用姿势。。。也许这样的问题还存在不少团队的应用中，所以再拿出来分享一下，希望可以帮助读者更好的理解注册中心与API网关的作用，并将它们用对地方！

在微服务架构中，我们都会使用API网关来作为暴露服务的唯一出口。这样可以将与业务无关的各项控制，集中的在API网关中进行统一管理，从而使得业务服务可以更加专注于业务领域本身。

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

所以，大致的结构是这样子的：

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

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

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

注意图中的两个地方：

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

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

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

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

拓展阅读

• SpringCloud专题资料：https://blog.didispace.com/spring-cloud-learning/
• 微服务专题资料：https://blog.didispace.com/micro-serivces-arch/

点击下方卡片关注我

分享其他地方看不到的技术思考与干货！