中台技术选型：pass掉spring cloud，而dubbo为啥？spring cloud 10w并发太难了，从性能比较有图有真相

本文主要是介绍中台技术选型：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压测结果：

在这里插入图片描述