分布式系统应用之服务发现!

简介: 分布式系统应用之服务发现!

什么是服务发现?

服务 → ip:port list的查找表

为什么需要服务发现?

虚拟化,容器技术,云平台 --> ip 动态分配

微服务化 --> 应用拆分,相互调用增加

方案演进

硬编码:只适用稳定的服务方

dns: 缓存导致更新扩散有延迟,故障转移问题

dns + loadbalancer/VIP: 基础设置配置方案(mysql,redis)

服务发现做什么?

服务注册/注销

失败节点检测

服务列表查询

实现分类

发现

client-side discovery: client请求前从registry查询ip:port列表,选择一个发请求 (eureka)

server-side discovery: 加一个lb/router,做代理转发,从registry获取服务ip的逻辑放到代理层 (nginx,k8s)

注册

self-registration:服务方在启动跟停止时主动上报注册中心 (eureka, nacos)

third-party registration:第三方模块代替服务方向注册中心上报 (consul, nacos)

实现细节 - 关注点

client端查询:缓存及更新

server端查找表维护:注册信息同步及失败节点检测

服务发现实现案例

eureka

client端:

所有查询走本地缓存

两个定时任务

  • 心跳:默认30s一次,服务续期
  • 缓存刷新:第一次全量,后面拉delta,即全部app的hash,发生变化触发全量刷新

server端:

客户端查询&注册表维护:多级缓存,读写分离,内层实时写,外层只读存储,30s更新一次

集群成员信息同步:定时任务,从已知节点同步

集群间数据同步:所有注册,下线,心跳,淘汰请求走异步队列同步peer node

失败检测:默认超3个周期无心跳,进入淘汰队列

  • 自我保护机制:如果一次清理超过15%,停止,保留当前全部数据直到恢复或人为干预,避免网络抖动触发大量服务下线

保证可用性,不保证一致性,server间数据同步可能延迟

consul

两种agent模式:

server → 负责维护注册表 & rpc响应

client → 转发请求 & 心跳检查

client端缓存:

agent支持参数指定最大过期时间

agent block query数据变更,client查询永远走缓存,超过3天不请求,不再监听

状态同步:

一个dc内client与server是一个集群,可以相互发现与广播信息,client不一定要配置server信息

server端,dc间wan gossip,dc内server之间raft保证一致性

client端参与lan gossip,广播成员以及服务状态,优先udp,重试几次降级到tcp

所有rpc请求均转发到对应dc内的leader处理

跨dc请求,由请求发起方的dc leader转发到目标dc的leader (dc间不同步数据)

server数据默认不做持久化

保证一致性,牺牲写性能

读一致性级别

  • default: leader leasing期限内提供读
  • consistent:leader每次rpc都跟folowler确认,有延迟
  • stale:任意时刻,任何节点都能提供读

失败检测:

agent主动进行心跳检测,失败检测通过集群内所有节点监控传播

agent下线,注册到该agent下的服务信息都会丢失

lifeguard,增强swim协议,动态调整超时时间,降低误判率

几类服务发现产品对比

eureka consul nacos etcd zk
api 服务发现rest api rest api & dns rest api & dns rest api & grpc zkClient
watcher long polling (eureka2) long polling udp key watcherclient long polling,server端定时任务遍历日志找某个版本之后的变更通知 key watcherclient 注册handler到本地,server保存回掉信息,触发时调用
心跳检查 client heartbeat server探活(支持mysql,redis之类无法嵌入client的基础服务) 注册时配了healthcheck的server端检查,client端默认注册就会启动beat定时任务 put key & ttl 并定时续期 依赖临时节点,跟server心跳保持
客户端缓存策略&更新策略 定时刷新,最多60s延迟 可手动指定缓存期限 一个service一个schedule任务定时更新
持久化 可手动持久化,用于还原备份 支持 v3支持,写wal 支持,快照 + 事务日志
cap ap cp(raft) ap(distrio) & cp (raft) cp(raft) cp(zab)



