在微服务模式下，服务个数少则几十个、上百个，多则上千个，每个服务一般都以集群方式部署，这时自然产生2个问题，服务发现和负载均衡
(1)服务发现，服务消费者Consumer如何发现服务提供者Provider
(2)负载均衡，服务消费者Consumer以哪种负载均衡策略访问多实例部署的服务提供者Provider
微信图片_20181102162756.jpg
在服务消费者和服务提供者之间，增加1层代理，由代理负责服务发现和负载均衡功能，消费者通过代理间接访问目标服务。服务发现和负载均衡并不是新问题，它们都有成熟的解决方案，关键在于代理，以及代理在架构中的位置，可分为3种模式
-
服务器端集中式代理
微信图片_20181102163144.jpg
代理作为独立的1层进行部署，并且需要专门进行维护
使用软件负载均衡器Nginx或硬件负载均衡器F5做负载均衡工作
服务发现工作，需要建立服务和IP地址的映射关系，服务消费者仅依赖服务名，由代理完成从服务名到IP地址的转换，并将请求路由出去
eBay和携程采用这种方式
[我们的架构]
-
客户端嵌入式代理
微信图片_20181102163150.jpg
包含服务发现和负载均衡逻辑的代理，以Java类库的方式嵌入在客户端应用程序中，需要独立的服务注册中心。服务启动时，向服务注册中心注册并定期发送心跳，当服务Down掉了，会被标记为不可用。客户端代理发现服务并做负载均衡调用
Netflix的Eureka和Ribbon可用作服务注册中心和客户端的负载均衡器，阿里的Dubbo也是这种模式
- 主机独立进程代理
代理既不在服务器端，也不在客户端，而是作为独立进程部署在集群的每个主机上。1个主机上的多个消费者共用代理，实现服务发现和负载均衡。没有过多了解，唯品会做过相关的研究
网友评论