首页 > 编程知识 正文

dubbo服务发现原理,dubbo工作原理

时间:2023-05-06 03:46:50 阅读:39083 作者:2325

官方文档地址 中文版 学习方便http://dubbo.apache.org/zh-cn/docs/user/quick-start.html

gitHub https://github.com/apache/incubator-dubbo

背景随着互联网的发展,网站APP应用的规模不断扩大,普通的垂直APP应用体系结构无法适应,分布式服务体系结构和移动计算体系结构势在必行,体系结构发展完善

单APP应用程序体系结构

如果网站流量很少,则通过在一个APP应用程序中聚合所有功能来降低部署节点和成本。 此时,用于简化追加删除重新审视作业的数据访问框架(ORM )很重要。

垂直APP应用程序体系结构

随着访问次数的逐渐增加,一个APP应用程序增加机器所带来的加速度越来越小,将APP应用程序分解为几个相互无关的APP应用程序以提高效率。 此时,用于加快前端页面开发的Web框架(MVC )是关键。

分布式服务体系结构

随着垂直的APP应用越来越多,APP应用之间的交互不可避免,提取核心业务,作为独立的服务,逐渐形成稳定的服务中心,使前端APP应用能够更快地适应变化的市场需求。 此时,用于提高业务复用和整合的分布式服务框架(RPC )很重要。

移动计算体系结构

随着服务增加,容量评估、小服务资源浪费等问题日益突出,需要增加基于访问压力实时管理集群容量的调度中心,提高集群利用率。 此时,用于提高设备利用率的资源调度和管理中心(SOA )很重要。

需求

在大规模服务化之前,APP应用程序可能只需要通过RMI和Hessian等工具,轻松暴露和引用远程服务,设置和调用服务的URL地址,并通过F5等硬件平衡负载。

当服务越来越多时,服务 URL 配置管理变得非常困难,F5 硬件负载均衡器的单点压力也越来越大。此时需要服务注册中心,需要动态注册和发现服务以使服务位置透明。 另外,通过在消费者端获取服务提供者地址列表,实现软负载均衡和Failover,还可以降低对F5硬件负载均衡器的依赖,降低部分成本。

当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。在这种情况下,架构师必须自动创建APP应用程序之间的依赖关系图,以便组织关系。

接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?为了解决这些问题,第一步是统计服务当前每天的呼叫量、响应时间,作为容量规划的参考指标。 接下来,为了能够动态调整权重,在线上,在一直增大某个设备的权重的同时,记录响应时间的变化,直到响应时间达到阈值为止,记录此时的访问数,将该访问数乘以设备数,反算总容量。

以上是Dubbo最基本的几个需求。

体系结构

节点角色说明

节点角色说明提供程序暴露服务服务提供程序Consumer调用远程服务服务消费者注册表服务注册和检测到的注册中心Monitor统计服务调用次数和调用时间监视中心Container服务执行情况

服务容器负责启动、加载和运行服务提供者。 服务提供者在启动时,在登记中心登记自己提供的服务。 服务消费者在启动时,向注册中心订阅自己需要的服务。 注册中心将服务提供商地址列表返回给消费者,如果发生更改,注册中心将根据长连接向消费者推送更改数据。 基于软负载均衡算法,服务消费者从提供商的地址列表中选择一个提供商进行调用,如果调用失败则选择另一个提供商进行调用。 消费者和提供者在内存中累计呼叫次数和呼叫时间,定时每分钟向监控中心发送统计数据。 Dubbo体系结构具有以下特点,分别是连接性、健壮性、伸缩性和向未来体系结构的升级性。

连接性注册中心负责服务地址的注册和检索,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,压力小的监控中心统计各服务呼叫次数、呼叫时间等首先汇总到内存中,然后每分钟发送到监控中心服务器,报告服务提供者向注册中心提供的服务,并向监控中心报告呼叫时间。 该时间不包括网络开销服务消费者从注册中心获取服务提供者地址列表,基于负载算法直接调用提供者,同时向监控中心报告调用时间。 在这个时间,网络开销注册中心、服务提供商、服务消费者三者之间是长连接,除了监控中心之外的注册中心通过长连接感知到服务提供商的存在,服务提供商瘫痪,注册中心立即成为消费者注册中心消费者本地缓存了提供者名单注册中心和监控中心,但服务消费者直接关闭服务提供者顽强的监控中心不会影响使用。 但是,即使某些采样数据库关闭,注册中心也可以通过缓存提供服务列表查询。 但是,无法在新服务注册中心的对等群集上注册。 发生任何停机后,即使自动切换到其他注册中心并全部停机,服务提供者和服务消费者也可以通过本地缓存通信服务提供者保持无状态。 发生任何停机后,所有不影响使用的服务提供者都停机后,服务消费者APP应用程序将不再可用,您可以多次等待服务提供者返回可扩展的注册中心

群,可动态增加机器部署实例,所有客户端将自动发现新的注册中心服务提供者无状态,可动态增加机器部署实例,注册中心将推送新的服务提供者信息给消费者升级性

当服务集群规模进一步扩大,带动IT治理结构进一步升级,需要实现动态部署,进行流动计算,现有分布式服务架构不会带来阻力。下图是未来可能的一种架构:

节点角色说明

节点角色说明Deployer自动部署服务的本地代理Repository仓库用于存储服务应用发布包Scheduler调度中心基于访问压力自动增减服务提供者Admin统一管理控制台Registry服务注册与发现的注册中心Monitor统计服务的调用次数和调用时间的监控中心

微信公众号

                          

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。