开发者学堂课程干货总结——Dubbo 分布式服务治理实践(二)

简介: Dubbo 分布式服务治理实践课时2——Dubbo分布式加与大规模服务集群治理 。电子书+视频为同学带来最佳学习效果,文字、课程链接、图谱地址统统为大家放送了哦!

哈喽各位同学们大家好呀,小编今天带着开发者学院中课程Dubbo分布式加与大规模服务集群治理”干货总结来了~一起学习新课程吧!

课程链接以及图谱地址小编已经为大家指路了,搭配学习效果更佳👇

课程名称:Dubbo 分布式服务治理实践

课程地址:https://developer.aliyun.com/learning/course/72/detail/1186?spm=a2c6h.21258778.0.0.6abe6a00HnUwTh

图谱名称:Alibaba Java 技术图谱

图谱地址:https://developer.aliyun.com/graph/java?spm=a2c6h.21110250.J_5703890090.6.700e3c67EjOBeJ


Dubbo分布式加与大规模服务集群治理 


一、Dubbo分布式架构 

image.png 

Dubbo架构主要分为两个部分:客户端服务端,也可称为Dubbo消费者和Dubbo提供者。 

例如电商网站,要调支付服务、物流服务订单服务监控服务、大数据服务等,服务是某些功能的封装,这些是提供者所提供的服务。作为客户端的话,用户要调用这些服务去完成某些业务功能因为客户端和服务端是位于不同进程,位于分布式网络中不同的节点上这是典型的一个架构。如果客户端和服务端两个都是单体的话,则为最简单的分布式架构。 

随着业务的不断发展,架构会不断演化有些业务是大规模的集群,此时单点调用无法解决问题这是由于服务端可能有10台100台1000台甚至更多。同样的服务有时候上线有时候下线,无法预估有多少台可能会上线,多少台会下线,此时需要使用集群的弹性收缩功能解决这个问题。 

如果集群从上线到下线到运行一直都是10台,则正常情况就能满足需求。但如果在某些大型业务场景,例如双11平时10台可以满足的业务,在双11的时候可能需要1000台,甚至上万台进行支撑因此不同的业务集群规模是不一样的小规模集群可能直接基于IP进行集群搭建就可以,大规模集群则需要对接多个不同的局域网,基于域名的方式进行调度的情况可能更多一点。 

因此,Dubbo分布式架构不仅是客户端和服务端消费者和提供者这样调用关系,它解决的是大规模客户端与大规模服务端的管理问题。 

简单的架构要解决技术问题的话,它还需要有一个注册中心,还有应用监控中心,这就是典型的Dubbo早期解决问题。 

 

 

二、Dubbo分布式集群架构 

这个基础上,如果服务是不定数量的大规模集群,就需架构进一步去升级改造。 

image.png 

注册中心可能是个集群,监控中心可能是个集群,在大型业务场景下,服务可能也是个集群。 

无论是支付服务、订单服务、商品服务、账号服务等,都可以根据自己的实际的并发需求,去部署不定规格、不定数量的大规模服务集群。Dubbo联合其他技术人员给用户提供快速上线包括管理的服务Dubbo不仅解决分布式调用的问题,还解决了多协议大规模集群的治理问题,这也是Dubbo在其他大型互联网公司中收到广泛好评的原因 

 

 

