(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 与负载均衡器发现服务的弊端
- 这种模型适用于在企业数据中心内部运行的应用程序，以及在一组静态服务器上运行少量服务的情况；
- 对基于云的微服务应用程序不使用，理由如下：
- 单点故障：如果负载均衡器出现故障，那么依赖它的每个应用程序都会出现故障；
- 有限的水平可伸缩性：大多数商业负载均衡器使用热插拔模型实现冗余，只能使用单个服务器来处理负载，跨多个服务器水平伸缩负载均衡基础设施的能力有限；
- 静态管理：大多数传统的负载均衡器不是为快速注册和注销服务设计的。它们使用集中式数据库来存储规则的路由；
- 复杂：需要手动定义和部署服务的映射规则；
1.3 云中的服务发现应该具备的特点
- 高可用：如果一个节点变得不可用，集群中的其他节点应该能够接管工作；
- 点对点：每个节点共享服务实例的状态；
- 负载均衡：在所有服务实例之间动态地对请求进行负载均衡；
- 有弹性：务发现的客户端应该在本地缓存服务信息；
- 容错：需要检测出服务实例什么时候是不健康的，并从可以接收客户端请求的可用服务列表中移除该实例；
1.4 服务发现架构
- 服务发现需要关注的四个概念：
- 服务注册；
- 服务地址的客户端查找；
- 信息共享；
- 健康监测；
微服务架构 | 3. 注册中心与服务发现 #yyds干货盘点#前言1. 服务发现基础知识2. Eureka3. Nacos4. Zookeeper5. Consul最后
- 这种方法很脆弱，因为服务客户端完全依赖于服务发现引擎来查找和调用服务；
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；
微服务架构 | 3. 注册中心与服务发现 #yyds干货盘点#前言1. 服务发现基础知识2. Eureka3. Nacos4. Zookeeper5. Consul最后
- 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.1 Netflix Eureka 注册中心
3. Nacos
Nacos 致力于解决微服务中的统一配置、服务注册与发现等问题。它提供了一组简单易用的特性集，帮助开发者快速实现动态服务发现、服务配置、服务元数据及流量管理；
- 点击跳转：微服务架构 | 3.2 Alibaba Nacos 注册中心
- 点击跳转：微服务架构 | *3.5 Nacos 服务注册与发现的源码分析
4. Zookeeper
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等；
- 点击跳转：微服务架构 | 3.3 Apache Zookeeper 注册中心
5. Consul
Consul 是一套开源的分布式服务发现和配置管理系统，由 HashiCorp 公司用 Go 语言开发。它提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网格，总之 Consul 提供了一种完整的服务网格解决方案；
- 点击跳转：微服务架构 | 3.4 HashiCorp Consul 注册中心
最后
::: hljs-center
新人制作，如有错误，欢迎指出，感激不尽！
:::
::: hljs-center
欢迎关注公众号，会分享一些更日常的东西！
:::
::: hljs-center
如需转载，请标注出处！
:::