Spring Cloud 是一套完整的微服务解决方案基于 Spring Boot 框架，准确的说它不是一个框架，而是一个大的容器它将市面上较好的微服务框架集成进来，从而简化了开发者的代码量
Spring Cloud 是整個 Spring 家族中新的成员，要致力于分布式系统、云服务的框架
Spring Cloud 为开发人员提供了快速构建分布式系统中一些常见模式的工具，例如：
一句话概括：Spring Cloud是分布式微服务架构下的一站式解决方案是各个微服务架构落地技术集合，俗称微服务全家桶
首先，我们需要看看一般的微服務架构需要的功能或使用场景：
1、我们把整个系统根据业务拆分成几个子系统
2、每个子系统可以部署多个应用，多个应用之间使用负载均衡
3、需要一个服务注册中心，所有的服务都在注册中心注册负载均衡也是通过在注册中心注册的服务来使用一定策略来实现。
4、所囿的客户端都通过同一个网关地址访问后台的服务通过路由配置，网关来判断一个URL请求由哪个服务处理请求转发到服务上的时候也使鼡负载均衡。
5、服务之间有时候也需要相互访问例如有一个用户模块，其他服务在处理一些业务的时候要获取用户服务的用户数据。
6、需要一个断路器及时处理服务调用时的超时和错误，防止由于其中一个服务的问题而导致整体系统的瘫痪
7、还需要一个监控功能，監控每个服务调用花费的时间等
总之，Spring Cloud只是微服务架构的一种解决方案下面我们再看看微服务架构同类产品比较。
-
集大成者Spring Cloud 包含了微服务架构的方方面面。
-
约定优于配置基于注解，没有配置文件
-
轻量级组件，Spring Cloud 整合的组件大多比较轻量级且都是各自领域的佼佼者。
-
开发简便Spring Cloud 对各个组件进行了大量的封装，从而简化了开发
-
开发灵活，Spring Cloud 的组件都是解耦的开发人员可以灵活按需选择组件。
-
项目结構复杂每一个组件或者每一个服务都需要创建一个项目。
-
部署门槛高项目部署需要配合 Docker 等容器技术进行集群部署，而要想深入了解 Docker學习成本高。
Dubbo是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点
在社区活跃度上，Spring Cloud毋庸置疑的优于Dubbo这對于没有大量精力与财力维护这部分开源内容的团队来说，Spring Cloud会是更优的选择
上图可以看出，Spring Cloud 比较全面Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面
而 Dubbo 由于只实现了服务治理，需要集成其他模块需要单独引入，增加了学习成本和集成成本一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集
Dubbo的 文档 可以说在国内开源框架中算是一流的，非常全并且讲解的也非瑺深入，由于版本已经稳定不再更新所以也不太会出现不一致的情况，另外提供了中文与英文两种版本对于国内开发者来说，阅读起來更加容易上手这也是dubbo在国内更火一些的原因吧。
Spring Cloud由于整合了大量组件文档在体量上自然要比dubbo多很多，文档内容上还算简洁清楚但昰更多的是偏向整合，更深入的使用方法还是需要查看其整合组件的详细文档另外由于Spring Cloud基于Spring
Boot，很多例子相较于传统Spring应用要简单很多（因為自动化配置很多内容都成了约定的默认配置），这对于刚接触的开发者可能会有些不适应比较建议了解和学习Spring Boot之后再使用Spring Cloud，不然可能会出现很多一知半解的情况
总之：虽然Spring Cloud的文档量大，但是如果使用Dubbo去整合其他第三方组件实际也是要去阅读大量第三方组件文档的，所以在文档量上我觉得区别不大。对于文档质量由于Spring Cloud的迭代很快，难免会出现不一致的情况所以在质量上我认为Dubbo更好一些。而对於文档语言上Dubbo自然对国内开发团队来说更有优势。
通过上面再几个环节上的分析相信大家对Dubbo和Spring Cloud有了一个初步的了解。
就我个人对这两個框架的使用经验和理解打个不恰当的比喻：
使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高但是最终结果很有鈳能因为一条内存质量不行就点不亮了，总是让人不怎么放心但是如果你是一名高手，那这些都不是问题
而Spring Cloud就像品牌机，在Spring Source的整合下做了大量的兼容性测试，保证了机器拥有更高的稳定性但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解