相关文章
|
27天前
|
弹性计算 人工智能 架构师
阿里云携手Altair共拓云上工业仿真新机遇
2024年9月12日,「2024 Altair 技术大会杭州站」成功召开,阿里云弹性计算产品运营与生态负责人何川,与Altair中国技术总监赵阳在会上联合发布了最新的“云上CAE一体机”。
阿里云携手Altair共拓云上工业仿真新机遇
|
3天前
|
人工智能 Rust Java
10月更文挑战赛火热启动,坚持热爱坚持创作!
开发者社区10月更文挑战,寻找热爱技术内容创作的你,欢迎来创作!
365 14
|
19天前
|
存储 关系型数据库 分布式数据库
GraphRAG:基于PolarDB+通义千问+LangChain的知识图谱+大模型最佳实践
本文介绍了如何使用PolarDB、通义千问和LangChain搭建GraphRAG系统,结合知识图谱和向量检索提升问答质量。通过实例展示了单独使用向量检索和图检索的局限性,并通过图+向量联合搜索增强了问答准确性。PolarDB支持AGE图引擎和pgvector插件,实现图数据和向量数据的统一存储与检索,提升了RAG系统的性能和效果。
|
6天前
|
JSON 自然语言处理 数据管理
阿里云百炼产品月刊【2024年9月】
阿里云百炼产品月刊【2024年9月】,涵盖本月产品和功能发布、活动,应用实践等内容,帮助您快速了解阿里云百炼产品的最新动态。
阿里云百炼产品月刊【2024年9月】
|
21天前
|
人工智能 IDE 程序员
期盼已久!通义灵码 AI 程序员开启邀测,全流程开发仅用几分钟
在云栖大会上,阿里云云原生应用平台负责人丁宇宣布,「通义灵码」完成全面升级,并正式发布 AI 程序员。
|
23天前
|
机器学习/深度学习 算法 大数据
【BetterBench博士】2024 “华为杯”第二十一届中国研究生数学建模竞赛 选题分析
2024“华为杯”数学建模竞赛,对ABCDEF每个题进行详细的分析,涵盖风电场功率优化、WLAN网络吞吐量、磁性元件损耗建模、地理环境问题、高速公路应急车道启用和X射线脉冲星建模等多领域问题,解析了问题类型、专业和技能的需要。
2592 22
【BetterBench博士】2024 “华为杯”第二十一届中国研究生数学建模竞赛 选题分析
|
5天前
|
存储 人工智能 搜索推荐
数据治理,是时候打破刻板印象了
瓴羊智能数据建设与治理产品Datapin全面升级,可演进扩展的数据架构体系为企业数据治理预留发展空间,推出敏捷版用以解决企业数据量不大但需构建数据的场景问题,基于大模型打造的DataAgent更是为企业用好数据资产提供了便利。
181 2
|
3天前
|
编译器 C#
C#多态概述:通过继承实现的不同对象调用相同的方法,表现出不同的行为
C#多态概述:通过继承实现的不同对象调用相同的方法,表现出不同的行为
105 65
|
7天前
|
Linux 虚拟化 开发者
一键将CentOs的yum源更换为国内阿里yum源
一键将CentOs的yum源更换为国内阿里yum源
332 2
|
23天前
|
机器学习/深度学习 算法 数据可视化
【BetterBench博士】2024年中国研究生数学建模竞赛 C题:数据驱动下磁性元件的磁芯损耗建模 问题分析、数学模型、python 代码
2024年中国研究生数学建模竞赛C题聚焦磁性元件磁芯损耗建模。题目背景介绍了电能变换技术的发展与应用,强调磁性元件在功率变换器中的重要性。磁芯损耗受多种因素影响,现有模型难以精确预测。题目要求通过数据分析建立高精度磁芯损耗模型。具体任务包括励磁波形分类、修正斯坦麦茨方程、分析影响因素、构建预测模型及优化设计条件。涉及数据预处理、特征提取、机器学习及优化算法等技术。适合电气、材料、计算机等多个专业学生参与。
1580 17
【BetterBench博士】2024年中国研究生数学建模竞赛 C题:数据驱动下磁性元件的磁芯损耗建模 问题分析、数学模型、python 代码