十、SpringCloud与Dubbo的区别

十、SpringCloud与Dubbo的区别

    1、背景

        Spring是专注于企业级开源框架开发，在中国，或者在整个世界上Spring框架都应用的非常广泛，开发出通用、开源、稳健的开源框架就是他们的主业。所以相对来说SpringCloud的背景比Dubbo更加强大。

        Dubbo是来源于国内顶尖的阿里团队，但是曾经被阿里弃用停更，但是后来阿里2017年7月31日团队又宣布重启维护。阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。

    2、服务发现

        Dubbo使用了第三方的ZooKeeper作为其底层的注册中心，实现服务的注册和发现，SpringCloud使用Spring Cloud Netflix Eureka实现注册中心，当然SpringCloud也可以使用ZooKeeper实现。

        分布式领域有一个很著名的CAP定理：C、数据一致性；A、服务可用性；P、分区容错性（服务对网络分区故障的容错性）。在这个特性中任何分布式系统只能保证两个。

        (1)、Zookeeper保证CP

            当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是ZooKeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

        (2)、Eureka保证AP

            Eureka在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

            ①、Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务

            ②、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

            ③、当网络稳定时，当前实例新的注册信息会被同步到其它节点中

            因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

    3、服务间调用方式

        (1)、REST是面向资源的，Restful是一种轻量级，跨语言，跨平台的web服务方式，它是一种设计理念，它强调将网络中的一切事物看成资源，对资源的所有的操作方式均定义成“查，插，删，改”　四种方式，向外界暴露API，用来调用，所有的操作都是无状态的。

            比如：左边是错误的设计，而右边是正确的

            GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗

            GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗

            GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗

            GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗

            左边的这种设计，很明显不符合REST风格，上面已经说了，URI 只负责准确无误的暴露资源，而 getDogs/addDogs...已经包含了对资源的操作，这是不对的。相反右边却满足了，它的操作是使用标准的HTTP动词来体现。

            HTTP动词

            GET         获取一个资源

            POST      添加一个资源

            PUT        修改一个资源

            DELETE  删除一个资源

        (2)、RPC架构的全名是远程过程调用，像调用本地服务（方法）一样调用服务器的服务（方法）。当你在客户端调用服务器端程序时，调用的方式和函数名和服务器端的一模一样，这样大大缩短了开发时间和交流成本，只需要在后端给出整个函数名列表和参数列表即可。

        (3)、Restful架构是基于Http应用层协议的产物，RPC架构是基于TCP传输层协议的产物。RPC架构的吞吐量和执行速度优于Restful。

        (4)、如果仔细阅读过微服务提出者马丁福勒的论文的话可以发现其定义的服务间通信机制就是Http Rest。RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强，我们需要为每一个微服务进行接口的定义，并通过持续继承发布，需要严格的版本控制才不会出现服务提供和调用之间因为版本不同而产生的冲突。而REST是轻量级的接口，服务的提供和调用不存在代码之间的耦合，只是通过一个约定进行规范，但也有可能出现文档和接口不一致而导致的服务集成问题，但可以通过swagger工具整合，是代码和文档一体化解决，所以REST在分布式环境下比RPC更加灵活。这也是为什么当当网的DubboX在对Dubbo的增强中增加了对REST的支持的原因。