微服务
微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力，而无论是Dobbo或者是SpringCloud都属于Java的微服务框架。
服务调用
服务调用方式是 Dubbo 和 Spring Cloud 重要不同点，了解 RPC/gRPC/HTTP/REST 相关概念，有助于对比 Dubbo 和 Spring Cloud。
1、RPC 是远端过程调用，其调用协议通常包含传输协议和编码协议。
2、HTTP 严格来说跟 RPC 不是一个层级的概念，HTTP 本身也可以作为 RPC 的传输层协议。
其中传输协议包含，例如著名的gRPC使用的 HTTP 2.0 协议，也有如 Dubbo 一类的自定义报文的 TCP 协议。而编码协议则有基于文本编码的，也有二进制编码的等。
需要注意的是在跨语言调用的时候，REST 风格直接把 HTTP 作为应用协议（直接和服务打交道），不同语言之间调用比较方便。而 RPC 可以把 HTTP 作为一种传输协议（比如 gRPC 使用 HTTP 2.0 协议传输），本身还会封装一层 RPC 框架的应用层协议，不同语言之间调用需要依赖 RPC 协议。
Dubbo 是什么？
Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架。
Dubbo 框架
模块注解：
- Provider: 暴露服务的服务提供方。
- Consumer: 调用远程服务的服务消费方。
- Registry: 服务注册与发现的注册中心。
- Monitor: 统计服务的调用次调和调用时间的监控中心。
- Container: 服务运行容器。
流程详解：
- 0 服务容器负责启动，加载，运行服务提供者（Standalone 容器）。
- 1 服务提供者在启动时，向注册中心注册自己提供的服务（Zookeeper/Redis）。
- 2 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（根据数据可以动态调整权重）。
Dubbo 集群容错
面对服务消费方时，当业务逻辑中需要调用一个服务时，真正调用的其实是 Dubbo 创建的一个 Proxy，该 Proxy 会把调用转化成调用指定的 Invoker（Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个（通过 LoadBalance），Invoker 封装了 Provider 地址及 Service 接口信息）。而在这一系列的委托调用的过程里就完成了服务治理的逻辑，最终完成调用。
Dubbo 特点
- 远程通讯: 提供对多种基于长连接的 NIO 框架抽象封装（非阻塞 I/O 的通信方式），包括多种线程模型、序列化，以及“请求-响应”模式的信息交换方式。
- 集群容错: 提供基于接口方法的透明远程过程调用（RPC），包括多协议支持（自定义 RPC 协议），以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
优点
- Dubbo 支持 RPC 调用，服务之间的调用性能会很好。
- 支持多种序列化协议，如 Hessian、HTTP、WebService。
- Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
- 在国内影响力比较大，中文社区文档较为全面。
- 阿里最近重启维护。
缺点
- Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断。
- Dubbo 只支持 RPC 调用。使得服务提供方（抽象接口）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）。
- 另外，以后要兼容服务，Dubbo RPC 本身不支持跨语言（可以用跨语言 RPC 框架解决，比如gRPC（重复封装了），或者自己再包一层 REST 服务，提供跨平台的服务调用实现，但相对麻烦很多）
- Dubbo 只是实现了服务治理，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分布式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且风险较大。
- 社区更新不及时（虽然最近在重启更新）。
Spring Cloud 是什么？
Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。
Spring Cloud 组件架构
流程：
- 请求统一通过 API 网关（Zuul）来访问内部服务。
- 网关接收到请求后，从注册中心（Eureka）获取可用服务。
- 由 Ribbon 进行均衡负载后，分发到后端具体实例。
- 微服务之间通过 Feign 进行通信处理业务。
- Hystrix 负责处理服务超时熔断。
- Turbine 监控服务间的调用和熔断相关指标。
优点
- 有强大的 Spring 社区、Netflix 等公司支持，并且开源社区贡献非常活跃。
- 标准化的将微服务的成熟产品和框架结合一起，Spring Cloud 提供整套的微服务解决方案，开发成本较低，且风险较小。
- 基于 Spring Boot，具有简单配置、快速开发、轻松部署、方便测试的特点。
- 支持 REST 服务调用，相比于 RPC，更加轻量化和灵活（服务之间只依赖一纸契约，不存在代码级别的强依赖），有利于跨语言服务的实现，以及服务的发布部署。另外，结合 Swagger，也使得服务的文档一体化。
- 提供了 Docker 微服务编排支持。
- 国内外企业应用非常多，经受了大公司的应用考验（比如 Netfilx 公司），以及强大的开源社区支持。
缺点
- 支持 REST 服务调用，但是因为接口定义过轻，导致定义文档与实际实现不一致导致服务集成时的问题（可以使用统一文档和版本管理解决，比如 Swagger）。
- 另外，REST 服务调用性能会比 RPC 低一些（但也不是强绑定）
- Spring Cloud 整合了大量组件，相关文档比较复杂，需要针对性的进行阅读。
Dubbo 和 Spring Cloud 对比
Dubbo 专注 RPC 和服务治理，Spring Cloud 则是一个微服务架构生态。
ZooKeeper 和 Eureka 的区别
鉴于服务发现对服务化架构的重要性，Dubbo 实践通常以 ZooKeeper 为注册中心（Dubbo 原生支持的 Redis 方案需要服务器时间同步，且性能消耗过大）。针对分布式领域著名的 CAP 理论（C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性），Zookeeper 保证的是 CP ，但对于服务发现而言，可用性比数据一致性更加重要，AP 胜过 CP，而 Eureka 设计则遵循 AP 原则。
Spring Cloud 支持 Consul（CA）和 Zookeeper，但不推荐使用。
总结
使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。