在微服务架构或分布式环境下，服务注册与发现技术不可或缺，这也是程序员进阶之路必须要掌握的核心技术之一，本文通过图解的方式带领大家轻轻松松掌握。

引入服务注册与发现组件的原因

先来看一个问题，假如现在我们要做一个商城项目，作为架构师的你应该怎样设计系统的架构？你心里肯定在想：这还不容易直接照搬淘宝的架构不就行了。但在现实的创业环境中一个项目可能是九死一生，如果一开始投入巨大的人力和财力，一旦项目失败损失就很大。

作为一位有经验的架构师需要结合公司财力、人力投入预算等现状选择最适合眼下的架构才是王道。大型网站都是从小型网站发展而来，架构也是一样。

任何一个大型网站的架构都不是从一开始就一层不变的，而是随着用户量和数据量的不断增加不断迭代演进的结果。

在架构不断迭代演进的过程中我们会遇到很多问题，技术发展的本质就是不断发现问题再解决问题，解决问题又发现问题。

单体架构

在系统建立之初可能不会有特别多的用户，将所有的业务打成一个应用包放在tomcat容器中运行，与数据库共用一台服务器，这种架构一般称之为单体架构。

应用与数据共同部署

在初期这种架构的效率非常高，根据用户的反馈可以快速迭代上线。但是随着用户量增加，一台服务的内存和CPU吃紧，很容易造成瓶颈，新的问题来了怎么解决呢？

应用与数据分离

随着用户请求量增加，一台服务器的内存和CPU持续飙升，用户请求响应时间变慢。这时候可以考虑将应用与数据库拆开，各自使用一台服务器，你看问题又解决了吧。

突然有一天扫地阿姨不小心碰了电线，其中一台服务器掉电了，用户所有的请求都报错，随之而来的是一系列投诉电话。

集群部署

单实例很容易造成单点问题，比如遇到服务器故障或者服务能力瓶颈，那怎么办？聪明的你肯定想到了，用集群呀。

集群部署是指将应用部署在多个服务器或者虚机上，用户通过服务均衡随机访问其中的一个实例，从而使多个实例的流量均衡，如果一个实例出现故障可以将其下线，其他实例不受影响仍然可以对外提供服务。

随着用户数量快速增加，老板决定增加投入扩大团队规模。开发团队壮大后效率并没有得到显著的提高，以前小团队可以一周迭代上线一次，现在至少需要两到三周时间。

业务逻辑越来越复杂，代码间耦合很严重，修改一行代码可能引入几个线上问题。架构师意识到需要进行架构重构。

微服务架构演进与数据交互

当单体架构演进到一定阶段后开发测试的复杂性都会成倍增加，团队规模的扩大也会使得各自工作耦合性更严重，牵一发而动全身就是这种场景。

单体架构遇到瓶颈了，微服务架构就横空出世了。微服务就是将之前的单体服务按照业务维度进行拆分，拆分粒度可大可小，拆分时机可以分节奏进行。最佳实践是先将一些独立的功能从单体中剥离出来抽成一个或多个微服务，这样可以保障业务的连续性和稳定性。

微服务之间交互方式

如上图将一个商城应用拆分为六个独立微服务。六个微服务可以使用Docker容器化进行多实例部署。

架构演化到这里遇到了一个难题，如果要查询用户所有的订单，用户服务可能会依赖订单服务，用户服务如何与订单服务交互呢？订单服务有多个实例，又该访问哪一个？

不同服务之间如何进行数据交互？通常有几种解决办法：

（1）服务地址硬编码

服务的地址写死在数据库或者配置文件，通过访问DNS域名进行寻址路由。

服务B的地址硬编码在数据库或者配置文件中，服务A首先需要拿到服务B的地址，然后通过DNS服务器解析获取其中一个实例的真实ip地址，最后可以向服务B发起请求。

如果遇到大促活动需要对服务实例扩容，大促完需要对服务实例进行下线，运维人员要做大量的手工操作，非常容易误操作。

（2）服务动态注册与发现

服务地址硬编码还有一个非常致命的问题，如果一台实例挂了，运维人员可能不能及时感知到，导致一部分用户的请求会异常。

