微服务架构之服务注册与发现功能详解
⽬录
微服务的注册与发现
1、服务注册
2、服务发现
3、注册中⼼
4、现下的主流注册中⼼
4.1 Eureka
4.1.1 介绍
4.1.2 整体架构
4.1.3 接⼊Spring Cloud
4.2 ZooKeeper
4.2.1 介绍
4.2.2 整体架构
4.2.3 接⼊Dubbo⽣态
4.3 Consul
4.3.1 介绍
4.3.2 整体架构
4.3.3 ⽣态对接
4.4 总结对⽐
微服务的注册与发现
我们前⾯在全景架构中对服务注册与发现做了⼤致的说明，本章我们着重详细说明微服务下注册与发现的这个能⼒。
微服务注册与发现类似于⽣活中的"电话通讯录"的概念，它记录了通讯录服务和电话的映射关系。在分布式架构中，服务会注册进去，当服务需要调⽤其它服务时，就这⾥到服务的地址，进⾏调⽤。步骤如下：
1、你先要把"好友某某"记录在通讯录中。
2、的时候通过通讯录中到"好友某某"，并拨通回电话。
3、当好友某某电话号码更新的时候，需要通知到你，并修改通讯录服务中的号码。
从这个过程中我们看到了⼀些特点：
1、把 "好友某某" 的电话号码写⼊通讯录中，统⼀在通讯录中维护，后续号码变更也是更新到通讯录中，这个过程就是服务注册的过程。
2、后续我们通过"好友某某"就可以定位到通讯录中的电话号码，并拨通电话，这个过程理解为服务发现的过程。
⽽我们微服务架构中的服务注册与发现结构如下图所⽰：
图⽚中是⼀个典型的微服务架构，这个结构中主要涉及到三⼤⾓⾊：
provider - 服务提供者
consumer - 服务消费者
register center - 注册中⼼
它们之间的关系⼤致如下：
1. 1、每个微服务在启动时，将⾃⼰的⽹络地址等信息（微服务的ServiceName、IP、Port、MetaData等）注册到注册中⼼，注册中⼼存储这些数据。
2. 2、服务消费者从注册中⼼查询服务提供者的地址，并通过该地址调⽤服务提供者的接⼝。
3. 3、各个微服务与注册中⼼使⽤⼀定机制（例如⼼跳）通信。如果注册中⼼与某微服务长时间⽆法通信，就会注销该实例。
优点如下：
1. 1、解耦：服务消费者跟服务提供者解耦，各⾃变化，不互相影响
2. 2、扩展：服务消费者和服务提供者增加和删除新的服务，对于双⽅没有任何影响
3. 3、中介者设计模式：⽤⼀个中介对象来封装⼀系列的对象交互，这是⼀种多对多关系的中介者模式。
从功能上拆开主要有三块：服务注册、服务发现，和注册中⼼。我们⼀个⼀个来看。
1、服务注册
如图中，为Register注册中⼼注册⼀个服务信息，会将服务的信息：ServiceName、IP、Port以及服务实例MetaData元数据信息写⼊到注册中⼼。当服务发⽣变化的时候，也可以更新到注册中⼼。
服务提供者（服务实例）的服务注册模型是⼀种简单、容易理解、流⾏的服务注册模型，其在多种技术⽣态中都有所体现：
1. 1、在K8S⽣态中，通过 K8S Service服务信息，和Pod的 endpoint（⽤来记录service对应的pod的访问地址）来进⾏注册。
2. 2、在Spring Cloud⽣态中，应⽤名对应服务Service，实例 IP + Port 对应 Instance实例。⽐较典型的就是A服务，后⾯对应有多个实例做负载均衡。
3. 3、在其他的注册组件中，⽐如 Eureka、Consul，服务模型也都是服务→服务实例。
可以认为服务实例是⼀个真正的实体的载体，服务是对这些相同能⼒或者相同功能服务实例的⼀个抽象。
2、服务发现
服务发现实际就是我们查询已经注册好的服务提供者，⽐如 p->p.queryService(serviceName)，通过服务名称查询某个服务是否存在，如果存在，
返回它的所有实例信息，即⼀组包含ip 、 port 、metadata元数据信息的endpoints信息。
这⼀组endpoints信息⼀般会被缓存在本地，如果注册中⼼挂掉，可保证段时间内依旧可⽤，这是去中⼼化的做法。对于单个 Service 后⾯有多个 Instance的情况（如上图），做 load balance。
服务发现的⽅式⼀般有两种：
1、拉取的⽅式：服务消费⽅（Consumer）主动向注册中⼼发起服务查询的请求。
2、推送的⽅式：服务订阅/通知变更（下发）：服务消费⽅（Consumer）主动向注册中⼼订阅某个服务，当注册中⼼中该服务信息发⽣变更时，注册中⼼主动通知消费者。
3、注册中⼼
注册中⼼提供的基本能⼒包括：提供服务注册、服务发现以及健康检查。
服务注册跟服务发现上⾯已经详细介绍了，健康检查指的是指注册中⼼能够感知到微服务实例的健康
状况，便于上游微服务实例及时发现下游微服务实例的健康状况。采取必备的访问措施，如避免访问不健康的实例。
主要的检查⽅式包括：
1. 1、服务Provider 进⾏ TTL 健康汇报（Time To Live，微服务Provider定期向注册中⼼汇报健康状态）。
2. 2、注册中⼼主动检查服务Provider接⼝。
综合我们前⾯的内容，可以总结下注册中⼼有如下⼏种能⼒：
1、⾼可⽤
这个主要体现在两个⽅⾯。⼀个⽅⾯是，注册中⼼本⾝作为基础设施层，具备⾼可⽤；第⼆种是就是前⾯我们说到的去中⼼化，极端情况下的故障，短时间内是不影响微服务应⽤的调⽤的
2、可视化操作
常⽤的注册中⼼，类似 Eureka、Consul 都有⽐较丰富的管理界⾯，对配置、服务注册、服务发现进⾏可视化管理。
3、⾼效运维
注册中⼼的⽂档丰富，对运维的⽀持⽐较好，并且对于服务的注册是动态感知获取的，⽅便动态扩容。
4、权限控制
数据是具有敏感性，⽆论是服务信息注册或服务是调⽤，需要具备权限控制能⼒，避免侵⼊或越权请求
5、服务注册推、拉能⼒
这个前⾯说过了，微服务应⽤程序（服务的Consumer），能够快速感知到服务实例的变化情况，使⽤拉取或者注册中⼼下发的⽅式进⾏处理。
4、现下的主流注册中⼼
4.1 Eureka
4.1.1 介绍
Eureka是Netflix OSS套件中关于服务注册和发现的解决⽅案。因为Spring Cloud 在它的微服务解决⽅案中对Eureka进⾏了集成，并作为优先推荐⽅案进⾏宣传，所以早期有⽤ Spring Cloud 来建设微服务系统的同学会⽐较熟悉。
⽬前⼤量公司的微服务系统中依旧使⽤Eureka作为注册中⼼，它的核⼼设计思想也被后续⼤量注册中⼼产品借鉴。但⽬前 Eureka 2.0已经停⽌维护，所以新的微服务架构设计中，不再建议使⽤。Spring Cloud Netflix主要分为两个部分：
1、Eureka Server：作为注册中⼼Server端，向微服务应⽤程序提供服务注册、发现、健康检查等能⼒。
2、Eureka Client：微服务应⽤程序Client端，⽤以和Eureka Server进⾏通信。
Eureka有⽐较友好的管理界⾯，如上图所⽰：
1、System Status：显⽰当前Eureka Server信息。
2、Instances Current registered with Eureka：在Eureka Server当前注册的数据，在Spring Cloud⽣态中，被注册的服务可以呗发现并罗列在这个地⽅。
3、General Info：基本信息，如cpu、内存、环境等。
4.1.2 整体架构
Eureka Server可以运⾏多个实例来构建集，解决单点问题，但不同于ZooKeeper的选举leader的过程，Eureka Server采⽤的是Peer to Peer对等通信。
所以他有如下特点：
1. 1、去中⼼化的架构：⽆master/slave区分，每⼀个Peer都是对等的。在这种架构中，节点通过彼此互相注册来提⾼可⽤性，每个节点需要添加⼀个或多个有效的serviceUrl指向其他节点。每个节点
都可被视为其他节点的副本。
2. 2、故障转移/故障恢复：如果某台Eureka Server宕机，Eureka Client的请求会⾃动切换到新的Eureka Server节点，当宕机的服务器重新恢复后，Eureka会再次将其纳⼊到服务器集管理之中。
3. 3、节点复制：当节点开始接受客户端请求时，所有的操作都会进⾏replicateToPeer（节点间复制）操作，将请求复制到其他Eureka Server当前所知的所有节点中。
同理，⼀个新的Eureka Server节点启动后，会⾸先尝试从邻近节点获取所有实例注册表信息，完成初始化。
4. 4、CAP模式：复制算法⾮强⼀致性算法，⽽是当有数据写⼊时，Eureka Server将数据同步给其他的节点，因此Eureka在CAP提系统（⼀致性、可⽤性、分区容错性）是典型的AP系统。
4.1.3 接⼊Spring Cloud
如上图所⽰：
1、Provider 服务提供者：服务向注册中⼼注册服务信息，即服务 -> 服务实例数据模型，同时定时向注册中⼼汇报健康检查，如果⼀定时间内（⼀般90s）没有进⾏⼼跳汇报，则会被注册中⼼剔除。所以这边注意，注册中⼼感知到应⽤下线并进⾏剔除这个过程可能⽐较长。
2、Consumer 服务消费者：服务向注册中⼼获取所需服务对应的服务实例信息。这边需要注意，Eureka不⽀持订阅，因此在Spring Cloud⽣态中，通过定时拉取⽅式从注册中⼼中获取所需的服务实例信息。
3、Remote Call 远程调⽤：Consumer从注册中⼼获取的Provider的实例信息，通过 Load Balance的策略，确定⼀个实际的实例，发起远程调⽤。
4.2 ZooKeeper
4.2.1 介绍
作为⼀个分布式的、开源的协调服务，ZooKeeper实现了⼀系列基础功能，包括简单易⽤的接⼝。
这些接⼝被⽤来实现服务的注册与发现功能。并实现⼀些⾼级功能，如数据同步、分布式锁、配置中⼼、集选举、命名服务等。
分布式和微服务的关系
在数据模型上，类似于传统的⽂件系统，节点类型分为：
1、持久节点：节点创建后，就⼀直存在，除⾮执⾏删除操作，主动删掉这个节点。
2、临时节点（注册中⼼场景下的主要实现机制）：临时节点的⽣命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会⾃动被清除掉。
在实际场景下，微服务启动的时候，会创建⼀个服务临时节点，等把服务停⽌，短时间后节点就没有了。
Zookeeper有如下特点：
1. 1、最终⼀致性：为客户端展⽰同⼀视图，这是zookeeper最重要的功能。
2. 2、可靠性：如果消息被到⼀台服务器接受，那么它将被所有的服务器接受。
3. 3、实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调⽤sync()接⼝。
4. 4、等待⽆关（wait-free）：慢的或者失效的client不⼲预快速的client的请求。
5. 5、原⼦性：更新只能成功或者失败，没有中间状态。
6. 6、顺序性：所有Server，同⼀消息发布顺序⼀致。
4.2.2 整体架构
上图是Zookeeper 的服务架构，他有如下流程：
1. 1、多个节点组成分布式架构，每个Server在内存中存储⼀份数据；
2. 2、通过选举产⽣leader，通过 Paxos(帕克索斯)强⼀致性算法进⾏保证，是典型的CP结构。
3. 3、Leader负责处理数据更新等操作（Zab协议）；
4.2.3 接⼊Dubbo⽣态
上图中的⾓⾊如下：
Provider：提供者，服务发布⽅
Consumer：消费者, 调⽤服务⽅
Container：Dubbo容器.依赖于Spring容器
Registry：注册中⼼，当Container启动时把所有可以提供的服务列表上Registry中进⾏注册，告诉Consumer提供了什么服务，以及服务⽅的位置
Monitor：
说明：ZooKeeper在注册中⼼⽅⾯对Dubbo⽣态⽀持的⽐较好。服务提供者Providerzai Container启动时主动向注册中⼼Registry ZooKeeper中注册信息。
服务消费者Consumer启动时向注册中⼼Registry ZooKeeper中订阅注册中⼼，当Provider的信息发⽣变化时，注册中⼼ZooKeeper会主动向Consumer进⾏推送通知变更。这边注意与Eureka的区别，这是主动推送通知，是注册中⼼下发的操作。
4.3 Consul
4.3.1 介绍
Consul是HashiCorp推出的⼀款软件，是⼀个Service Mesh解决⽅案，提供了功能丰富的控制⾯功能：
1、Service Discovery（服务发现）
2、Configuration（配置化）
3、Segmentation Functionality

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。