1 . 框架背景

当前主流上较常用的java微服务框架 , 就是cloud和dubbo . 
dubbo是阿里公司开源的RPC框架 , 背景很优秀 , 技术也是一等一的强 , 在spring cloud之前的年代也是很辉煌的 , 后来阿里停止维护了大概2年多的时间 , 中间有人提了些bug和意见都没人搭理 . 后来cloud强势崛起后把微服务的概念又炒的火热起来 , dubbo又恢复维护和更新 , 并且加入了更多的官方支持 , 用dubbo和zookeeper结合起来 , 也是很不错的一套微服务架构
spring cloud 框架 , 故名思议 , 是出产了spring那一套框架的人做出来的 , spring在java领域 , 几乎无人不知无人不晓的一个框架 . 
spring cloud其实就是一系列框架的有序集合 , 然后spring的团队进行了 “Spring boot”开发风格的改善和一些功能封装 , 并不是重复造轮子

2 . Cloud 和Dubbo的对比

• dubbo采用rpc远程调用 , cloud采用http协议通讯

rpc是基于tcp/udp , 传输的是二进制

而http则是在tcp上基础上又封装了一层 , 从通讯效率上讲 . colud略逊一筹 , 因为http通常的通讯通常是json .

• 组件完善性

dubbo的服务网关/断路器/分布式配置/服务跟踪等功能不完善或没有 , 需要再借助其他框架实现 . 增加开发成本 . 而cloud其下涵盖了17个或更多的组件 , 功能完善

• 服务依赖性

dubbo的各服务间依赖性太强 , 多个服务间通讯必须都提供各自的service抽象接口 , 所以在调用者和提供者的版本上必须要协同一致 . 并且提供方修改接口时 , 会直接导致调用方请求失败 . 而cloud采用http通讯则可以较好的兼容该问题

• 接口的约束性

由于dubbo采用的抽象接口约束 , 接口的参数内容和数量以及响应对象都有较强的一致性

但cloud采用的http方式 , 对接口约束比较宽泛 , 接口的调用方式(get/post)/传参格式(json/string/xml)/响应对象(文本/文件/对象) , 等都需要统一的约束和规范 , 否则在后期迭代中会越来越混乱

• 跨语言

​​​​​​​http通讯方便的解决了跨语言的问题 , 只要任何一个支持http的语言 , 都可以很方便的集成到微服务中来 . 而dubbo则不能

正是如此 , 当当网在基于dubbo上扩展的dubbox上增加了http调用的支持

综合来讲呢 , dubbo就是效率高 , 约束强 ; 而cloud就是比较自由 , 比较全能

3 . Spring Cloud 组件总览