引入服务注册与发现组件可以很好解决上面遇到的问题，避免过多的人工操作。

架构演进总结

在单体架构中一个应用程序就是一个服务包，包内的模块通过函数方法相互调用，模型足够简单，根本没有服务注册和发现一说。

在微服务架构中会将一个应用程序拆分为多个微服务，微服务会部署在不同的服务器、不同的容器、甚至多数据中心，微服务间要相互调用，服务注册和发现成为了一个不可或缺的组件。

为什么需要服务注册

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

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

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

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

服务注册与发现基本原理

服务注册与发现分为注册和发现两个关键的步骤，其中有三个角色：服务提供者、服务消费者、服务注册中心。

服务注册：服务进程在注册中心注册自己的元数据信息。通常包括主机和端口号，有时还有身份验证信息，协议，版本号，以及运行环境的信息。

服务发现：客户端进程向注册中心发起查询，来获取服务的信息（服务在哪台机器上、使用什么协议、运行环境等）。服务发现的一个重要作用就是提供给客户端一个可用的服务列表。

服务提供者：将自己的服务信息注册到“服务注册中心”里面。

服务消费者：到“服务注册中心”里面去查询有哪些服务可以调用。

因此，我们可以分为服务提供者和服务消费者这两个视角去分析原理，这就有了服务注册和服务发现的概念。

服务注册

服务注册有两种形式：客户端自己注册和第三方代理注册。

自己注册

客户端自己注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己。

这种方式的缺点是注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。

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

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

第三方代理注册

第三方代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作。

这种方式的缺点是多引用了一个代理服务，并且代理服务要保持高可用状态。

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

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

服务发现

从“服务消费者”的视角，“服务消费者”向“服务注册中心”查询和调用服务。从服务的查询和调用的发现方式角度，也分为两种模式：客户端发现 和 代理发现。

客户端发现

客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后，客户端根据负载均衡算法选择一个实例发起请求调用。

这种方式比较简单直接，客户端可以控制负载均衡算法。但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。

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

代理发现

代理发现是指新增一个路由服务，该服务负责查询发现并获取可用的实例列表，服务消费者如果需要调用服务A的一个实例，可以直接将请求发往路由服务，路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可，如果发现实例不可用，路由服务还可以自行重试，服务消费者完全不用感知。

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

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

心跳机制

如果服务有多个实例，其中一个实例出现宕机，注册中心可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。

如何实现摘机？业界比较常用的方式是通过心跳检测的方式实现，心跳检测有主动和被动两种方式，这里的主动还是被动都是从注册中心的角度来讲。

被动监测

被动检测是指服务主动向注册中心发送心跳消息，注册中心被动接收，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。

上图中服务A的实例2已经宕机不能主动给注册中心发送心跳消息，15秒之后注册就会将实例2移除掉。

主动监测

主动检测是注册中心主动发起，每隔几秒会给列表中所有的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例。

业界常用的服务注册与发现组件对比

了解服务注册与发现的基本原理后，如果你要在项目中使用服务注册与发现组件，当面对众多的开源组件该如何进行技术选型？

在互联网公司里，有研发实力的大公司一般会选择自研或者基于开源组件进行二次开发，但是对于中小型公司来说直接选用一款开源软件会是一个不错的选择。

常用的注册与发现组件有eureka，zookeeper，consul，etcd等，由于eureka在2018年已经宣布放弃维护，这里就不再推荐使用了。

下面结合各个维度对比一下各组件。

组件	优点	缺点	接口类型	一致性算法
zookeeper	1.功能强大，不仅仅只是服务发现； 2.提供watcher机制可以实时获取服务提供者的状态； 3.广泛使用，dubbo等微服务框架已支持；	1.没有健康检查； 2.需要在服务中引入sdk，集成复杂度高； 3.不支持多数据中心；	sdk	Paxos
consul	1.开箱即用，方便集成； 2.带健康检查； 3.支持多数据中心； 4.提供web管理界面；	不能实时获取服务变换通知	restful/dns	Raft
etcd	1.开箱即用，方便集成； 2.可配置性强	1.没有健康检查； 2.需配合三方工具完成服务发现功能； 3.不支持多数据中心；	restful	Raft

