『荐读』微服务架构之「服务注册」

Posted 2021-04-14 WHITer

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了『荐读』微服务架构之「服务注册」相关的知识，希望对你有一定的参考价值。

微服务架构是一个庞大复杂的工程，为什么说它庞大复杂呢？因为想要做好微服务，就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章中已经初步介绍过了这些组件，包括：服务注册、服务网关、配置中心、服务框架、服务监控、服务追踪、服务治理等。

只有将这些基础设施搭建完善了，微服务实践的道路才能走的稳、走的远。后面的文章中会依次把每一个基础组件都详细分析一下。今天我们就先挑选「服务注册」聊一聊。

我们再来回到微服务架构中，一般集群都会部署很多个微服务节点。这些节点一般也具备这2种角色，称为：“服务的提供者” 和 “服务的消费者”。

“服务消费者”需要调用“服务提供者”的API来获得服务。当“服务提供者”的节点有增加或减少的时候，也得让调用者（“服务消费者”）及时的知晓。而在大规模集群中，一般节点数目都很多，节点变化频繁，通过手动去维护这些节点的状态是不现实的，因此需要一个叫做“服务注册中心”的组件来实现。

在分析其原理之前，我们先来看一下这里包含的一些角色，有三类：“服务提供者”、“服务消费者”、“服务注册中心”。

其中“服务提供者”需要将自己的服务信息注册到“服务注册中心”里面。而“服务消费者”需要到“服务注册中心”里面去查询有哪些服务可以调用。因此，我们可以分为两个视角去分析原理：

自己注册：
如图，自己注册就是指微服务节点在启动的时候，自己去服务注册中心登记注册了，把自己的信息和状态传过去。这种方式整体结构比较简单，对于注册中心而言也比较省事，但是对于微服务节点而言，每个微服务都得包含这么一段注册的逻辑代码，架构上看起来不是很优美。
第三方注册：
如图，第三方注册就是指有一个“服务管理器”（图中的Service Manager），这个“服务管理器”会去管理所有的微服务和进程，以轮询或其它方式去检查有哪些微服务实例正在运行，会将这些微服务实例自动更新到服务注册中心。这是目前比较常用的方式，例如Eureka就是采用这个模式。
如果再拿114百事通的例子来讲，就相当于114中心安排了一个管理员，这个管理员会定期的到街上去看一看有哪些新开的商店就把它登记下来，有哪些关闭了的商店就从注册中心删除掉。

客户端模式
客户端模式在实现上比较简单。
代理模式
这种模式，看起来“服务消费者”省事了，但是API Gateway模块却复杂了，因为API Gateway就是整个系统的一个非常核心关键节点了，不仅需要保障自己的稳定性和性能，而且还需要处理一些负载均衡的逻辑。在大型架构中，这种模式用的还比较多。

讲完了服务注册中心的必要性和原理，我们再来看一下在实际应用中应该如何去应用。虽然我们可以根据原理自己去开发一套服务注册中心，但是如果没有特殊需求，还是不建议重复造轮子了，市面上有很多成熟的方案可以直接使用。

Eureka
Eureka是由Netflix开源，其架构如下图：
从图中可以看到，我们的服务（图中Application Clinet与Application Service）要使用Eureka就需要集成它的SDK（图中Eureka Client）。图中的Eureka部署在了三个异地机房，也就是说Eureka是支持多中心部署的。
服务提供者（Application Service）通过Eureka Client实现服务的注册、更新和注销等。服务消费者（Application Clinet）通过Eureka Client实现服务的查询和调用。
Eureka支持了与Spring Cloud的集成，所以使用起来也非常方便，目前属于比较流行的方案。
Consul
Consul是另外一个非常流行的开源组件，如下图:
Consul是在服务外进行完成一系列动作的，也就是说并不需要服务节点去依赖它的SDK，没有侵入性，所以跨语言的解决能力更强一些。它一般是在服务节点外通过一些探针的方法去检查应用是否存活，是否需要注册或注销。
Consul也支持Spring Cloud集成，所以使用起来也很方便，也属于比较流行的方案。
Etcd、Zookeeper
这两个也有一些公司基于它们来实现服务注册，也集成了Spring Cloud，不过不算非常广泛。