springCloud与dubbo技术选型

spring Cloud与dubbo都为微服务框架,那么我们在进行技术选型时应该怎么考虑呢?可以从以下几个方面考虑

1.架构完整度:与spring cloud相比,dubbo的架构完整度不够,其本身只提供了服务注册中心与服务治理两个模块,而spring cloud到现在为止,已经提供了服务注册中心,服务治理等24个模块,并且还在增加中。虽然dubbo也可以整合第三方框架,但是搭建出来的dubbo架构可能出现兼容性问题,而spring cloud不会,因为其每一个模块都是经过严格测试的,几乎不存在兼容性问题。如果将spring cloud比作品牌机,那dubbo就是组装机

2.社区活跃度:与spring cloud相比,dubbo社区活跃度相对较低,社区活跃度的高低将影响项目维护成本,在社区活跃度很高时,一般项目中遇到的问题都可以在社区中找到响应的解决方案

3.通讯协议:dubbo服务间通讯采用rpc,而spring cloud采用的时http的rest。rpc对于业务接口有很强的依赖性,生产者和消费者都需要依赖相同的接口,并且还需要通过严格的业务接口版本来进行管理,这种依赖在大型微服务项目将会成为一个很大的问题,相比rpc,rest更加轻量化,服务调用者和提供者间的依赖仅仅是一纸契约,一段文本,不存在代码层面的强依赖,服务提供者和调用者之间还可以通过不同的语言来实现,只需要提供rest接口就可以通讯。

4.技术改造和微服务开发:国内的开发团队选择dubbo的一个很重要的原因就是官方文档,dubbo提供了高质量的官方文档,而spring cloud都是英文版的,并且文档内容要比dubbo多的多,文档内容更偏向模块整合,要对每个模块的进行更深入的了解,需要查看更为详细的文档,对于中小型团队来说,阅读英文文档的成本必须要考虑的

原文地址:https://www.cnblogs.com/kiwi-deng/p/11781410.html

时间: 2024-08-30 13:04:39

springCloud与dubbo技术选型的相关文章

微服务开发实战(spring-cloud/spring-cloud-alibaba/dubbo),一个案例,手把手带你入门

平日里,都是看别人的文章,虽开公众号写了不少,但像样的不多.年末了,年终总结也没来得及写,为了输出点像样的东西,立刻就着手这个系列.一个键一个字母的敲,边敲边写,文章还在持续更新中,直至完整.相信通过这个系列的系统练习,能有一个大跨步的提升. 专栏简介(是什么?) 结合SpringCloud.SpringCloudAlibaba.Dubbo等开源套件,基于某商场停车业务需求,进行微服务开发实战,力争通过一个案例的实操,掌握微服务架构中常用的技能点,轻松入门. 为什么要写这个专栏(为什么?) 微服

技术选型:Sentinel vs Hystrix

摘要: 这是围绕 Sentinel 的使用场景.技术对比和实现.开发者实践等维度推出的系列文章的第三篇. ? 第一篇回顾: Dubbo 的流量防卫兵 | Sentinel如何通过限流实现服务的高可用性 - 传送门 ? 第二篇回顾: RocketMQ 的保险丝| Sentinel 如何通过匀速请求和冷启动来保障服务的稳定性 - 传送门 Sentinel 是阿里中间件团队研发的面向分布式服务架构的轻量级高可用流量控制组件,于今年7月正式开源. 这是围绕 Sentinel 的使用场景.技术对比和实现.

微服务技术选型之路

本文以笔者个人经历讲述关于微服务方面的技术选型和相关知识点.微服务模式的项目从初建到上线部署应用,每一个环节都会涉及到相当多的技术细节(上线后的性能调优更需要).本文着重介绍一套微服务搭建流程中面临的一些技术选型,战略性的技术方案及相关技术的简要介绍,不做每一项技术的深入说明. ?微服务简介 微服务是指开发一个单个小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上.微服务也指一种种松耦合的.有一定的有界上下文的面向服务架构. 微服务是系统架构上的一种设计

