关于服务:华为云专家原创-服务注册与发现如何满足服务治理

摘要：本文次要介绍了服务注册与发现的原理，以及罕用的几种服务注册与发现组件介绍比照。

在单体利用向微服务架构演进的过程中，本来的巨石型利用会依照业务需要被拆分成多个微服务，每个服务提供特定的性能，并可能依赖于其余的微服务。每个微服务实例都能够动静部署，服务实例之间的调用通过轻量级的近程调用形式（HTTP、音讯队列等）实现，它们之间通过事后定义好的接口进行拜访。

因为服务实例是动静部署，每个服务实例的地址和服务信息都可能动态变化，势必须要一个中心化的组件对各个服务实例的信息进行治理，该组件治理了各个部署好的服务实例元数据，包含不仅限于服务名、IP 地址、端口号、服务形容和服务状态等。

什么是服务注册与发现？

服务注册与发现次要蕴含两局部：服务注册与服务发现。服务注册是指服务实例启动时将本身信息注册到服务注册与发现核心，并在运行时通过心跳等形式向服务注册与发现核心汇报本身服务状态；服务发现是指服务实例向服务注册与发现核心获取其余服务实例信息，用于进行接下来的近程调用。接下来让咱们介绍服务注册与发现核心的职责和服务实例进行服务注册的根本流程，以及分布式系统中数据同步的基本原理 CAP。

服务注册与发现核心有什么性能？

在传统单体利用中，利用都是部署在固定的物理机器或者云平台上，他们之间的调用个别是通过固定在代码外部或者配置文件的服务地址和端口间接发动。因为利用数量较少，系统结构复杂度不高，开发人员和运维人员能够较为轻松地进行治理和配置。

随着利用架构向微服务架构迁徙，服务数量的减少和动静部署动静扩大的个性，使得服务地址和端口在运行时是随时可变的。对此，咱们须要一个额定的中心化组件对立治理动静部署的微服务利用的服务实例元数据，个别称它为服务注册与发现核心。服务注册与发现核心次要有以下的职责：

• 治理以后注册到服务注册与发现核心的微服务实例元数据信息，包含服务实例的 服务名、IP 地址、端口号、服务形容和服务状态等；
• 与注册到服务发现与注册核心的微服务实例维持心跳，定期检查注册表中的服务实例是否在线，并剔除有效服务实例信息；
• 提供服务发现能力，为服务调用方提供服务提供方的服务实例元数据。

通过服务发现与注册核心，能够很不便地管理系统中动态变化的服务实例信息。与此同时，它也可能成为零碎的瓶颈和故障点。因为服务之间的调用信息来自于服务注册与发现核心，当它不可用时，服务之间的调用可能无奈失常进行。因而服务发现与注册核心个别会集群化部署，提供高可用性和高稳定性。

分布式中的 CAP 实践

在实质上来讲，微服务利用属于分布式系统的一种落地实际，而分布式系统最大的难点是解决各个节点之间数据状态的一致性。即便是提倡无状态的 HTTP RESTful API 申请，在解决多服务实例状况下的批改数据状态申请，也是须要通过数据库或者分布式缓存等内部系统维护数据的一致性。CAP 原理是形容分布式系统下节点数据同步的根本定理。

CAP 原理由加州大学的 Eric Brewer 传授提出，别离指 Consistency (一致性)、Availablity (可用性)、Partition tolerance (分区容忍性)。Eric Brewer 认为，以上三个指标最多同时满足两个。

• Consistency，指数据一致性，示意一个零碎的数据信息 (包含备份数据) 在同一时刻都是统一的。在分布式系统下，同一份数据可能存在于多个不同的实例中，在数据强一致性的要求下，对其中一份数据的批改必须同步到它的所有备份中。在数据同步的任何时候，都须要保障所有对该份数据的申请将返回同样的状态。
• Availablity，指服务可用性，要求服务在承受到客户端申请后，都可能给出响应。服务可用性考量的是零碎的可用性，要求零碎在高并发状况下和局部节点宕机的状况下，零碎整体仍然可能响应客户端的申请。
• Partition tolerance，指分区容忍性。在分布式系统中，不同节点之间是通过网络进行通信。基于网络的不可靠性，位于不同网络分区的服务节点可能会通信失败，如果零碎可能容忍这种状况，阐明它是满足分区容忍性的。如果零碎不可能满足分区容忍性，那么将会限度分布式系统的扩展性，即服务节点的部署数量和地区都会受限，违反了分布式系统设计的初衷，所以一般来讲分布式系统都会满足分区容忍性。