三、Dubbo核心组件 

  • Dubbo主要有以下核心组件: 
  1. Provider:服务的提供方,通过Jar或者容器的方式启动服务 
  2. Consumer:服务消费方 
  3. Registry:注册中心 
  4. Monitor:统计服务和调用次数,调用时间监控中心。(Dubbo的控制台页面中可以显示,目前只有一个简单版本 
  5. Container:服务运行的容器 

 

 

四、Dubbo SOA服务治理 

image.png 

Dubbo诞生于SOA盛行的2008年,早期基于Web Service中心SOA服务治理,后面在这个基础上逐渐开始大规模的扩充,服务之间关系越来越复杂。此时需要治理中心,用来做大规模的流量调度、监控等,这些都是极具挑战性的问题,因此阿里开发了很多工具在内部去解决这些问题。 

对于这些挑战性问题,Dubbo的许多观点思想与目前微服务架构Spring Cloud不谋而合。这是由于微服务到大规模集群的层次上,无论怎么拆,它终究会面临这些问题,例如熔断限流,负载均衡,流量调度,安全治理等。 

2013~2017年Dubbo疏于维护,而这是Spring Cloud蓬勃发展时期,逐渐成为世界级微服务框架,但从某种程度上来说,Dubbo可以称为Spring Cloud的前辈。 

 

 

五、Dubbo未来底层同步与异步架构 

image.png 

Dubbo从3.0版本开始,也在做服务高并发协议等方面的改造如云原生支持的改造,去支持底层的高并发高吞吐量,去对接K8s云原生的工具,协议层支持RPC等新的类型,从而让Dubbo整个通信协议更多样化,使用户在不同场景下可以选择不同的实践方式。 

异步请求和同步请求各有优势,异步请求优势在于非阻塞,同步请求的优势在于即时性,但如果是阻塞操作、长时间操作的话,可能会导致线程卡死的状况,影响整体的并发。 

Dubbo整个分布架构是更高层级的架构,它是大规模服务集群,不仅仅是开发落地,而且要大规模服务治理,它的实践经验给其他互联网公司的架构提供了很好的参考。 

 

 

六、Dubbo分布式架构与Remoting 

image.png 

Dubbo分布式架构的远程通讯(Remoting提供对多种NIO框架抽象封装,包括“同步转异步”和“请求-响应”模式的信息交换方式 

相关文章
|
1月前
|
人工智能 安全 Java
分布式 Multi Agent 安全高可用探索与实践
在人工智能加速发展的今天,AI Agent 正在成为推动“人工智能+”战略落地的核心引擎。无论是技术趋势还是政策导向,都预示着一场深刻的变革正在发生。如果你也在探索 Agent 的应用场景,欢迎关注 AgentScope 项目,或尝试使用阿里云 MSE + Higress + Nacos 构建属于你的 AI 原生应用。一起,走进智能体的新世界。
479 41
|
1月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
3月前
|
数据采集 消息中间件 监控
单机与分布式:社交媒体热点采集的实践经验
在舆情监控与数据分析中,单机脚本适合小规模采集如微博热榜,而小红书等大规模、高时效性需求则需分布式架构。通过Redis队列、代理IP与多节点协作,可提升采集效率与稳定性,适应数据规模与变化速度。架构选择应根据实际需求,兼顾扩展性与维护成本。
112 2
|
6月前
|
人工智能 安全 应用服务中间件
阿里巴巴 MCP 分布式落地实践:快速转换 HSF 到 MCP server
本文分享了阿里巴巴内部将大规模HSF服务快速转换为MCP Server的实践经验,通过Higress网关实现MCP协议卸载,无需修改代码即可接入MCP生态。文章分析了MCP生态面临的挑战,如协议快速迭代和SDK不稳定性,并详细介绍了操作步骤及组件功能。强调MCP虽非终极解决方案,但作为AI业务工程化的起点具有重要意义。最后总结指出,MCP只是AI原生应用发展的第一步,未来还有更多可能性值得探索。
1172 48
|
2月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
6月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
2203 57
|
6月前
|
安全 JavaScript 前端开发
HarmonyOS NEXT~HarmonyOS 语言仓颉:下一代分布式开发语言的技术解析与应用实践
HarmonyOS语言仓颉是华为专为HarmonyOS生态系统设计的新型编程语言,旨在解决分布式环境下的开发挑战。它以“编码创造”为理念,具备分布式原生、高性能与高效率、安全可靠三大核心特性。仓颉语言通过内置分布式能力简化跨设备开发,提供统一的编程模型和开发体验。文章从语言基础、关键特性、开发实践及未来展望四个方面剖析其技术优势,助力开发者掌握这一新兴工具,构建全场景分布式应用。
690 35
|
7月前
|
存储 负载均衡 测试技术
ACK Gateway with Inference Extension:优化多机分布式大模型推理服务实践
本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with Inference Extension组件,在Kubernetes环境中为多机分布式部署的LLM推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。
|
8月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
718 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
8月前
|
人工智能 运维 监控
领先AI企业经验谈:探究AI分布式推理网络架构实践
当前,AI行业正处于快速发展的关键时期。继DeepSeek大放异彩之后,又一款备受瞩目的AI智能体产品Manus横空出世。Manus具备独立思考、规划和执行复杂任务的能力,其多智能体架构能够自主调用工具。在GAIA基准测试中,Manus的性能超越了OpenAI同层次的大模型,展现出卓越的技术实力。