微服务架构案例(01):项目技术选型简介,架构图解说明

本文源码:GitHub·点这里 || GitEE·点这里 一.单体架构 单体架构在中等偏小的业务中比较常见,场景模式就是单个应用.单个数据库.一个程序包(例如war格式或者Jar格式)包含所有业务需求功能,这是一种比较传统的架构风格. 单体架构的缺陷 复杂性高,整个项目包含的模块多,依赖模糊,修改程序容易触发不可知问题. 扩展能力受限,单体应用只能整体进行扩展,无法针对业务模块的特性进行伸缩. 稳定性差,任何微小的问题,都可能导致整个应用服务直接挂掉. 二.微服务架构 微服务架构是一种架构概念,

移动开发主流框架的选取以及技术选型方案解析

传统的移动开发模式主要分为三种,Native App,Web App 和 Hybrid App,对于目前微信端比较火爆的开发平台小程序,或者其他厂商推广的流应用.轻应用等开发方式,基本都离不开H5的支撑.目前App前端开发主流框架RN,Ionic,Vue都发展得不错.但是业务需求的快速发展,有些框架并不能够满足他们的需求,在不同的业务场景,受诸多约束因素的影响,研发团队应该如何在前端框架上做好选型? 根据目前51CTO社群(群号312724475)中大部分移动开发领域的开发者实际项目经验,我们邀

创业公司的技术选型

技术选型对创业公司至关重要,好的选型会让你少走弯路,产品更快推向市场,比竞争对手更快赢得客户,获得更多融资,有更多资源投入产品研发和市场扩展 … 如此往复形成良性循环.相反,每一个错误选型都会带来巨大的技术债务,我知道一些创业公司把 demo 时的选型一直用到 A 轮甚至 B 轮,然后不得不停下业务花几个月时间去重构整个系统. 可以说,对初创团队的技术 leader,最重要的事情就是选择正确的技术体系. 下面是我们技术选型的三个原则: 一.利用好创业公司技术选型的后发优势 大公司的基础设施往往超

技术选型注意事项

最近一个朋友比较烦恼,原因是他们的系统换数据库了,如果仅仅是换个数据库倒是没啥大不了,撑死了改个数据库的驱动,改改连接字符串就得了,这都是分分钟的事.但是悲哀的是表结构也得到了较大的调整,"累觉不爱"来形容这为朋友对换数据库这件事的感受再恰当不过了.而笔者对这件事有几点体会. 错误发现的越早浪费的时间越少 其实如果后面Dao实现用的是Hibernate或者是JPA那么在开发阶段换数据库就不再是什么麻烦的事情,然而他们用的是Ibatis(或者是MyBatis?忘记哪个了who care~

atitit.技术选型方法总结为什么java就是比.net有前途

#----按照不同的需要有不铜的法... 一般有开发效率,稳定性上的需要.. 作者 老哇的爪子 Attilax 艾龙,  EMAIL:[email protected] 转载请注明来源: http://blog.csdn.net/attilax #-----常规选型..一般还是java+php比较好.. 长期性:把需要都罗列出来,然后把那些在长期还用得到的标出来. 一般来说.console是最稳定性的...前端gui/web是不稳定性的...后端就是更好.. 查看历史:: 会晓得,为什么php会

技术选型--因地制宜、量体裁衣

——摘自<HTML5移动Web开发实战> c12  12.2 1.技术成熟度 一项技术是否成熟,决定了你的应用是否稳定.特别是新的技术通常意味着缺乏稳定性,在需要保证正确性和稳定性的场景(比如面向金融或者面向数量巨大的最终用户的应用),选择新技术时一定要慎重再慎重,对于一些不关键的容错性高的场景(比如内部系统),选择新技术的风险就会小很多. 2.文档 由于程序员基本都是由人类构成,因此文档好坏基本上制约着程序员的工作效率.无论你看到某项技术吹的再天花乱坠,请一定记得看看它的文档是否健全优雅,示