在满足了分区容忍性的前提下，分布式系统并不能同时满足数据一致性和服务可用性。假如服务 A 当初有两个实例 A1 和 A2，它们之间的网络通信呈现了异样，基于分区容忍性，这并不会影响 A1 和 A2 独立的失常运行。如果此时客户端申请 A1，申请将数据 B 从 B1 状态批改为 B2，因为网络的不可用，数据 B 的批改并不能告诉到实例 A2。如果此时另一个客户端向 A2 申请数据 B，如果 A2 返回数据 B1，将满足服务可用性，但并不能满足数据一致性；如果 A2 须要期待 A1 的告诉之后才可能返回数据 B 的正确状态，尽管满足了数据一致性，但并不能响应客户端申请，违反了服务可用性的指标。

基于分布式系统的根本特质，P 是必须要满足，接下来须要思考满足 C 还是 A。在相似银行之类对金额数据要求强一致性的零碎中，要优先思考满足数据一致性；而相似公众网页之类的零碎，用户对网页版本的新旧不会有特地的要求，在这种场景下服务可用性高于数据一致性。

如何抉择服务注册与发现框架？

随着近几年微服务框架高速倒退，目前业界曾经开源出了大量优良的服务注册与发现组件，包含不仅限于 Consul、Etcd、Zookeeper、Eureka。它们之间各有千秋，在组件选型时能够依据本身业务的须要进行抉择和革新，接下来咱们次要对 Consul、Etcd、Zookeeper 作一些简略的介绍和比拟。

基于 Raft 算法、开箱即用的服务发现零碎 Consul

Consul 由 HashiCorp 开源，是反对多个平台的分布式高可用零碎。Consul 应用 Golang 语言实现，次要用于实现分布式系统的服务发现与配置，满足 AP 个性。Consul 是分布式、高可用和可横向扩大的，提供以下次要个性：

• 服务发现：能够应用 HTTP 或者 DNS 的形式将服务实例的元数据注册到 Consul，和通过 Consul 发现所依赖服务的元数据列表。
• 查看查看：Consul 提供定时的健康检查机制，定时申请注册到 Consul 中的服务实例提供的健康检查接口，将异样返回的服务实例标记为不衰弱。
• Key/Value：Consul 提供了 Key/Value 存储性能，能够通过简略的 HTTP 接口进行应用。
• 多数据中心：Consul 应用 Raft 算法来保证数据一致性，提供了开箱即用的多数据中心性能。

服务实例与 Consul 的交互如下图所示：

Consul 与服务实例的交互过程

通过 Consul 实现服务注册与发现核心的调用过程如下：

1. Producer 在启动之初会通过 /register 接口将本人的服务实例元数据注册到 Consul 中；
2. Consul 通过 Producer 提供的健康检查接口 /health 定时查看 Producer 的服务实例状态；
3. Consumer 申请 Consul 的接口获取 Producer 服务的元数据；
4. Consumer 从 Consul 中返回的 Producer 服务实例元数据列表中抉择适合的服务实例，应用其配置的 IP 和端口信息发动服务调用，如图 7-1 中 Consumer 调用 Producer 的 /service 接口。

Consul 是一个高可用的分布式系统，反对多数据中心部署。一个 Consul 集群由多个部署和运行了 Consul Agent 的节点组成。Consul 集群中存在两种角色，Server 和 Client。每个 Consul Agent 负责对本地的服务进行监控查看，并将查问申请转发到 Server 中进行解决。Consul 简略的架构图如下图所示：

Consul 架构图

从上图可知，Consul 次要由 Consul Client 和 Consul Server 组成，且 Consul 应用 Gossip 协定来治理成员和播送音讯到集群。

Consul 作为一个开箱即用、高可用分布式服务发现和配置零碎，能够很不便地为微服务的服务治理提供强有力的反对。在前面的课时中，咱们将实现一个 Consul 的客户端，将咱们本身的 Web 服务注册到 Consul 中，以供其余服务或者网关调用。

基于 HTTP 协定的分布式 key/Value 存储系统 Etcd

Etcd 是由 CoreOS 开源，采纳 Golang 语言编写的分布式、高可用的 Key/Value 存储系统，次要用于服务发现和配置共享。Ectd 的经典利用场景有：

