前言
参考资料：
《Spring Microservices in Action》
《Spring Cloud Alibaba 微服务原理与实战》
《B站 尚硅谷 SpringCloud 框架开发教程 周阳》
注册中心用来集中管理微服务，实现服务的注册，发现，检查等功能；
1. 服务发现基础知识
1.1 注册中心与服务发现的联系
- 注册中心是用来集中管理微服务，实现服务的注册，发现，检查等功能；
- 服务 A 与服务 B 注册进注册中心 C，形成服务注册表（表里登记了服务 A 和服务 B 的地址等相关信息）。当 A 服务想要访问 B 服务时，可以通过注册中心 C 的服务发现机制，获取服务注册表进而找到服务 B；
1.2 使用 DNS 与负载均衡器发现服务的弊端
- 这种模型适用于在企业数据中心内部运行的应用程序，以及在一组静态服务器上运行少量服务的情况；
- 对基于云的微服务应用程序不使用，理由如下：
-
单点故障：如果负载均衡器出现故障，那么依赖它的每个应用程序都会出现故障；
-
有限的水平可伸缩性：大多数商业负载均衡器使用热插拔模型实现冗余，只能使用单个服务器来处理负载，跨多个服务器水平伸缩负载均衡基础设施的能力有限；
-
静态管理：大多数传统的负载均衡器不是为快速注册和注销服务设计的。它们使用集中式数据库来存储规则的路由；
-
复杂：需要手动定义和部署服务的映射规则；
1.3 云中的服务发现应该具备的特点
-
高可用：如果一个节点变得不可用，集群中的其他节点应该能够接管工作；
-
点对点：每个节点共享服务实例的状态；
-
负载均衡：在所有服务实例之间动态地对请求进行负载均衡；
-
有弹性：务发现的客户端应该在本地缓存服务信息；
-
容错：需要检测出服务实例什么时候是不健康的，并从可以接收客户端请求的可用服务列表中移除该实例；
1.4 服务发现架构
- 服务发现需要关注的四个概念：
- 服务注册；
- 服务地址的客户端查找；
- 信息共享；
- 健康监测；
- 这种方法很脆弱，因为服务客户端完全依赖于服务发现引擎来查找和调用服务；
1.5 服务治理的概念
- 在传统的 RPC 远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务于服务之间依赖关系；
- 可以实现：服务调用、负载均衡、容错等，实现服务发现与注册；
1.6 服务注册的概念
- 在服务注册与发现中，有一个注册中心；
- 当服务器启动的时候，会把当前自己服务器的信息。如：服务地址通讯地址等以别名方式注册到注册中心上；
- 另一方（消费者|服务提供者），以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地 RPC 调用 ；
1.7 RPC 远程调用框架核心设计思想
- 在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系（服务治理概念）；
- 在任何RPC 远程框架中，都会有一个注册中心，用于存放服务地址相关信息（接口地址）；
1.8 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图：
1.10 AP 架构和 CP 架构
-
AP 架构：
- 当网络分区出现后，为了保证可用性，系统 B 可以返回旧值，保证系统的可用性；
- 结论：违背了一致性 C 的要求，只满足可用性和分区容错，即 AP；
-
CP 架构：
- 当网络分区出现后，为了保证一致性，就必须拒接请求，否则无法保证一致性；
- 结论：违背了可用性 A 的要求，只满足一致性和分区容错，即 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 集成 |
/ |
支持 |
/ |
支持 |
支持 |
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 提供了一种完整的服务网格解决方案；
最后
新人制作，如有错误，欢迎指出，感激不尽！
欢迎关注公众号，会分享一些更日常的东西！
如需转载，请标注出处！
