@[TOC](3. 注册中心与服务发现)


前言

参考资料
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》

注册中心用来集中管理微服务,实现服务的注册,发现,检查等功能;


1. 服务发现基础知识

1.1 注册中心与服务发现的联系

  • 注册中心是用来集中管理微服务,实现服务的注册,发现,检查等功能;
  • 服务 A 与服务 B 注册进注册中心 C,形成服务注册表(表里登记了服务 A 和服务 B 的地址等相关信息)。当 A 服务想要访问 B 服务时,可以通过注册中心 C 的服务发现机制,获取服务注册表进而找到服务 B;

1.2 使用 DNS 与负载均衡器发现服务的弊端

基于 DNS 与负载均衡的传统服务发现模型

  • 这种模型适用于在企业数据中心内部运行的应用程序,以及在一组静态服务器上运行少量服务的情况;
  • 对基于云的微服务应用程序不使用,理由如下:
    • 单点故障:如果负载均衡器出现故障,那么依赖它的每个应用程序都会出现故障;
    • 有限的水平可伸缩性:大多数商业负载均衡器使用热插拔模型实现冗余,只能使用单个服务器来处理负载,跨多个服务器水平伸缩负载均衡基础设施的能力有限;
    • 静态管理:大多数传统的负载均衡器不是为快速注册和注销服务设计的。它们使用集中式数据库来存储规则的路由;
    • 复杂:需要手动定义和部署服务的映射规则;

1.3 云中的服务发现应该具备的特点

  • 高可用:如果一个节点变得不可用,集群中的其他节点应该能够接管工作;
  • 点对点:每个节点共享服务实例的状态;
  • 负载均衡:在所有服务实例之间动态地对请求进行负载均衡;
  • 有弹性:务发现的客户端应该在本地缓存服务信息;
  • 容错:需要检测出服务实例什么时候是不健康的,并从可以接收客户端请求的可用服务列表中移除该实例;

1.4 服务发现架构

  • 服务发现需要关注的四个概念:
    • 服务注册;
    • 服务地址的客户端查找;
    • 信息共享;
    • 健康监测;
      传统服务发现架构
  • 这种方法很脆弱,因为服务客户端完全依赖于服务发现引擎来查找和调用服务;

客户端负载均衡架构

1.5 服务治理的概念

  • 在传统的 RPC 远程调用框架中,管理每个服务与服务之间依赖关系比较复杂,管理比较复杂,所以需要使用服务治理,管理服务于服务之间依赖关系;
  • 可以实现:服务调用、负载均衡、容错等,实现服务发现与注册;

1.6 服务注册的概念

  • 在服务注册与发现中,有一个注册中心;
  • 当服务器启动的时候,会把当前自己服务器的信息。如:服务地址通讯地址等以别名方式注册到注册中心上;
  • 另一方(消费者|服务提供者),以该别名的方式去注册中心上获取到实际的服务通讯地址,然后再实现本地 RPC 调用 ;

1.7 RPC 远程调用框架核心设计思想

  • 在于注册中心,因为使用注册中心管理每个服务与服务之间的一个依赖关系(服务治理概念);
  • 在任何RPC 远程框架中,都会有一个注册中心,用于存放服务地址相关信息(接口地址);

1.8 Eureka 与 Dubbo 的系统架构对比图

Eureka 与 Dubbo 的系统架构对比图

1.9 注册中心的 CAP 理论

  • CAP 含义:
    • C:Consistency 强一致性:注册一个服务,集群下多节点必须全部注册成功后才能进行访问和使用;master节点挂掉了需要等待重新选举成功后才能使用,选举期间服务不可用; (所有节点在同一时间具有相同的服务);
    • A:Availability 可用性:注册一个服务,只要有一个节点注册成功就可以对外提供访问;master节点挂了也可以正常使用; (保证每个请求不管成功或者失败都有响应);
    • P:Partition tolerance 分区容错性:把服务注册到每个节点,增强容错机制 (系统中任意信息的丢失或失败不会影响系统的继续运作);
  • CAP 理论关注粒度是数据,而不是整体系统设计的策略;
  • CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求;因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类:
    • CA 原则:单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大;
    • CP 原则:满足一致性,分区容忍性的系统,通常性能不是特别高;
    • AP 原则:满足可用性,分区容忍性的系统,通常可能对一致性要求低一些;
  • 经典CAP图

经典CAP图

1.10 AP 架构和 CP 架构

  • AP 架构
    • 当网络分区出现后,为了保证可用性,系统 B 可以返回旧值,保证系统的可用性;
    • 结论:违背了一致性 C 的要求,只满足可用性和分区容错,即 AP;
      AP 架构
  • CP 架构
    • 当网络分区出现后,为了保证一致性,就必须拒接请求,否则无法保证一致性;
    • 结论:违背了可用性 A 的要求,只满足一致性和分区容错,即 CP;
      CP架构

1.10 目前几种流行的注册中心对比

  • 基础对比
名称 厂商 CAP 模型 控制台管理 对外暴露接口 社区活跃度
Eureka Netflix AP 支持 HTTP 低(2.x 版本闭源)
Nacos Alibaba AP+CP 可切换 支持 HTTP/DNS/UDP
Zookeeper Apache CP 不支持 TCP 客户端
Consul HashiCorp CP 支持 HTTP/DNS
  • 功能与支持性对比
比较项 Eureka Nacos Zookeeper Consul CoreDNS
健康检查 Client Beat TCP/HTTP/MySQL/Client Beat Client Beat TCP/HTTP/gRPC/CMD /
负载均衡 Ribbon 权重/DSL/metadata/CMDB / Fabio RR
雪崩保护 支持 支持 / / /
自动注销实例 支持 支持 支持 / /
监听支持 支持 支持 支持 支持 /
多数据中心 支持 支持 / 支持 /
跨注册中心 / 支持 / 支持 /
Spring Colud 集成 支持 支持 支持 支持 /
Dubbo 集成 / 支持 支持 支持 /
kubernates 集成 / 支持 / 支持 支持

Nacos 服务发现实例模型

2. Eureka

Eureka 是 Netflix 开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在 AWS 域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的;
Spring Cloud 将它集成在其子项目 spring-cloud-netflix 中,以实现 Spring Cloud 的服务发现功能;

3. Nacos

Nacos 致力于解决微服务中的统一配置、服务注册与发现等问题。它提供了一组简单易用的特性集,帮助开发者快速实现动态服务发现、服务配置、服务元数据及流量管理;

4. Zookeeper

ZooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务,是 Google 的 Chubby 一个开源的实现,是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等;

5. Consul

Consul 是一套开源的分布式服务发现和配置管理系统,由 HashiCorp 公司用 Go 语言开发。它提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能中的每一个都可以根据需要单独使用,也可以一起使用以构建全方位的服务网格,总之 Consul 提供了一种完整的服务网格解决方案;

  • 点击跳转:[微服务架构 | 3.4 HashiCorp Consul 注册中心]()

最后

::: hljs-center

新人制作,如有错误,欢迎指出,感激不尽!

:::

::: hljs-center

欢迎关注公众号,会分享一些更日常的东西!

:::

::: hljs-center

如需转载,请标注出处!

:::

::: hljs-center

公众号

:::