白话讲解微服务注册发现及负载均衡

一、公益图书馆例子

笔者不想直接用专业的术语来说明“微服务注册与发现”，所以我们来看生活中的一个案例：“公益图书馆”。随着人们生活水平的不断提高，追求精神食粮的朋友也越来越多。笔者曾经在一些城市看见过公益图书馆，其运行逻辑是：一些公益组织和个人提供一块场所，然后由组织内的人向图书馆内捐书。捐出的书越多，一段时间内能够借阅的书也就越多。这种做法有助于大家分享图书、节约资金、交流读书心得。那我们来看一下几个关键环节：

• 捐书：组织内的人向公益图书馆捐书，是不是直接将书放到书架上就完事了呢？当然不是，是先向图书管理系统记录一下捐书的人、书名、捐书的时间等信息，再将书放到书架上。
• 借书：借书的人通常是通过图书管理系统的一个小程序查询图书，然后取书，全靠自觉。图书可能存在多个副本（多人捐的同一种书），借书的人会根据书籍状态择优选择。
• 这其中非常重要的一个角色就是图书管理系统及其小程序，为大家捐书、借书提供了数据支持和集中管理功能。
• 兼职图书管理员定期维护图书，将破损图书从图书管理系统中下架维护。

其实上面的这个“公益图书馆的例子”就是典型的服务注册与发现：

• 每一本图书就是一个服务，捐书的过程就是“服务注册”的过程。
• 借书的查询图书的过程就是“服务发现”的过程。
• 其中最重要的角色：图书管理系统、管理员及其小程序，就是服务注册中心或者服务注册平台。
• 捐书者可能同时是借书者。进行服务注册的微服务节点，同时可能也使用服务发现机制发现其他微服务。
• 捐书是主动行为，不是被动行为。这和微服务的注册是一样的，微服务必须在启动的时候向服务注册组件进行主动注册。这样做的目的就是降低数据维护成本，不需要专人维护注册数据。
• 图书下架是被动的，不是主动的，不是捐书的人将其下架。微服务也是一样，当服务出现故障发生问题，服务发现注册组件应具备将服务下线的能力。
• 图书管理员可以检查图书并下架，这过程在服务注册与发现中被称为：健康检查
• 对于同一种图书可能存在多个同样的副本，由使用者择优选择借哪一本书。对于服务发现获得的结果：同一种服务的多个副本的情况，由服务调用者择优决定使用哪一个服务副本。这种服务方式比较专业的说法是：客户端负载均衡。

与客户端负载均衡相对的方法就是服务端负载均衡，如果上面的例子中借书过程一本书有多个副本，由图书管理员或系统决定借书者借其中的哪一个副本，这个就是服务端负载均衡。

二、服务注册与发现

• 服务注册 -服务在中央注册表中注册其服务位置的过程。通常注册其主机和端口，有时还注册认证凭证，协议，版本号和或环境信息。
• 服务发现 -客户端应用程序查询中央注册表以了解服务位置的过程。
• 维护中央注册表的角色被称为服务注册平台或者服务注册中心

2.1. 服务注册

当一个微服务启动的时候，必须主动向服务注册中心注册其服务地址，以供其他微服务查询调用。图中橘黄色为服务注册中心，绿色为微服务节点。

图片：服务注册

2.2.客户端负载均衡（服务发现）

当一个微服务有多个副本的时候，由调用者决定使用哪一个副本提供服务。

服务发现：客户端负载均衡（服务发现）

三、Spring Cloud常用的服务注册中心

• Eureka：Spring Cloud的大儿子，出生的时候条件一般，长大后素质有限
• Nacos：后起之秀，曾经Spring Cloud眼中“别人家的孩子”，已经纳入收养范围（孵化项目）。
• Apache Zookeeper：关系户，与hadoop关系比较好
• etcd：关系户，与kubernetes关系比较好
• Consul：关系户，曾经与Docker关系比较好

如果你的应用已经使用到了hadoop、kubernetes、docker，在Spring Cloud实施过程中可以考虑使用其关系户组件，避免搭建两套注册中心，节省资源。但是二者兼容使用说说容易，真正用起来还需要功夫。目前看，笔者觉得与Spring Cloud关系最好的应该是Nacos。