微服务里的服务发现注册中心，一般适用于微服务之间的接口访问和调用，本身是去中心化的，微服务网关主要是在微服务架构里涉及到了前端应用，前端应用需要做好访问后端应用的接口，需要一个网关实现统一的微服务接口代理和流量转发，于是引入了微服务网关，那为什么使用微服务网关而不是反向代理（如nginx）呢，是因为nginx不可以自动的去进行心跳检测来进行负载均衡，也没服务发现机制，也就是说后端微服务进行变化时，不能自动的，动态反映在nginx上（需要手动在代理上做修改）；下面说内部微服务向外延展时，会涉及到细粒度api接口和权限控制，于是需要在微服务上层构建一个api网关，会详细的管理每个api接口（比如采购服务的接口，招标服务接口），对每个接口实现相应的安全日志，限流，熔断等操作
@ zccao 分享
我们目前的架构和老师讲的稍微有些不同,但是基本类似,听完后收获不少,感谢,我们是
Nginx负载均衡器集群--->Zuul网关集群、Eureka服务治理--->后端的服务集群
微服务与微服务之间的调用,一般是去中心化(点对点),,service A直接调用service B(内网调用,不经过转发),速度很快(流量有限,可能会忽略掉认证授权问题等等)
但是还是做服务的注册和发现,因为微服务都需要将服务注册到注册中心(Consul、Eureka等等)
服务提供者向注册中心注册服务,服务消费者去注册中心做服务发现,获取指定的服务信息,
拿到了服务信息后,可以进行相关处理后直接调用服务但是前端调用后端服务(前后端分离架构,跨应用调用-为了安全性考虑,不把底层微服务站点地址暴露在外网),
在微服务架构中,一般是要经过API网关(API网关提供接口暴露供前端调用),
,然后由网关转发到底层的微服务,(API GateWay会和注册中心做一个集成,去服务注册中心做服务发现
根据服务名称找到对应的服务信息(ip+port)--前提是服务在线,然后直接将请求转发给真正的底层微服务
比如:spring cloud中的zuul网关和eureka注册中心
这种对外接口暴露地址是: api网关地址/服务名称/接口路由地址
网关本身也是个服务,也会注册到eureka注册中心,而且为了提高高可用性,也是多实例部署(集群),
前面再加一层负载均衡器,主要是为了保证api网关集群的高可用性),
那么我们可以在api网关层做很多非业务性功能
(路由转发、负载均衡、API限流(流量的控制)、认证授权、链路追踪、熔断降级等等),
业务量比较大的话,整个后端的高并发难以避免,有时会有大量的流量进来,这时就需要提高整个服务的高可用性。
所有正常生产环境上,都是以集群的方式(多实例部署)提高服务的高可用性。
使用相关的负载均衡算法,将流量均摊到各个服务节点上。
我们目前实际生产大概是这样干的
