架构师零基础到精通——注册中心

Posted 2023-04-01 架构师Cool

博客昵称：架构师Cool
最喜欢的座右铭：一以贯之的努力，不得懈怠的人生。
作者简介：一名Coder，软件设计师/鸿蒙高级工程师认证，在备战高级架构师/系统分析师，欢迎关注小弟！
博主小留言：哈喽！各位CSDN的uu们，我是你的小弟Cool，希望我的文章可以给您带来一定的帮助
百万笔记知识库， 所有基础的笔记都在这里面啦，点击左边蓝字即可获取！助力每一位未来架构师！
欢迎大家在评论区唠嗑指正，觉得好的话别忘了一键三连哦！😘

注册中心/模块

• 注册中心
• • 1、服务注册
  • • 1-1、客户端注册
    • 1-2、代理注册
  • 2、服务发现
  • • 2-1、客户端发现
    • 2-2、代理发现
  • 3、心跳机制
  • • 3-1、被动检测
    • 3-2、主动检测
  • 4、Dubbo注册中心
  • • 4-1、核心功能
    • 4-2、生产特性
  • 5、业界方案
  • • 5-1、Zookeeper
    • 5-2、Consul
    • 5-3、Nacos

注册中心

注册中心主要是为分布式服务的发布与发现提供一层统一标准化的基础组件，便于使用者直接操作简单接口即可实现服务发布与发现功能。

1、服务注册

服务注册有两种形式：客户端注册和代理注册。

1-1、客户端注册

客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己。

这种方式缺点是注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。

1-2、代理注册

代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作。

这种方式的缺点是多引用了一个代理服务，并且代理服务要保持高可用状态。

2、服务发现

服务发现也分为客户端发现和代理发现。

2-1、客户端发现

客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用。

这种方式非常直接，客户端可以控制负载均衡算法。但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。

2-2、代理发现

代理发现是指新增一个路由服务负责服务发现获取可用的实例列表，服务消费者如果需要调用服务A的一个实例可以直接将请求发往路由服务，路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可，如果发现实例不可用，路由服务还可以自行重试，服务消费者完全不用感知。

3、心跳机制

如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。如何实现摘机？业界比较常用的方式是通过心跳检测的方式实现，心跳检测有主动和被动两种方式。

3-1、被动检测

被动检测是指服务主动向注册中心发送心跳消息，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。

上图中服务A的实例2已经宕机不能主动给注册中心发送心跳消息，15秒之后注册就会将实例2移除掉。

3-2、主动检测

主动检测是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例。

4、Dubbo注册中心

4-1、核心功能

针对使用者，主要关注注册中心的以下五个核心接口，通过以下五个核心接口，可以实现服务的动态发布、动态发现以及优雅下线等操作：

• 注册服务：将服务提供者的URL暴露至注册中心
• 注销服务：从注册中心将服务提供者的地址进行摘除
• 订阅服务：将从注册中心订阅需要消费的URL至本地,当注册中心的服务清单发展变化时,自动通知订阅者
• 退订服务：取消向注册中心订阅的服务监听者
• 查找服务：向注册中心查找指定的服务清单列表

4-2、生产特性

Zookeeper会有一些未知的问题出现，所以需要生产特性来应对各种可能出现的问题，从而提升产品的质量。该类功能针对使用者一般情况是没办法直接感受到，但其发挥的作用就是保障产品的高质量服务：

• 自动重连：与Zookeeper或Redis的连接断开后，支持自动重新连接
• 自动切换：与Zookeeper或Redis的连接失败后，支持自动切换
• 自动清理：Zookeeper或Redis中的数据过期后，支持自动清理（超时自动摘除）
• 自动恢复：与Zookeeper或Redis自动重连成功后，支持自动恢复（即再次发起注册、订阅或监听动作）
• 自动重试：失败自动重试（注册、注销、订阅、退订、监听和取消监听失败，无限重试至成功为止）
• 自动缓存：Client订阅的服务清单会自动离线缓存至JVM本地的文件（变更通知时更新）

5、业界方案

下面结合各个维度对比一下各组件：

