本文主要是介绍中台技术选型:pass掉spring cloud,而dubbo为啥?spring cloud 10w并发太难了,从性能比较有图有真相,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
dubbo
Dubbo 是一个分布式服务框架,致力于提供高性能和透明化的RPC 远程服务调用方案,以及SOA 服务治理方案。简单的说,Dubbo 就是个服务框架,说白了就是个远程服务调用的分布式框架
优点:
传输性能:二进制的传输,占用带宽会更少,dubbo 支持RPC 调用,服务之间的调用性能会很好。
支持多种序列化协议,如 Hessian、HTTP、WebService。
Dobbo Admin后台管理功能强大,提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
在国内影响力比较大,中文社区文档较为全面。
阿里最近重启维护。
维护成本:精简化,针对性,有监控,技术精简化,遮蔽技术
更灵活的技术迭代和选型:高质量的RPC服务,稳定即可,更多的,推荐升级周边服务,比如MyBaties,Spring等
缺点:
Registry 严重依赖第三方组件(zookeeper 或者 redis),当这些组件出现问题时,服务调用很快就会中断。
Dubbo 只支持 RPC 调用。使得服务提供方(抽象接口)与调用方在代码上产生了强依赖,服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题,就会导致服务调用出错,并且以后发布部署会成很大问题(太强的依赖关系)。
另外,以后要兼容 .NET Core 服务,Dubbo RPC 本身不支持跨语言(可以用跨语言 RPC 框架解决,比如 Thrift、gRPC(重复封装了),或者自己再包一层 REST 服务,提供跨平台的服务调用实现,但相对麻烦很多)
Dubbo?只是实现了服务治理,其他微服务框架并未包含,如果需要使用,需要结合第三方框架实现(比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra,但使用相对麻烦些),开发成本较高,且风险较大。
社区更新不及时(虽然最近在疯狂更新),但也难免阿里以后又不更新了,就尴尬了。
主要是国内公司使用,但阿里内部使用 HSF,相对于 Spring Cloud,企业应用会差一些。
spring cloud
Spring Cloud 基于 Spring Boot,为微服务体系开发中的架构问题,提供了一整套的解决方案——服务注册与发现,服务消费,服务保护与熔断,网关,分布式调用追踪,分布式配置管理等。
优点:
有强大的 Spring 社区、Netflix 等公司支持,并且开源社区贡献非常活跃。
标准化的将微服务的成熟产品和框架结合一起,Spring Cloud 提供整套的微服务解决方案,开发成本较低,且风险较小。
基于 Spring Boot,具有简单配置、快速开发、轻松部署、方便测试的特点。
支持 REST 服务调用,相比于 RPC,更加轻量化和灵活(服务之间只依赖一纸契约,不存在代码级别的强依赖),有利于跨语言服务的实现,以及服务的发布部署。另外,结合 Swagger,也使得服务的文档一体化。
提供了 Docker 及 Kubernetes 微服务编排支持。
国内外企业应用非常多,经受了大公司的应用考验(比如 Netfilx 公司),以及强大的开源社区支持。
缺点:
传输性能:HTTP+JSON,http协议传输,带宽会比较多,同时使用http协议一般会使用JSON报文,消耗会更大 ,Boot已经实现了,与其说使用Cloud,还不如用Boot
支持 REST 服务调用,可能因为接口定义过轻,导致定义文档与实际实现不一致导致服务集成时的问题(可以使用统一文档和版本管理解决,比如 Swagger)。
另外,REST 服务调用性能会比 RPC 低一些(但也不是强绑定)
Spring Cloud 整合了大量组件,相关文档比较复杂,需要针对性的进行阅读。
维护成本:大量的技术引入,组件多维护成本上升。
更灵活的技术迭代和选型:组件封装得甚至有些过渡
loadrunner压测结果:
这篇关于中台技术选型:pass掉spring cloud,而dubbo为啥?spring cloud 10w并发太难了,从性能比较有图有真相的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!