还有谁?
服务注册发现和负载均衡是微服务架构在技术上的根本问题,解决的办法是采用代理Proxy。
根据代理在架构上的位置不同,服务发现代理一般有三种模式
集中式代理
简单、传统,独立一层集中部署,由独立团队(一般是运维或框架)负责治理和运维。
常用的集中式代理有硬件负载均衡器(如F5),软件负载均衡器(如Nginx),F5(4层负载)+Nginx(7层负载)
相对比较重,有单点问题和性能问题
可以和服务注册中心结合,降低手工配置的复杂性,实现DevOps研发自助部署。
目前社区流行的开源代理如traefik和kong等都支持和服务注册中心(Consul/Eureka/Etcd/Zookeeper等)进行集成……
客户端嵌入式
代理嵌入在应用程序中。一般需独立的服务注册中心组件配合,启动时自动注册到注册中心并定期报心跳,
客户端代理则发现服务并做负载均衡。
Eureka
客户端复杂,支持多语言困难,无法集中治理
主机独立进程
两种模式的折中,作为独立进程部署在每台主机上,主机上的多个消费者共用这个代理,
实现服务发现和负载均衡,一般也需要独立的服务注册中心组件配合。
弥补两者不足,纯分布式的,无单点问题,性能也OK,应用语言栈无关,可以集中治理。
ServiceMesh
运维部署复杂