Dubbo与SpringCloud的选择

Dubbo优点：

• Dubbo 支持 RPC 调用，服务之间的调用性能会很好。
• 支持多种序列化协议，如 Hessian、HTTP、WebService。
• Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
• 在国内影响力比较大，中文社区文档较为全面。
• 阿里最近重启维护。

Dubbo优点：

• Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断。
• Dubbo 只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）。
• 另外，以后要兼容 .NET Core 服务，Dubbo RPC 本身不支持跨语言（可以用跨语言 RPC 框架解决，比如
  Thrift、gRPC（重复封装了），或者自己再包一层 REST 服务，提供跨平台的服务调用实现，但相对麻烦很多）
• Dubbo 只是实现了服务治理，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分布式配置用淘宝的
  Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且风险较大。
• 社区更新不及时（虽然最近在疯狂更新），但也难免阿里以后又不更新了，就尴尬了。
• 主要是国内公司使用，但阿里内部使用 HSF，相对于 Spring Cloud，企业应用会差一些。

SpringCloud优点：

• 有强大的 Spring 社区、Netflix 等公司支持，并且开源社区贡献非常活跃。
• 标准化的将微服务的成熟产品和框架结合一起，Spring Cloud 提供整套的微服务解决方案，开发成本较低，且风险较小。
• 基于 Spring Boot，具有简单配置、快速开发、轻松部署、方便测试的特点。
• 支持 REST 服务调用，相比于 RPC，更加轻量化和灵活（服务之间只依赖一纸契约，不存在代码级别的强依赖），有利于跨语言服务的实现，以及服务的发布部署。另外，结合Swagger，也使得服务的文档一体化。
• 提供了 Docker 及 Kubernetes 微服务编排支持。
• 国内外企业应用非常多，经受了大公司的应用考验（比如 Netfilx 公司），以及强大的开源社区支持。

SpringCloud缺点：

• 支持 REST 服务调用，可能因为接口定义过轻，导致定义文档与实际实现不一致导致服务集成时的问题（可以使用统一文档和版本管理解决，比如 Swagger）。
• 另外，REST 服务调用性能会比 RPC 低一些（但也不是强绑定）
• Spring Cloud 整合了大量组件，相关文档比较复杂，需要针对性的进行阅读。

Dubbo 和 Spring Cloud 的主要不同体现在两个方面：服务调用方式不同和专注点不同（生态不同）。

选择Dubbo的原因：

从学习成本上考虑，Dubbo的版本趋于稳定，文档完善，可以即学即用，没有太大难度。Spring Cloud 基于Spring Boot开发，需要开发者先学会Spring Boot。另外，Spring Cloud版本迭代快，需要快速跟进学习。Spring Cloud文档大多是英文的，要求学习者有一定的英文阅读能力。此外，Spring Cloud文档很多，不容易快速找到相应的文档。Dubbo更易上手，并且广泛使用于阿里巴巴的各大站点，经历了“双11”期间高并发、大流量的检验，Dubbo框架非常成熟和稳定。Dubbo提供一个功能强大的图形化管理后台，对开发团队比较友好。