方案	优点	缺点	访问协议	一致性算法
Zookeeper	1.功能强大，不仅仅只是服务发现；2.提供watcher机制可以实时获取服务提供者的状态；3.广泛使用，dubbo等微服务框架已支持	1.没有健康检查；2.需要在服务中引入sdk，集成复杂度高；3.不支持多数据中心	TCP	Paxos（CP）
Consul	1.开箱即用，方便集成；2.带健康检查；3.支持多数据中心；4.提供web管理界面	不能实时获取服务变换通知	HTTP/DNS	Raft（CP）
Nacos	1.开箱即用，适用于dubbo，spring cloud等；2.AP模型，数据最终一致性；3.注册中心，配置中心二合一(二合一也不一定是优点)，提供控制台管理；4.纯国产，各种有中文文档，久经双十一考验	刚刚开源不久，社区热度不够，依然存在bug	HTTP/DNS	CP+AP
Eureka			HTTP	AP

5-1、Zookeeper

5-2、Consul

Consul是HashiCorp公司推出的开源工，使用Go语言开发，具有开箱即可部署方便的特点。Consul是分布式的、高可用的、 可横向扩展的用于实现分布式系统的服务发现与配置。

Consul有哪些优势？

• 服务注册发现：Consul提供了通过DNS或者restful接口的方式来注册服务和发现服务。服务可根据实际情况自行选择
• 健康检查：Consul的Client可以提供任意数量的健康检查，既可以与给定的服务相关联，也可以与本地节点相关联
• 多数据中心：Consul支持多数据中心，这意味着用户不需要担心Consul自身的高可用性问题以及多数据中心带来的扩展接入等问题

Consul的架构图

Consul 实现多数据中心依赖于gossip protocol协议。这样做的目的：

• 不需要使用服务器的地址来配置客户端；服务发现是自动完成的
• 健康检查故障的工作不是放在服务器上，而是分布式的

Consul的使用场景

Consul的应用场景包括服务注册发现、服务隔离、服务配置等。

• 服务注册发现场景中consul作为注册中心，服务地址被注册到consul中以后，可以使用consul提供的dns、http接口查询，consul支持health check

• 服务隔离场景中consul支持以服务为单位设置访问策略，能同时支持经典的平台和新兴的平台，支持tls证书分发，service-to-service加密

• 服务配置场景中consul提供key-value数据存储功能，并且能将变动迅速地通知出去，借助Consul可以实现配置共享，需要读取配置的服务可以从Consul中读取到准确的配置信息

5-3、Nacos

Nacos 英文全称为 Dynamic Naming and Configuration Service，是一个由阿里巴巴团队使用 Java 语言开发的开源项目。

Nacos 是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台（参考自 Nacos 官网）。

Nacos 的命名是由 3 部分组成：

Nacos 作为服务注册中心经历了十年“双十一”的洪峰考验，具有简单易用、稳定可靠、性能卓越等优点，可以帮助用户更敏捷、容易地构建和管理微服务应用。

架构师零基础到精通——架构演进

博客昵称：架构师Cool
最喜欢的座右铭：一以贯之的努力，不得懈怠的人生。
作者简介：一名Coder，软件设计师/鸿蒙高级工程师认证，在备战高级架构师/系统分析师，欢迎关注小弟！
博主小留言：哈喽！各位CSDN的uu们，我是你的小弟Cool，希望我的文章可以给您带来一定的帮助
百万笔记知识库， 所有基础的笔记都在这里面啦，点击左边蓝字即可获取！助力每一位未来架构师！
欢迎大家在评论区唠嗑指正，觉得好的话别忘了一键三连哦！😘

架构演进

• • 软件架构模式
  • • 1、分层模式
    • 2、客户端-服务器模式
    • 3、主从设备模式
    • 4、管道-过滤器模式
    • 5、代理模式
    • 6、点对点模式
    • 7、事件总线模式
    • 8、模型-视图-控制器模式
    • 9、黑板模式
    • 10、解释器模式

软件架构模式

