Spring Cloud 比较

一、简介

1、SpringCloud：一套微服务架构下的一站式解决方案，理念就是解决我们在微服务架构中遇到的任何问题；
2、SpringCloudAlibaba：阿里实现对SpringCloud组件进行扩展；
3、SpringCloudTencent：腾讯实现对SpringCloud组件进行扩展；

二、区别

名称	SpringCloud	SpringCloudAlibaba	SpringCloudTencent
注册中心	Eureka、Consul	Nacos	polaris-discovery
配置中心	SpringCloud Config	Nacos	polaris-config
网关	SpringCloud Zuul	SpringCloud Gateway	polaris-router
负载均衡	Ribbon	Loadbalancer	polaris-loadbalancer
熔断降级	Hystrix	Sentinel	polaris-circuitebreaker/ratelimit
服务调用	Feign	OpenFeign	Feign

Dubbo 与 Spring Cloud 的区别

Dubbo 是阿里巴巴开源的RPC框架，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

两者都是现在主流的微服务框架，但却存在不少差异：

初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理
生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。
组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper

SpringCloud生态丰富，功能完善，更像是品牌机；Dubbo则相对灵活，可定制性强，更像是组装机。

两者的生态对比：

功能	Dubbo	SpringCloud
分布式配置	无	Spring Cloud Config、Nacos
服务注册中心	Zookeeper	Eureka(主流）、Nacos、Consul、zookeeper
服务调用方式	RPC基于Dubbo协议	REST API 基于Http协议
服务监控	Dubbo-Monitor	Spring Boot Admin
熔断器	不完善	Hystrix、Sentinel
服务网关	无	Zuul、Gateway
服务跟踪	无	Sleuth+Zipkin、SkyWalking
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task
信息总线	无	Spring Cloud Bus

Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

使用 Dubbo 构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果使用者是一名高手，那这些都不是问题。

而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

Spring Cloud

springcloud的版本说明：
- springcloud项目是由多个独立项目集合而成的，每个项目都是独立的，各自进行自己的迭代和版本发布
- springcloud的F版本是基于springboot的2.0.x构建，之前的是基于springboot的1.5.x构建
SpringCloud的5大核心组件：
1. Eureka：注册中心
2. Zuul：服务网关
3. Ribbon：负载均衡
4. Feign：服务调用
5. Hystix：熔断器
将微服务划分为外部服务和内部服务
- 外部服务：以终端划分的外部服务，如api-admin、api-pc、api-applets、api-app、api-h5，提供对外(用户)的API 接口数据。
- 外部服务提供Feign服务通信调用内部服务获取数据。
- 内部服务：如订单服务、用户服务、商品服务、内容服务等内部服务，提供增删改查(搜索)等基本数据库操作
微服务介绍
- 微服务架构，重点在一个微字，简单的说就是将单体服务拆分成更多更小的服务，每个服务都是一个独立的，可以运行的项目。我们来看一张图：
- 这么拆有什么好处？
  - 没有拆分之前，你修改一个功能，进行测试，部署上线，可能要一个月，要考虑对其他服务的影响，考虑其他人改动代码的影响，还要对整个系统功能全量回归测试，费事费力，可能上线基本上就得1个月，那么服务拆分之后，可以独立打包，测试，部署，升级，只需要关心自己的功能，随时可以安排上线。而且每个微服务都有清晰的任务划分，利于扩展。总之，拆分之后对于开发人员来说是非常爽的一件事。
  - 有好处那就有缺点，服务多了之后，要考虑怎么管理维护，使用的架构也不一样，技术学习成本也会上升。
微服务架构常见的问题
- 一旦决定采用微服务架构系统，就会面临以下几个不能饶过的问题：
  - 这么多服务，怎么管理？
  - 这么多服务，他们之间怎么通讯？
  - 这么多服务，用户应该怎么访问他们？
  - 这么多服务，一旦出现问题了，怎么进行自处理？
  - 这么多服务，一旦出现问题了，怎么进行问题排查？
- 上面的这些问题，是任何一个微服务设计者都绕不过去的，市面上一些微服务架构产品就是提供了一系列的组件来解决上述问题。
- 来看一个常见的微服务架构图