最蛋疼的注册中心与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了。没有必要再增加一层代理，不但增加部署成本，同时还会降低的性能。完全是赔了夫人又折兵的做法，非常不可取！
除非有一种情况，如果你的业务集群很大，对前端暴露用一套网关，同时后端服务有几千几万，由很多个不同的团队在维护，那么在团队的边界处设立内部的网关，那还是合理的。同时这种情况下，对于注册中心，按团队做隔离也是有必要的。因为这样可以分而治之，更好的做好接口的访问控制与管理。但是，如果你本身服务不多，团队也不大，那就别折腾这么复杂的架构了，越复杂稳定性就越难保障，这点一定要平衡好。
北京云中融信网络科技有限公司（简称融云），是安全、可靠的全球互联网通信云服务商，向开发者和企业提供即时通讯和实时音视频通信云服务。iResearch 艾瑞权威数据报告显示，融云即时通讯云市场份额连续多年稳居头位。
融云构建了一张覆盖全球所有国家及地区（共 233 个）的通信云网络，在全球各地设立多个数据中心及数千个加速节点。基于客户业务需求，融云可提供多种部署模式——公有云、私有云、混合云，为全球企业提供稳定的互联网通信云服务。针对企业级用户，融云将业务垂直到各个行业，为社交、直播、金融、交通运输、教育、电商、医疗等多个行业领域推出了针对性解决方案。
融云基于海量业务的技术锤炼，从基础架构到精细化运营，充分体现平台实力；凭借卓越的产品和优质的服务，在开发者规模、行业覆盖率、平台日活跃用户数、日均消息量等方面超越全行业。目前，已有数十万互联网用户及上千家企业级用户通过融云实现了场景化沟通，并从中获益，包括工商银行、中国移动、四川航空、CCTV 微视、中联重科、58 赶集、大河报业、新东方、陆金所、融创地产、IDG、华兴资本、易车网、猪八戒、得到 APP、荔枝、汽车之家、哈啰出行、百姓网、StarMaker、Opera、Elelive。