微服务架构是一个庞大复杂的工程，为什么说它庞大复杂呢？

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

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

一、为什么需要「 服务注册 」？

我们先来举一个生活中的例子：在以前互联网还不够发达的时候，“114号码百事通”大家应该很熟悉，有啥需求就会去打个电话查询一下。比如想知道附近电影院电话是多少，就会先去打114问一下。那114为啥知道这么多信息呢，还不是因为各类服务者（商店、机构等）都已经在114上登记了嘛。所以这里的“114百事通”就相当于一个服务注册中心了，这里的各类商店机构就相当于可以提供不同服务的服务者了，而打电话的我们就是去寻找这些服务的消费者了。

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

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

“服务提供者”将自己的服务地址等信息登记到“服务注册中心”中，调用者（“服务消费者”）需要的时候，每次都先去“服务注册中心”查询即可。既解决了人工维护微服务节点状态的问题，也能解决多节点间负载均衡的问题。

二、「 服务注册 」的实现原理是什么？

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

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

从“服务提供者”的视角， “服务提供者”向“服务注册中心”进行注册：

登记注册具体的也有为两种方式，一种是自己注册，另一种是第三方注册。

自己注册：

如图，自己注册就是指微服务节点在启动的时候，自己去服务注册中心登记注册了，把自己的信息和状态传过去。这种方式整体结构比较简单，对于注册中心而言也比较省事，但是对于微服务节点而言，每个微服务都得包含这么一段注册的逻辑代码，架构上看起来不是很优美。

再拿114百事通的例子解释一遍，自己注册就表示这是商家开店之后自己跑去告诉114电话台，说自己商店开业了，目前在经营着哪些服务，请求114登记下来。

第三方注册：

如图，第三方注册就是指有一个“服务管理器”（图中的Service Manager），这个“服务管理器”会去管理所有的微服务和进程，以轮询或其它方式去检查有哪些微服务实例正在运行，会将这些微服务实例自动更新到服务注册中心。这是目前比较常用的方式，例如Eureka就是采用这个模式。

如果再拿114百事通的例子来讲，就相当于114中心安排了一个管理员，这个管理员会定期的到街上去看一看有哪些新开的商店就把它登记下来，有哪些关闭了的商店就从注册中心删除掉。

从“服务消费者”的视角，“服务消费者”向“服务注册中心”查询和调用服务：

对于服务的查询和调用，也分为两种模式：客户端模式和代理模式。

客户端模式

在客户端模式下，“服务消费者”（图中的Client）在向“服务注册中心”查询到自己需要调用的“服务提供者”的地址之后，“服务消费者”（客户端）就会自己根据地址去访问微服务（图中的第3步 API Gateway是可选项，有API Gateway的情况下，API Gateway起到负载均衡作用，没有第3步的话，那就是Client直接调用Microservice，需要Client自己写负载均衡逻辑）。

客户端模式在实现上比较简单。

代理模式

在代理模式下，“服务消费者”（图中的Client）与 微服务、“服务注册中心”中间有一个 API Gateway组件相隔着。“服务消费者”只管去找API Gateway访问即可。至于去注册中心查询服务地址，以及访问服务地址的动作都由API Gateway效劳了，最后API Gateway在把结果返回给“服务消费者”即可。

这种模式，看起来“服务消费者”省事了，但是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，不过不算非常广泛。

以上，就是对微服务架构中「 服务注册 」的一些思考。