一张图讲解微服务-注册中心，微服务网关和API网关区别-一张图讲解微服务-注册中心，微服务网关和API网关区别

热门回复：

• 俗邻老古:谢谢up，能探讨个问题吗？我理解这个应该是业务规模较大，且要满足未来更多扩展业务、第三方业务接入的架构，下一步可能就是要提升稳定性多开架构了吧。 那么作为自由职业、小公司，这类模型拿过来根本不适应，一般就是小项目做完小客户用好就可以了。 比方说好的模型是山顶，小项目用的模型是山下，如何能够让这些好模型平滑过渡到小项目，而让小项目在爬山的过程中，既轻装快行，又能灵活升级呢？
• 带你去吃小豆花:微服务里的服务发现注册中心，一般适用于微服务之间的接口访问和调用，本身是去中心化的，微服务网关主要是在微服务架构里涉及到了前端应用，前端应用需要做好访问后端应用的接口，需要一个网关实现统一的微服务接口代理和流量转发，于是引入了微服务网关，那为什么使用微服务网关而不是反向代理（如nginx）呢，是因为nginx不可以自动的去进行心跳检测来进行负载均衡，也没服务发现机制，也就是说后端微服务进行变化时，不能自动的，动态反映在nginx上（需要手动在代理上做修改）；下面说内部微服务向外延展时，会涉及到细粒度api接口和权限控制，于是需要在微服务上层构建一个api网关，会详细的管理每个api接口（比如采购服务的接口，招标服务接口），对每个接口实现相应的安全日志，限流，熔断等操作
• sky夜耀:知识储备不够，每期都听的半知半懂
• jackbryant永不言弃:我们目前的架构和老师讲的稍微有些不同,但是基本类似,听完后收获不少,感谢,我们是 Nginx负载均衡器集群--->Zuul网关集群、Eureka服务治理--->后端的服务集群 微服务与微服务之间的调用,一般是去中心化(点对点),,service A直接调用service B(内网调用,不经过转发),速度很快(流量有限,可能会忽略掉认证授权问题等等) 但是还是做服务的注册和发现,因为微服务都需要将服务注册到注册中心(Consul、Eureka等等) 服务提供者向注册中心注册服务,服务消费者去注册中心做服务发现,获取指定的服务信息, 拿到了服务信息后,可以进行相关处理后直接调用服务但是前端调用后端服务(前后端分离架构,跨应用调用-为了安全性考虑,不把底层微服务站点地址暴露在外网), 在微服务架构中,一般是要经过API网关(API网关提供接口暴露供前端调用), ,然后由网关转发到底层的微服务,(API GateWay会和注册中心做一个集成,去服务注册中心做服务发现 根据服务名称找到对应的服务信息(ip+port)--前提是服务在线,然后直接将请求转发给真正的底层微服务 比如:spring cloud中的zuul网关和eureka注册中心 这种对外接口暴露地址是: api网关地址/服务名称/接口路由地址 网关本身也是个服务,也会注册到eureka注册中心,而且为了提高高可用性,也是多实例部署(集群), 前面再加一层负载均衡器,主要是为了保证api网关集群的高可用性), 那么我们可以在api网关层做很多非业务性功能 (路由转发、负载均衡、API限流(流量的控制)、认证授权、链路追踪、熔断降级等等), 业务量比较大的话,整个后端的高并发难以避免,有时会有大量的流量进来,这时就需要提高整个服务的高可用性。 所有正常生产环境上,都是以集群的方式(多实例部署)提高服务的高可用性。 使用相关的负载均衡算法,将流量均摊到各个服务节点上。 我们目前实际生产大概是这样干的
• 烂牌-:有一个小问题，就是现在公司都会接入mesh，用mesh来做限流熔断等调度策略的管控，那这个时候是用api网关做这些好还是用mesh来做这个好呢？[热词系列_妙啊]