首页 > 编程知识 正文

dubbo通信协议是什么,阿里sofa与dubbo区别

时间:2023-05-05 00:49:25 阅读:147182 作者:3586

十. SpringCloud和Dubbo的区别

1、背景

Spring专注于企业级开源框架的开发,Spring框架在中国乃至全球的应用非常广泛,开发通用、开源、稳健的开源框架是他们的主要工作所以相对来说,SpringCloud的背景比Dubbo更强大。

Dubbo来源于国内顶尖的阿里团队,但曾被阿里抛弃撤换。 但是,蚂蚁于2017年7月31日宣布团队重新开始维护。 阿里巴巴是一家商业公司,许多顶级项目也是开源的,但从总体战略上看,仍然以服务自身的业务为主。

2、服务发现

Dubbo使用第三方ZooKeeper作为其基础注册中心,实现服务的注册和发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,当然SpringCloud也使用zookeed

分布式领域有一个很有名的CAP定理。 c、数据一致性; a、服务可用性p、分区容错(针对网络分区故障的服务容错)。 在这个特性中,任何分布式系统都只能保证两个。

(1)、Zookeeper保证CP

向注册中心查询服务列表可以接受注册中心返回几分钟前的注册信息,但无法获得服务,直接down后无法使用。 也就是说,对服务注册功能可用性的要求高于一致性。 但是,在ZooKeeper中,当主节点因网络故障而无法与其他节点联系时,其馀节点可能会再次进行leader选举。 问题是,leader的选举时间过长,为30 ~ 120s秒,选举中整个zk集群无法使用,从而导致选举中注册服务瘫痪。 在云部署环境中,zk群集因网络问题而丢失主节点的概率相对较高。 服务最终可以恢复,但不能容忍长时间使用登记。

) 2、Eureka保证美联社

Eureka的设计优先考虑可用性。 Eureka中的每个节点是平等的,即使有几个节点锁定也不会影响正常节点的工作,剩下的节点仍然可以提供注册和查询服务。 另一方面,如果Eureka客户端在注册一个Eureka时发现连接失败,它会自动切换到另一个节点。 如果只剩下一个Eureka,就可以保证注册服务可用,并保证可用。 但是,检测到的信息可能不是最新的。 无法保证强一致性。 此外,Eureka还具有自我保护机制。 如果15分钟内85%以上的节点没有正常心率,则Eureka认为客户端和注册中心发生了网络故障,可能会发生以下情况:

、Eureka不再从注册列表中删除因长时间未收到心跳而应过期的服务

、Eureka仍然可以接受新服务的注册和查询请求,但不同步到其他节点(即确保当前节点仍然可用)。

、如果网络稳定,当前实例的新注册信息将同步到其他节点

因此,Eureka可以很好地应对某些节点因网络故障而失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。

3、服务间呼叫方式

) 1、REST是面向资源的,REST风格是轻量级、跨语言、跨平台的web服务方式。 它是一种设计理念,将网络万物视为资源,将对资源的所有操作方式定义为“查、插、删、改”四种方式,强调用于向外部暴露和调用API,所有操作

例如,左边是错误的设计,右边是正确的

get/rest/API/get dogs-- get/rest/API/dogs获取所有小狗

get/rest/API/add dogs--在开机自检/rest/API/dogs中添加小狗

get/rest/API/edit dogs/: dog _ id-- put/rest/API/dogs/3360 dog _ id修改小狗

get/rest/API/delete dogs/: dog _ id--删除delete/rest/API/dogs/: dog _ id小狗

左边的这个设计显然不是rest风格。 如上所述,URI只负责准确无误的曝光资源,而getDogs/addDogs .包含对资源的操作是错误的。 相反右边被满足,但其操作使用标准的HTTP动词来表现。

HTTP动词

GET获取资源

开机自检添加资源

ut将更改资源

删除删除资源

    (2)、RPC架构的全名是远程过程调用,像调用本地服务(方法)一样调用服务器的服务(方法)。dddbks在客户端调用服务器端程序时,调用的方式和函数名和服务器端的一模一样,这样大大缩短了开发时间和交流成本,只需要在后端给出整个函数名列表和参数列表即可。

        (3)、Restful架构是基于Http应用层协议的产物,RPC架构是基于TCP传输层协议的产物。RPC架构的吞吐量和执行速度优于Restful。

        (4)、如果仔细阅读过微服务提出者苹果寒风的论文的话可以发现其定义的服务间通信机制就是Http Rest。RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强,我们需要为每一个微服务进行接口的定义,并通过持续继承发布,需要严格的版本控制才不会出现服务提供和调用之间因为版本不同而产生的冲突。而REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,只是通过一个约定进行规范,但也有可能出现文档和接口不一致而导致的服务集成问题,但可以通过swagger工具整合,是代码和文档一体化解决,所以REST在分布式环境下比RPC更加灵活。这也是为什么当当网的DubboX在对Dubbo的增强中增加了对REST的支持的原因。

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