体系化认识微服务之四：服务注册发现机制

Posted 2022-11-02 rhwayfunn

服务调用者要在众多的微服务中调用具体的服务提供者，必然涉及到负载均衡的问题，根据负载均衡的实现可以分为集中式LB、进程内LB和独立进程LB。

集中式LB

LB上有所有的服务地址配置，当服务消费者调用某个服务的时候，LB会根据负载均衡策略（随机、轮询等）将请求转发到具体的服务上。此外，服务调用者还需要知道LB的地址，通常的做法是运维在服务器上配置一个DNS域名或者IP，这个域名指向LB。

这种实现方式的问题每次调用都要访问LB，LB存在单点问题，无法水平扩展

进程内LB

为了解决每次服务调用都经过LB的不足，把LB放在客户端可以很好解决，这里多了一个注册表，服务提供方启动时，首先将服务地址注册到服务注册表，定期发送心跳包到服务注册表，检查存活状态。

服务消费方要访问某个服务时，经历以下过程：

1. 服务消费者在启动时从服务注册表获取需要的服务注册信息
2. 将服务提供者注册信息缓存在本地（客户端LB）
3. 监听服务提供者注册信息的变更，如接收到服务注册中心的服务变更通知，则在本地缓存中更新服务的注册信息
4. 根据本地缓存中的服务注册信息构建服务调用请求，并根据负载均衡策略（随机负载均衡，Round－Robin负载均衡等）来转发请求
5. 对服务提供方的存活进行检测，如果出现服务不可用的服务提供方，将从本地缓存中剔除，定期检测本地服务注册表的存活状态

这一方案对服务注册表的可用性要求很高，一般采用能满足高可用分布式一致的组件(例如Zookeeper、Consul、Etcd等)来实现。这里由于LB是在服务调用者的进程内，那么每个服务调用者都有自己的本地LB，不会导致每次调用都直接访问LB的情况，而且服务调用者直接访问服务提供者，没有额外的开销。

这样部署的条件是服务注册表要支持高可用，通常采用集群部署的方式实现。目前开源组件比如Dubbo、Eureka、Karyon都是采用类似这种服务注册发现机制，不足是要对不同的语言开发不同的客户端，因为LB需要进行路由，不同的语言就需要开发不同的客户端进行路由，比如Dubbo本身是用Java开发的，只要配和注册中心比如zookeeper就可以完成服务注册和发现，但是使用Node.js如果要调用dubbo服务就需要开发基于Node.js的客户端去发现dubbo的服务，相当于是Node.js版的Dubbo。

独立进程LB

与第二种类似，区别是这将LB作为独立进程，好处是多语言环境下可以不用开发不同的客户端，不足是部署复杂，增加了出错调试的复杂度。只要LB进程的主机部署了其他应用，不管是什么语言开发的都能通过LB完成路由，这样就不需要开发专门的客户端去路由了

每次服务调用都要穿透主机所在的LB，包括请求和响应。目前开源的组件有Airbnb的SmartStack