之前在做顾问和咨询项目的时候,见到了一种非常经典的关于API网关和注册中心的错误用法。这个案例在我的星球里已经分享过,没想到最近又碰到了两个类似的使用姿势。也许这样的问题还存在不少团队的应用中,所以拿出来再分享一下,希望可以帮助读者更好的理解注册中心与API网关的作用,并将它们用对地方!
在微服务架构中,我们都会使用API网关来作为暴露服务的唯一出口。这样可以将与业务无关的各项控制,集中的在API网关中进行统一管理,从而使得业务服务可以更加专注于业务领域本身。
而在微服务构建的系统内部,各个服务之间的调度,我们通常采用注册中心和客户端负载均衡的方式来实现服务之间的调用。
所以,大致的结构是这样子的:
在这样的架构实践中,注册中心和API网关的功能,主要有以下两点:
下面就来具体说说今天的主角(错误案例),先上图:
注意图中的两个地方:
更震惊的是,在我看到代码的时候,他们居然也是用feign来编写服务间调用的,但在配置请求路径的时候,是使用在内部API网关上配置的二级域名来实现(比如:http://service-name.didispace.com/api-path
,这里service-name
对应不同的服务名),而熟悉Spring Cloud的读者都知道,其实service-name.didispace.com
这部分直接用服务名替代就可以了...是不是瞬间有种脱裤子放x的感觉?
如果这样来使用的话,其实引入注册中心的用处就很小了,实际上只有给两个网关提供了集中的后端服务发现功能。如果要实现这种功能,其实注册中心都可以不需要,每个服务都直接上报地址给网关就好了,架构会更加简单。
同时,在这样的实现方式之下,内部调用都要经过内部网关多一跳的调度过程,除了要多出内部网关的部署资源之外,每一次内部调用的时间开销实际上都大了。所以这样的用法是非常不推荐的!
对于API网关的定位,还是以作为对外出口的管理为最佳,内部的代理调用,均交给服务注册与发现机制 + 客户端负载均衡就ok了。没有必要再增加一层代理,不但增加部署成本,同时还会降低的性能。完全是赔了夫人又折兵的做法,非常不可取!
除非有一种情况,如果你的业务集群很大,对前端暴露用一套网关,同时后端服务有几千几万,由很多个不同的团队在维护,那么在团队的边界处设立内部的网关,那还是合理的。同时这种情况下,对于注册中心,按团队做隔离也是有必要的。因为这样可以分而治之,更好的做好接口的访问控制与管理。但是,如果你本身服务不多,团队也不大,那就别折腾这么复杂的架构了,越复杂稳定性就越难保障,这点一定要平衡好。
最后,大家结合自己团队的注册中心与API网关应用是否有犯一样的问题呢?或者如果有其他问题与疑问,不妨留言交流一下?也可以加入我们的技术交流群一起探讨技术问题!
欢迎关注我的公众号:程序猿DD,获得独家整理的免费学习资源助力你的Java学习之路!另每周赠书不停哦~
任务 (task) 定义了事件发生时所执行的动作,比如在输入一个卡片或选择一个链接...
一般使用td元素的colspan属性来实现单元格跨列操作,使用td元素的rowspan属性来...
前不久为了寻找表格(table)所包含的主要标签,一直在寻找着,找到当然就是跟大...
如何使整个页面内容居中,如何使高度适应内容自动伸缩。这是学习CSS布局最常见的...
1.拥有希望,也许会失望,但放弃希望,却一定绝望。 2.靠爸妈,你最多是公主,...
1,使用调速函数控制过渡效果的速度曲线(加速,减速等) 使用调速函数可以设置...
Docker 是什么? Docker 是一个开源的容器引擎,可以轻松的为任何应用创建一个轻...
1.青春是一本太仓促的书,我们含着泪,一读再读。 2.少年的时光就是晃,用大把...
1、要响应式开发web,也就是页面必须自适应屏幕大小,可以采用流体布局,如之前...
今天仍是Watch应用设计案例。我很喜欢案例学习,所以不会介意连续三周来做相同的...