01.【微服务架构】服务注册与发现:AP和CP,你选哪个?-- 服务注册与发现模型

简介: 【5月更文挑战第1天】本文探讨了服务注册与发现的关键作用,在微服务架构中,这一概念常出现在面试中。文章深入讲解基础模型,包括服务端注册、心跳维持、客户端缓存及服务端下线流程,并强调了高可用性的重要性,涉及服务端崩溃检测、客户端容错和注册中心选型。通过分析客户端、注册中心和服务端之间的交互,提出如何应对潜在故障的策略,以构建稳定的微服务架构。

服务注册与发现在微服务架构中处于一个非常核心的地位,也是面试中的常见问题。不过因为微服务架构大行其道,现在我们多少都能回答出来一些服务注册与发现的内容,也因此不容易在面试中刷出亮点,拉开和其他面试者的差距。

本文将深入剖析服务注册与发现,学习服务注册与发现的基本模型,然后在服务端崩溃检测、客户端容错和注册中心选型三个角度找到高可用微服务架构的亮点。

前置知识

为什么会需要服务注册与发现呢?

设想这样一个场景,你的服务部署在不同的机房、不同的机器上,监听不同的端口。现在你的客户端收到了一个请求,要发送给服务端,那么你的客户端怎么知道哪些服务端能够处理这个请求呢?
2024-05-25-15-27-15-image.png

基本的服务注册与发现模型如下所示:


2024-05-25-15-28-00-image.png

图里的步骤如下:

  1. 服务端启动的时候,需要往注册中心里注册自身的信息,主要是定位信息。

  2. 注册成功之后,注册中心和服务端要保持心跳。

  3. 客户端第一个发起对某个服务的调用之前,要找注册中心获得所有可用服务节点列表,随后客户端会在本地缓存每个服务对应的可用节点列表。

  4. 客户端和注册中心要保持心跳和数据同步,后续服务端有任何变动,注册中心都会通知客户端,客户端会更新本地的可用节点列表

  5. 客户端发送请求

  6. 服务端返回响应

上面的步骤你都可以看作是一个正向的步骤,而对应的反向步骤则是指服务端下线的过程。

服务端下线的过程可以总结为四步:

  1. 服务端通知注册中心自己准备下线了

  2. 注册中心通知客户端某个服务端下线了

  3. 客户端收到通知之后,新来的请求就不会给服务端发过去

  4. 服务端等待一段时间之后,暂停服务并下线
    2024-05-25-16-02-34-image.png

需要注意的是,服务端必须等待一段时间才能下线。因为从它通知注册中心自己要下线,到客户端收到通知,是有一段时间延时的,这段延时就是服务端要等待的最小时间。

把整个模型看作是三角形,三个顶点分别是客户端、注册中心和服务端。三角形的三条边分别是客户端-注册中心,注册中心-服务端,客户端-服务端。而后面我们讨论的高可用方案,无论是思考三角形的任何一个顶点,或者任何一条边出问题了怎么办。
2024-05-25-16-08-35-image.png

目录
相关文章
|
7月前
|
运维 负载均衡 微服务
|
8月前
|
机器学习/深度学习 人工智能 监控
大型动作模型LAM:让企业重复任务实现80%效率提升的AI技术架构与实现方案
大型动作模型(LAMs)作为人工智能新架构,融合神经网络与符号逻辑,实现企业重复任务的自动化处理。通过神经符号集成、动作执行管道、模式学习、任务分解等核心技术,系统可高效解析用户意图并执行复杂操作,显著提升企业运营效率并降低人工成本。其自适应学习能力与上下文感知机制,使自动化流程更智能、灵活,为企业数字化转型提供坚实支撑。
550 0
大型动作模型LAM:让企业重复任务实现80%效率提升的AI技术架构与实现方案
|
9月前
|
存储 BI Shell
Doris基础-架构、数据模型、数据划分
Apache Doris 是一款高性能、实时分析型数据库,基于MPP架构,支持高并发查询与复杂分析。其前身是百度的Palo项目,现为Apache顶级项目。Doris适用于报表分析、数据仓库构建、日志检索等场景,具备存算一体与存算分离两种架构,灵活适应不同业务需求。它提供主键、明细和聚合三种数据模型,便于高效处理更新、存储与统计汇总操作,广泛应用于大数据分析领域。
959 2
|
9月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
1004 0
|
11月前
|
人工智能 负载均衡 API
长连接网关技术专题(十二):大模型时代多模型AI网关的架构设计与实现
随着 AI 技术快速发展,业务对 AI 能力的渴求日益增长。当 AI 服务面对处理大规模请求和高并发流量时,AI 网关从中扮演着至关重要的角色。AI 服务通常涉及大量的计算任务和设备资源占用,此时需要一个 AI 网关负责协调这些请求来确保系统的稳定性与高效性。因此,与传统微服务架构类似,我们将相关 API 管理的功能(如流量控制、用户鉴权、配额计费、负载均衡、API 路由等)集中放置在 AI 网关层,可以降低系统整体复杂度并提升可维护性。 本文要分享的是B站在大模型时代基于多模型AI的网关架构设计和实践总结,希望能带给你启发。
942 4
|
11月前
|
人工智能 缓存 自然语言处理
Bolt DIY架构揭秘:从模型初始化到响应生成的技术之旅
在使用Bolt DIY或类似的AI对话应用时,你是否曾好奇过从输入提示词到获得回答的整个过程是如何运作的?当你点击发送按钮那一刻,背后究竟发生了什么?本文将揭开这一过程的神秘面纱,深入浅出地解析AI对话系统的核心技术架构。
425 5
|
6月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
7月前
|
数据采集 机器学习/深度学习 搜索推荐
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
MIT与丰田研究院研究发现,扩散模型的“局部性”并非源于网络架构的精巧设计,而是自然图像统计规律的产物。通过线性模型仅学习像素相关性,即可复现U-Net般的局部敏感模式,揭示数据本身蕴含生成“魔法”。
313 3
MIT新论文:数据即上限,扩散模型的关键能力来自图像统计规律,而非复杂架构
|
6月前
|
机器学习/深度学习 存储 缓存
115_LLM基础模型架构设计:从Transformer到稀疏注意力
大型语言模型(LLM)的架构设计是其性能的核心决定因素。从2017年Transformer架构的提出,到如今的稀疏注意力和混合专家模型,LLM架构经历了快速的演进。本文将全面探讨LLM基础架构的设计原理,深入分析Transformer的核心机制,详细介绍稀疏注意力、MoE等创新架构,并展望未来架构发展方向。通过数学推导和实践案例,为构建高效、强大的LLM提供全面指导。
984 0