核心部件
Remoting：网络通信框架，实现了sync-over-async和request-response消息机制。
RPC：一个远程过程调使用的笼统，支持负载均衡、容灾和集群功能
Registry：服务目录框架使用于服务的注册和服务事件发布和订阅
核心内容
RPC远程调使用：封装了长连接NIO框架，如Netty、Mina等，采使用的是多线程模式。
集群容错：提供了机遇借口方法的远程调使用的功能，并实现了负载均衡策略略、失败容错等功能。
服务发现：集成了Apache的Zookeeper组建，使用于服务的注册和发现。
框架架构图
Spring Cloud 与 Dubbo 比较
架构流程
●服务提供者向服务中心注册服务。
●服务消费者订阅服务。
●服务消费者发现服务。
●服务消费者远程调度服务提供者进行服务消费，在调渡过程中，用了负载均衡策略、失败容错的功能。
●服务消费者和提供者，在内存中记录服务的调使用次数和调使用时间，并定时每分钟发送一次统计数据到监控中心。
特性
●服务提供者向服务中心注册服务。
●服务消费者订阅服务。
●服务消费者发现服务。
●服务消费者远程调度服务提供者进行服务消费，在调渡过程中，用了负载均衡策略、失败容错的功能。
●服务消费者和提供者，在内存中记录服务的调使用次数和调使用时间，并定时每分钟发送一次统计数据到监控中心。
Spring Cloud 与 Dubbo 比较
首先，从微服务关注点来比较Spring Cloud 和 Dubbo 两大服务框架，如表所示：
微服务关注点
Spring Cloud
Dubbo配置管理Config―服务发现Eureka、Consul、ZookeeperZookeeper负载均衡Ribbon自带网管Zuul―分布式追踪Spring Cloud Sleuth―容错Hystrix不完善通信方式HTTP、MessageRPC安全板块Spring Cloud Security―
Spring Cloud 拥有很多的项目板块，包含了微服务系统的方方面面。Dubbo 是一个非常优秀的服务治理和服务调使用框架，但缺少很多功能板块，例如网管、链路追踪等。在项目板块上，Spring Cloud 占据着更大的优势。
Spring Cloud的升级速度非常快，Camden.SR从2017年2月~4月基本每个月会发一次版本的迭代。从GitHub的代码仓库来看，Spring Cloud几乎每天都有升级。阿里巴巴于2011年10月开源了Dubbo，开园后的Dubbo发展迅速，大概没2~3个月又一次版本升级。然而，从2013年3月开始，Dubbo暂停了版本升级，知道2017年9月，阿里巴巴中间件部门把Dubbo列为重点开源项目，重新组建了Dubbo团队，并在2017年9月~11月期间，保持每月一次版本升级的频率。
从开发风格上来讲，Dubbo更倾向于Spring Xml 的配置方式，Dubbo 官方也推荐这种方式。Spring Cloud基于Spring Boot，Spring Boot 采使用的是基于注解和JavaBean配置方式的敏捷开发。从开发速度上讲，Spring Cloud具备更高的开发和部署速度。
Spring Cloud的通信方式大多数是基于HTTP Restful 风格的，服务与服务之间完全无关、无耦合。因为采使用的是HTTP Rest，因而服务无关乎语言和平台，只要要提供相应API接口，即可以相互调使用。Dubbo 的通信方式基于远程调使用，对接口、平台和语言有强依赖性。假如需要实现跨平台调使用服务，需要些额外的中间件，这也是Dubbo存在的起因。
Spring Cloud
Spring Cloud
Dubbo
Dubbo
Dubbo 和Spring Cloud拥有各自的优缺点。Dubbo更易上手，并且广泛适使用于阿里巴巴的各大站点，经历了“双11”期间高并发、大流量的检验，Dubbo框架非常成熟和稳固。Spring Cloud服务框架严格遵守Martin Fowler提出的微服务规范，社区异常活跃，它很可能成为微服务架构的标准。