有没有想过要设计多大的企业规模系统？在主要的软件开发开始之前，我们必须选择一个合适的体系结构，它将为我们提供所需的功能和质量属性。因此，在将它们应用到我们的设计之前，我们应该了解不同的体系结构。

架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围。

1、分层模式

这种模式也称为多层体系架构模式。它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。每个层都为下一个提供更高层次服务。

一般信息系统中最常见的是如下所列的4层。

• 表示层(也称为UI层)
• 应用层(也称为服务层)
• 业务逻辑层(也称为领域层)
• 数据访问层(也称为持久化层)

使用场景：

• 一般的桌面应用程序
• 电子商务Web应用程序
  

2、客户端-服务器模式

这种模式由两部分组成：一个服务器和多个客户端。服务器组件将为多个客户端组件提供服务。客户端从服务器请求服务，服务器为这些客户端提供相关服务。此外，服务器持续侦听客户机请求。

使用场景：

• 电子邮件，文件共享和银行等在线应用程序

3、主从设备模式

这种模式由两方组成;主设备和从设备。主设备组件在相同的从设备组件中分配工作，并计算最终结果，这些结果是由从设备返回的结果。

使用场景：

• 在数据库复制中，主数据库被认为是权威的来源，并且要与之同步
• 在计算机系统中与总线连接的外围设备(主和从驱动器)

4、管道-过滤器模式

此模式可用于构造生成和处理数据流的系统。每个处理步骤都封装在一个过滤器组件内。要处理的数据是通过管道传递的。这些管道可以用于缓冲或用于同步。

使用场景：

• 编译器。连续的过滤器执行词法分析、解析、语义分析和代码生成
• 生物信息学的工作流

5、代理模式

此模式用于构造具有解耦组件的分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责组件之间的通信协调。

服务器将其功能(服务和特征)发布给代理。客户端从代理请求服务，然后代理将客户端重定向到其注册中心的适当服务。

使用场景：

• 消息代理软件，如Apache ActiveMQ，Apache Kafka，RabbitMQ和JBoss Messaging

6、点对点模式

在这种模式中，单个组件被称为对等点。对等点可以作为客户端，从其他对等点请求服务，作为服务器，为其他对等点提供服务。对等点可以充当客户端或服务器或两者的角色，并且可以随时间动态地更改其角色。

使用场景：

• 像Gnutella和G2这样的文件共享网络
• 多媒体协议，如P2PTV和PDTP
• 像Spotify这样的专有多媒体应用程序
  

7、事件总线模式

这种模式主要是处理事件，包括4个主要组件：事件源、事件监听器、通道和事件总线。消息源将消息发布到事件总线上的特定通道上。侦听器订阅特定的通道。侦听器会被通知消息，这些消息被发布到它们之前订阅的一个通道上。

使用场景：

• 安卓开发
• 通知服务

8、模型-视图-控制器模式

这种模式，也称为MVC模式，把一个交互式应用程序划分为3个部分，

• 模型：包含核心功能和数据
• 视图：将信息显示给用户(可以定义多个视图)
• 控制器：处理用户输入的信息

这样做是为了将信息的内部表示与信息的呈现方式分离开来，并接受用户的请求。它分离了组件，并允许有效的代码重用。

使用场景：

• 在主要编程语言中互联网应用程序的体系架构
• 像Django和Rails这样的Web框架

9、黑板模式

这种模式对于没有确定解决方案策略的问题是有用的。黑板模式由3个主要组成部分组成。

• 黑板——包含来自解决方案空间的对象的结构化全局内存
• 知识源——专门的模块和它们自己的表示
• 控制组件——选择、配置和执行模块

所有的组件都可以访问黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上查找特定类型的数据，并通过与现有知识源的模式匹配来查找这些数据。

使用场景：

• 语音识别
• 车辆识别和跟踪
• 蛋白质结构识别
• 声纳信号的解释

10、解释器模式

这个模式用于设计一个解释用专用语言编写的程序的组件。它主要指定如何评估程序的行数，即以特定的语言编写的句子或表达式。其基本思想是为每种语言的符号都有一个分类。

使用场景：

• 数据库查询语言，比如SQL
• 用于描述通信协议的语言