微服务架构 | 3. 注册中心与服务发现

2022-01-14 本文已影响0人多氯环己烷

前言

参考资料：
《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 与负载均衡的传统服务发现模型.png

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

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

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

1.4 服务发现架构

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

客户端负载均衡.png

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图.png

1.10 AP 架构和 CP 架构

AP 架构：
- 当网络分区出现后，为了保证可用性，系统 B 可以返回旧值，保证系统的可用性；
- 结论：违背了一致性 C 的要求，只满足可用性和分区容错，即 AP；
  
  AP 架构.png
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 服务发现实例模型.png

2. Eureka

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