一、架构完整度对比
核心组件 | Dubbo | SpringCloud |
服务注册中心 | zookeeper | Spring Cloud Netflix Eureka |
服务调用方式 | RPC | REST API |
服务网关 | 无 | Spring Cloud Netflix Zuul |
断路器 | 不完善 | Spring Cloud Netflix Hysrix |
分布式配置 | 无 | Spring Cloud Config |
分布式追踪系统 | 无 | Spring Cloud Sleuth |
消息总线 | 无 | Spring Cloud Bus |
数据流 | 无 | Spring Cloud Stream 基于Redis，Rabbit,Kafka实现的消息微服务 |
批量任务 | 无 | Spring Cloud Task |
二、 Dubbo工作原理图
- Provider：暴露服务方称之为“服务提供者”。
- Consumer：调用远程服务方称之为“服务消费者”。
- Registry：服务注册与发现的中心目录服务称之为“服务注册中心”。
- Monitor：统计服务的调用次数和调用时间的日志服务称之为“服务监控中心”。
三、SpringCloud工作原理图
- Eureka负责服务的注册与发现，很好将各服务连接起来
- Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。
- Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示
- Spring Cloud Config 提供了统一的配置中心服务
- 当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息
- 所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用
- 监控我们使用Sleuth+Zipkin+springAdmin将所有的请求数据记录下来，方便我们进行后续分析
四、技术选型
1.架构完整度: 从上面对比，发现在架构完整性方面SpringCloud由于dubbo；
2.社区活跃度:与spring cloud相比，dubbo社区活跃度相对较低，社区活跃度的高低将影响项目维护成本，在社区活跃度很高时，一般项目中遇到的问题都可以在社区中找到响应的解决方案；
3.通讯协议:dubbo服务间通讯采用rpc，而spring cloud采用的时http的rest。rpc对于业务接口有很强的依赖性，生产者和消费者都需要依赖相同的接口，并且还需要通过严格的业务接口版本来进行管理，这种依赖在大型微服务项目将会成为一个很大的问题，相比rpc，rest更加轻量化，服务调用者和提供者间的依赖仅仅是一纸契约，一段文本，不存在代码层面的强依赖，服务提供者和调用者之间还可以通过不同的语言来实现，只需要提供rest接口就可以通讯。
4.技术改造和微服务开发：国内的开发团队选择dubbo的一个很重要的原因就是官方文档，dubbo提供了高质量的官方文档，而spring cloud都是英文版的，并且文档内容要比dubbo多的多，文档内容更偏向模块整合，要对每个模块的进行更深入的了解，需要查看更为详细的文档，对于中小型团队来说,阅读英文文档的成本必须要考虑的
