一、Dubbo负责人的采访
刘军，阿里巴巴中间件高级研发工程师，主导了 Dubbo 重启维护以后的几个发版计划，所以让我们来看一下他关于Dubbo和Springcloud是否二选一，他们之间的区别的阐述。
7、目前 Dubbo 被拿来比较最多的就是 Spring Cloud ，您怎么看待二者的关系，业务上是否有所冲突？
关于 Dubbo 和 Spring Cloud 间的关系，我们在开源中国年终盛典的 Dubbo 分享中也作了简单阐述，首先要明确的一点是 Dubbo 和 Spring Cloud 并不是完全的竞争关系，两者所解决的问题域并不一样：Dubbo 的定位始终是一款 RPC 框架，而 Spring Cloud 的目标是微服务架构下的一站式解决方案。如果非要比较的话，我觉得 Dubbo 可以类比到 Netflix OSS 技术栈，而 Spring Cloud 集成了 Netflix OSS 作为分布式服务治理解决方案，但除此之外 Spring Cloud 还提供了包括 config、stream、security、sleuth 等等分布式问题解决方案。
当前由于 RPC 协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时 Dubbo 与 Spring Cloud 是只能二选一，这也是为什么大家总是拿 Dubbo 和 Spring Cloud 做对比的原因之一。Dubbo 之后会积极寻求适配到 Spring Cloud 生态，比如作为 Spring Cloud 的二进制通信方案来发挥 Dubbo 的性能优势，或者 Dubbo 通过模块化以及对 http 的支持适配到 Spring Cloud 。
Netflix OSS 技术栈
1.Netflix Eureka 服务注册中心，提供服务的注册和发现
2.Netflix Ribbon 客户端负载均衡
3.Netflix Feign 客户端负载均衡，包装Ribbon，提供了接口式的服务调用
4.Netflix Hystrix 熔断器，负责服务的熔断和降级
5.NetFlix Hystrix dashboard 提供服务监控
6.Netflix zuul 路由网管 提供代理+路由+过滤三大功能
二、Dubbo和Springcloud比较
1.社区活跃度
https://github.com/dubbo dubbo社区
https://github.com/springcloud springcloud社区
可以进去看一下他们对于技术的活跃程度曲线
2.解决问题的方向
dubbo：定位始终是一款 RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
springcloud：微服务架构，提供微服务架构的一站式服务。
3.功能对比
根据两者的解决问题的域，得到他们的功能
| Dubbo | Spring | |
|---|---|---|
| 服务注册中心 | Zookeeper | Spring Cloud Netfilx Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 服务网关 | 无 | Spring Cloud Netflix Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总线 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
Dubbo的某些功能都是，通过整合其他组件实现，springcloud是通过实现Netflix oss的技术栈和原有的技术，实现的架构。
Dubbo提供了各种Filter，对于上述中“无”的要素，可以通过扩展Filter来完善。
例如
1．分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理
2．服务跟踪：可以使用京东开源的Hydra，或者扩展Filter用Zippin来做服务跟踪
3．批量任务：可以使用当当开源的Elastic-Job、tbschedule
总结：从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度略高。Dubbo更像是一个组装机，springcloud是一体机。
4.服务调用方式
Spring Cloud抛弃了RPC通讯，采用基于HTTP的REST方式。Spring Cloud牺牲了服务调用的性能，但是同时也避免了原生RPC带来的问题。REST比RPC更为灵活，不存在代码级别的强依赖，在强调快速演化的微服务环境下，显然更合适。
5.服务获取方式
dubbo通过长连接推送服务提供者地址列表给消费端，即是：Dubbo订阅Zookeeper下相应的节点，当节点的状态发生改变时，Zookeeper会立即反馈订阅的Client，实时性很高。
springcloud的eureka是 消费者端主动去eurekaServer注册中心获取数据，消费者可以配置去EurekaServer拉去服务列表的周期
dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
6.服务注册中心满足的CAP原则
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
Dubbo推荐使用zookeeper作为服务注册中心，zookeeper满足CP原则，一致性和分区容错性。springcloud的服务注册中心是Eureka，他满足的是AP原则，可用性和分区容错性。
Zookeeper如何保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka如何保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的 ，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
总结：那么既然保证了保证了可用性，那么数据的一致性肯定是不能够保证了，所以这个就是自我保护的机制。所以到底是AP还是CP，又或者是AC（数据库），要看业务场景来定。
而且Eureka部署集群时非常简单的，相比于dubbo部署zookeeper集群。
7.节点性质
Dubbo只有Consumer订阅Provider节点，也就是Consumer发现Provider节点信息
Eureka不区分Consumer或者Provider，两者都统称为Client，一个Client内可能同时含有Provider，Consumer，通过服务发现组件获取的是其他所有的Client节点信息，在调用时根据应用名称来筛选节点