• Key/Value 存储：Etcd 反对 HTTP RESTful API，提供强一致性、高可用的数据存储能力。
• 服务发现：通过在 Etcd 中注册某个服务的目录，服务实例连贯 Etcd 并在目录下公布对应 IP 和 Port 以供调用方应用，能够无效实现服务注册与发现的性能；
• 音讯公布与订阅：通过 Etcd 的 Watcher 机制，能够使订阅者订阅他们关怀的目录。当音讯发布者批改被监控的目录内容时，能够将变动实时告诉给订阅者。

Etcd 的集群的根本架构图

绝对于其余的组件来讲，Etcd 更为轻量级，部署简略，反对 HTTP 接口。它能够为服务发现提供一个稳固高可用的音讯注册仓库，为微服务协同工作提供了无力的反对。

重量级一致性服务零碎 Zookeeper

Zookeeper 作为 Hadoop 和 Hbase 的重要组件，是一个开源的分布式应用协调服务，目前由 Apache 基金会保护，采纳 Java 语言开发。Zookeeper 致力于为分布式应用提供一致性服务，它的设计指标是将分布式系统中那些简单且容易出错的服务封装为简略高效的接口以供开发人员应用。

Zookeeper 底层只提供了两个性能，治理客户端提交的数据和为客户端程序提供数据节点的监听服务。它是一个典型的分布式数据一致性解决方案，基于 ZooKeeper 能够实现服务发现与注册、音讯公布与订阅、分布式协调与告诉、分布式锁、Master 选举、集群治理和分布式队列等诸多性能。

Zookeeper 集群中存在三种角色，别离为 Leader、Follower 和 Observer，架构图如图所示：

Zookeeper 架构图

Zookeeper 通过 ZAB 协定来保障其数据一致性。ZAB 不是一种通用的分布式一致性算法，它是在 Paxos 算法的根底上，为 Zookeeper 特地设计的解体可复原的原子音讯播送协定。ZAB 协定次要蕴含两种基本模式，解体复原和音讯播送：

• 解体恢复模式：在服务启动或者 Leader 服务器解体时，ZAB 协定就会进入解体恢复模式，在所有的 Follower 中选举出 Leader。当选举了新的 Leader 后，集群中有半数与新的 Leader 实现状态同步后就会退出恢复模式，进入到音讯播送模式。
• 音讯播送模式：ZAB 协定音讯播送过程应用的是一个原子播送协定，相似于一个二阶段提交，然而又有所不同，并非所有 Follower 节点都返回 Ack 才进行一致性事务实现，而是只须要半数以上即可提交实现一个事务播送。

Zookeeper 为分布式系统提供协调服务，可能无效地反对微服务架构的服务注册和发现机制。同时 Zookeeper 中提供的其余数据一致性解决方案，可能无力撑持微服务中分布式业务的开发。

服务注册与发现组件的比照

以上介绍的三种服务注册与发现组件在业界都曾经有了宽泛的利用，在很多大公司的我的项目中都能看到它们的身影，比方 Zookeeper 在 Hadoop 体系中施展了极其重要的分布式协调作用。上面将从个性方面比拟他们的异同：

从软件的生态登程，Consul 是以服务发现和配置作为次要性能指标，附带提供了 Key/Value 存储，绝对于 Etcd 和 Zookeeper 来讲业务范围较小，更适宜于服务注册与发现。Etcd 和 Zookeeper 属于通用的分布式一致性存储系统，被利用于分布式系统的协调工作中，应用范畴形象，具体的业务场景须要开发人员自主实现，如服务发现、分布式锁等。Zookeeper 具备宽广的周边生态，在分布式系统中失去了宽泛的应用；而 Etcd 以简略易用的个性吸引了大量开发人员，在目前炽热的 Kubernetes 中也有利用。仅从服务注册与发现组件的需要来看，抉择 Consul 作为服务注册与发现核心可能获得更好的成果；如果零碎存在其余分布式一致性合作需要，抉择 Etcd 和 Zookeeper 反而可能提供更多的服务反对。

小结

本文次要介绍了服务注册与发现的原理，以及罕用的几种服务注册与发现组件介绍比照。服务注册与发现在微服务架构中是各个微服务之间的协调者，因而把握服务注册与发现的基本原理，正确应用服务注册与发现组件是十分重要的一件事。在接下来的文章中，咱们将基于 Consul 实现 Go 微服务的服务注册与发现。

本文分享自华为云社区《【华为云专家原创】服务注册与发现如何满足服务治理？》，原文作者：aoho。

点击关注，第一工夫理解华为云陈腐技术~