spring cloud和dubbo各自的优缺点是什么?

简而言之，Dubbo确实类似于Spring Cloud的一个子集，Dubbo功能和文档完善，在国内有很多的成熟用户，然而鉴于Dubbo的社区现状（曾经长期停止维护，2017年7月31日团队又宣布重点维护），使用起来还是有一定的门槛。Dubbo具有调度、发现、监控、治理等功能，支持相当丰富的服务治理能力。Dubbo架构下，注册中心对等集群，并会缓存服务列表已被数据库失效时继续提供发现功能，本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的网站。
虽然Dubbo 支持短连接大数据量的服务提供模式，但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的。所以，对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言，Dubbo 确实是一个可以考虑的选择。但如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo 并不合适。同时，对于人手不足的初创产品而言，这么重的架构维护起来也不是很方便。Spring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）。但它并没有重复造轮子，而是选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架（我们需要特别感谢Netflix ，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，Spring Cloud主要是对Netflix开源组件的进一步封装），通过Spring Boot 进行封装集成并简化其使用方式。基于Spring Boot，意味着其使用方式如Spring Boot 简单易用；能够与Spring Framework、Spring Boot、Spring Data 等其他Spring 项目完美融合，意味着能从Spring获得巨大的便利，意味着能减少已有项目的迁移成本。

Dubbo是阿里巴巴开源的分布式服务化治理框架（微服务框架），久经阿里巴巴电商平台的大规模复杂业务的高并发考验，到目前为止Dubbo仍然是开源界中体系最完善的服务化治理框架，因此Dubbo被国内大量的的互联网公司和专统企业使用，国内使用Dubbo的企业有：阿里巴巴、京东、当当、携程、去哪儿、搜狐、南方航空、中软国际、软通动力、各大电信运营商等；Spring Cloud是一个基于Spring Boot来实现的一系列工具框架的集合体。

在微服务架构中，Spring Cloud为基于JVM的云应用开发中的服务发现、负载均衡、断路器、智能路由、配置管理、控制总线等等操作提供了一种简单、快捷的开发方式。 Spring Cloud包含了多个子项目，比如：Spring Cloud Netflix 、Spring Cloud Config、Spring Cloud Stream、Spring Cloud Bus、Spring Cloud Sleuth等项目。

从项目的背景来看，Dubbo 国内用的公司挺多，国内影响力大，Spring Cloud 自然在国外影响力较大，所以这个来看不分伯仲了，毕竟都有大公司在使用。

从社区的活跃度来看，可以看下各自的Github托管项目来区分，Dubbo · GitHub 与 Spring Cloud · GitHub ，从更新频率与更新时间来看 Spring Cloud 优于Dubbo，Dubbo基本不维护了。

从框架的完整度来看，Dubbo只是实现了服务治理（注册，发现等），而Spring Cloud下面有很多个子项目覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。如果选择Spring Cloud，基本上每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与快速的迭代更新也会让你没有后顾之忧。