从整体上看consul的功能更加完备和均衡。接下来以consul为例详细介绍一下。

Consul——值得推荐的服务注册与发现开源组件

简单认识一下Consul

Consul是HashiCorp公司推出的开源组件，使用Go语言开发，具有开箱即用、方便部署的特点。Consul是一款分布式的、高可用的、可横向扩展的用于实现分布式系统的服务发现与配置的开源组件。

Consul有哪些优势？

服务注册发现：Consul提供了通过DNS或者restful接口的方式来注册服务和发现服务。服务可根据实际情况自行选择。
健康检查：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联，也可以与本地节点相关联。
多数据中心：Consul支持多数据中心，这意味着用户不需要担心Consul自身的高可用性问题以及多数据中心带来的扩展接入等问题。

Consul的架构图

Consul 实现多数据中心依赖于gossip protocol协议。这样做的目的：

不需要使用服务器的地址来配置客户端；服务发现是自动完成的。
健康检查故障的工作不是放在服务器上，而是分布式的。

Consul的使用场景

Consul的应用场景包括服务注册发现、服务隔离、服务配置等。

服务注册发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check。

服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密。

服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息。

参考

13张图彻底搞懂分布式系统服务注册与发现原理

微服务架构之「服务注册」

分布式系统服务注册与发现概念和原理相关推荐

分布式系统服务注册与发现原理 SpringCloud 学习笔记
分布式系统服务注册与发现原理 & SpringCloud 学习笔记分布式系统服务注册与发现原理引入服务注册与发现组件的原因单体架构应用与数据分离集群部署微服务架构架构演进总结服 ...
13张图彻底搞懂分布式系统服务注册与发现原理
在微服务架构或分布式环境下,服务注册与发现技术不可或缺,这也是程序员进阶之路必须要掌握的核心技术之一,本文通过图解的方式带领大家轻轻松松掌握. 引入服务注册与发现组件的原因先来看一个问题,假如现在我 ...
13 张图彻底搞懂分布式系统服务注册与发现原理
作者 | 雷架来源 | 爱笑的架构师(ID:DancingOnYourCode) 头图 | CSDN 下载自东方IC 在微服务架构或分布式环境下,服务注册与发现技术不可或缺,这也是程序员进阶之路必 ...
13张图解分布式系统服务注册与发现机制，给你整明白
本文 Github/javamap 已收录,有Java程序员进阶技术知识地图以及我的系列文章,欢迎大家Star. 在微服务架构或分布式环境下,服务注册与发现技术不可或缺,这也是程序员进阶之路必须要掌 ...
微服务系列：服务注册与发现的实现原理、及实现优劣势比较
服务注册与发现的来源首先,服务注册与发现是来自于微服务架构的产物. 在传统的服务架构中,服务的规模处于运维人员的可控范围内.当部署服务的多个节点时,一般使用静态配置的方式实现服务信息的设定.而在微服 ...
nacis服务注册原理_服务注册和发现之Eureka原理篇
概念在传统应用组件间调用,通过接口规范约束来实现的,从而实现不同模块间良好协作:但是被拆分成微服务后,每个微服务实例的数量和网络地址都可能动态变化,使得原来硬编码的地址极不方便,故需要一个中心化的组 ...
8、Zookeeper服务注册与发现原理浅析
了解Zookeeper的我们都知道,Zookeeper是一种分布式协调服务,在分布式应用中,主要用来实现分布式服务的注册与发现以及分布式锁,本文我们简单介绍一下Zookeeper是如何实现服务的注册与 ...
Consul微服务注册与发现
Consul微服务注册与发现概念安装与运行服务提供者服务消费者总结:Eureka.Zookeeper.Consul 的异同概念 1.什么是Consul? Consul是一套开源的分布式服务 ...
go-kit微服务，服务注册与发现，负载均衡（二）
目录 consul简介 consul安装手动操作代码操作服务注册服务反注册拉取服务list 服务发现测试代码负载均衡 consul简介 Consul 是 HashiCorp 公司推出的开 ...

分布式系统服务注册与发现概念和原理