微服务架构 | 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 服务发现架构

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

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.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 注册中心

---

最后

新人制作，如有错误，欢迎指出，感激不尽！ 欢迎关注公众号，会分享一些更日常的东西！ 如需转载，请标注出处！