Dubbo诞生于阿里系，是阿里巴巴服务化管理的核心框架，广泛应用于我国各大互联网公司； 只需要Spring配置就可以完成服务化，没有对APP应用的入侵，设计的目的还是以服务自己的业务为主。
微服务体系结构是网络的热门话题是网络技术发展的必然结果它提倡将单个APP应用程序划分为一组较小的服务，服务之间协同合作，为用户提供最终价值。
虽然微服务体系结构没有公认的技术标准和规范或草案，但行业已有一个具有影响力的开源微服务体系结构框架，提供了Dubbo和Spring Cloud等微服务的重要思路。
大型互联网公司也有自研的微服务框架，但其模式都没有太大差异。
降低微服务的主要好处和复杂性
通过将结合起来的复杂业务分割为单一的服务，避免了本来的复杂无止境的积累。
每个微服务都集中在单一功能上，每个通过定义适当的接口来明确表达服务边界的服务开发人员只集中在服务本身上，并使用缓存和DAL等各种技术手段来提高系统性能，对消费者来说是完全透明的。
可独立部署
因为微服务具有独立的执行过程，所以每个微服务都可以独立部署。 在业务迭代期间，只需要发布相关服务的迭代，减少了测试工作量，同时降低了发布服务的风险。
容错技术
在微服务体系结构中，如果组件发生故障，故障将被隔离为一个服务。 例如，通过限流、熔断等方式降低差错危害，保障核心业务正常运行。
扩展
单块体系结构APP应用程序还可以通过将整个APP应用程序完全复制到不同的节点上来实现向外扩展。
当扩展需求因APP应用程序组件而异时，微服务体系结构提供了灵活性。 这是因为每个服务都可以根据实际需要独立扩展。
本文主要围绕微服务的技术选型、通信协议、服务依赖模式、启动模式、运行模式等几个方面对Dubbo和Spring Cloud两种开发框架进行综合比较。
架构师根据公司的技术能力，结合项目特点选择合适的微服务架构平台，可以确保项目微服务化改造或开发流程的实施。
核心部件
微服务的核心要素在于服务的发现、注册、路由、熔断、降级、分布式配置，根据上述几个必要条件比较杜比与斯普林云。
整体架构Dubbo核心部件(下图) :
Provider :暴露服务的提供者可以通过jar或容器启动服务。
消费者：调用远程服务的服务消费者。
Registry :服务注册中心和发现中心。
监视器：统计服务和调用次数，调用时间监视中心。 (可以显示在Dubbo的控制台页面上。 目前，只有一个简单版本。 ）
容器：服务运行时所在的容器。
Dubbo的总体体系结构
Spring Cloud的整体体系结构：
服务提供商：暴露服务的提供者。
服务消费者：调用远程服务的服务消费者。
EureKa Server :服务注册中心和服务发现中心。
Spring Cloud的整体体系结构
从总体框架看，两者模式接近，需要服务提供者、注册中心和服务消费者。
微服务体系结构的核心要素
Dubbo只是实现了服务治理，Spring Cloud子项目分别涵盖了微服务体系结构下的许多部件，服务治理只是其中的一个方面。
虽然Dubbo提供了各种各样的Filter，但是可以通过扩展Filter来改善上述“无”元素。 例如：
分布式配置：可以使用淘宝diamond、百度disconf实现分布式配置管理。
服务跟踪：可以使用京东开源Hydra，也可以使用扩展过滤器Zippin进行服务跟踪。
批处理任务：可以使用开源的Elastic-Job和tbschedule。
从核心要素来看，Spring Cloud更好，只要在开发过程中集成Spring Cloud的子项目，各种组件的融合就能顺利进行，但Dubbo需要通过实现各种过滤器来进行定制。
通信协议
根据通信协议级别，比较两个框架支持的协议类型和操作效率。
支持合同
达布o
Dubbo使用RPC通信协议，提供串行化方式如下。
Dubbo:Dubbo的默认协议采用单个长连接和NIO异步通信，适用于数据量少、同时发生服务呼叫或服务消费者的机器数远远多于服务提供商的机器数的情况。
RMI:RMI协议采用JDK标准的java.rmi.*实现，采用阻塞短连接和JDK标准串行化方式。
Hessian:Hessian协议用于集成Hessian的服务，Hessian的基础采用HTTP通信、servlet暴露服务，Dubbo默认将Jetty实现为服务器。
http :实现采用spring的Http Invoker。
web服务：基于
CXF 的 frontend-simple 和 transports-http 实现。Spring Cloud
Spring Cloud 使用 HTTP 协议的 REST API。
性能比较
使用一个 Pojo 对象包含 10 个属性，请求 10 万次，Dubbo 和 Spring Cloud 在不同的线程数量下，每次请求耗时（ms）如下：
说明：客户端和服务端配置均采用阿里云的 ECS 服务器，4 核 8G 配置，Dubbo 采用默认的 Dubbo 协议。
点评：Dubbo 支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜 Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适。
服务依赖方式
Dubbo
服务提供方与消费方通过接口的方式依赖，服务调用设计如下：
Interface 层：服务接口层，定义了服务对外提供的所有接口。
Molel 层：服务的 DTO 对象层。
Business层：业务实现层，实现 Interface 接口并且和 DB 交互。
因此需要为每个微服务定义各自的 Interface 接口，并通过持续集成发布到私有仓库中。调用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成环境都需要严格的管理版本依赖。
通过 maven 的 install & deploy 命令把 Interface 和 Model 层发布到仓库中，服务调用方只需要依赖 Interface 和 Model 层即可。
在开发调试阶段只发布 Snapshot 版本，等到服务调试完成再发布 Release 版本，通过版本号来区分每次迭代的版本。通过 xml 配置方式即可接入 Dubbo，对程序无入侵。
Dubbo 接口依赖方式
Spring Cloud服务提供方和服务消费方通过 Json 方式交互，因此只需要定义好相关 Json 字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵。
点评：Dubbo 服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。
而 Spring Cloud 通过 Json 交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身 Rest API 方式交互，为跨平台调用奠定了基础。
组件运行流程Dubbo
下图中的每个组件都是需要部署在单独的服务器上，Gateway 用来接受前端请求、聚合服务，并批量调用后台原子服务。每个 Service 层和单独的 DB 交互。
Dubbo 组件运行流程
Dubbo 组件运行：
Gateway：前置网关，具体业务操作，Gateway 通过 Dubbo 提供的负载均衡机制自动完成。
Service：原子服务，只提供该业务相关的原子服务。
Zookeeper：原子服务注册到 ZK 上。
Spring Cloud
Spring Cloud组件运行：
所有请求都统一通过 API 网关（Zuul）来访问内部服务。
网关接收到请求后，从注册中心（Eureka）获取可用服务。
由 Ribbon 进行均衡负载后，分发到后端的具体实例。
微服务之间通过 Feign 进行通信处理业务。
点评：业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。
Dubbo 需要自己开发一套 API 网关，而 Spring Cloud 则可以通过 Zuul 配置即可完成网关定制。使用方式上 Spring Cloud 略胜一筹。
微服务架构组成以及注意事项
到底使用是 Dubbo 还是 Spring Cloud 并不重要，重点在于如何合理的利用微服务。
下面是一张互联网通用的架构图，其中每个环节都是微服务的核心部分。
网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等。
业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务耦合。
Local Cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效的降低了服务调用的频次，同时也提示了访问速度。本地缓存一般使用自动过期方式，业务场景中允许有一定的数据延时。
服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在 Service 层主动调用。
Remote Cache：访问 DB 前置一层分布式缓存，减少 DB 交互次数，提升系统的TPS。
DAL：数据访问层，如果单表数据量过大则需要通过 DAL 层做数据的分库分表处理。
MQ：消息队列用来解耦服务之间的依赖，异步调用可以通过 MQ 的方式来执行。
数据库主从：服务化过程中必经的阶段，用来提升系统的 TPS。
服务启动方式建议使用jar方式启动，启动速度快，更容易监控。
缓存、缓存、缓存，系统中能使用缓存的地方尽量使用缓存，通过合理的使用缓存可以有效的提高系统的TPS。
服务拆分要合理，尽量避免因服务拆分而导致的服务循环依赖。
合理的设置线程池，避免设置过大或者过小导致系统异常。
Dubbo 出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过 Spring 配置的方式即可完成服务化，对于应用无入侵，设计的目的还是服务于自身的业务为主。
虽然阿里内部原因 Dubbo 曾经一度暂停维护版本，但是框架本身的成熟度以及文档的完善程度，完全能满足各大互联网公司的业务需求。
如果我们使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。
Spring Cloud 是大名鼎鼎的 Spring 家族的产品， 专注于企业级开源框架的研发。
Spring Cloud 自从发布到现在，仍然在不断的高速发展，几乎考虑了服务治理的方方面面，开发起来非常的便利和简单。
Dubbo 于 2017 年开始又重启维护，发布了更新后的 2.5.7 版本，而 Spring Cloud 更新的非常快，目前已经更新到 Finchley.M2。
因此，企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题，不管是 Dubbo 还是 Spring Cloud 都是实现微服务有效的工具。
参考Dubbo和Spring Cloud微服务架构比较