【二】Spring Cloud 入门 三步走Spring Cloud 入门 三步走

1、是什么

1）、官网说明：

​ SpringCloud,基于SpringBoot提供了一套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。

​ SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建 分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它 们都可以用SpringBoot的开发风格做到一键启动和部署。

​ SpringBoot并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 SprinqBoot风格进行再封装屏蔽掉了复杂得配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

2）、总的来说：

Spring Cloud = 分布式微服务架构下的一战式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。

3）、SpringCloud与SpringBoot是什么关系？

1、SpringBoot专注于快速方便的开发单个个体微服务。

2、SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的_个个单体微服务整合并管理起来， 为各个微服务之间提供 ，配置管理 、服务发现 、断路器、路由、微代理’、事件总线、全局锁’、决策竞选、分布式会话等等集成服 。

3、SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot,属于依赖的关系.

4、SpringBqot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

4）、Dubbo是怎么到SpringCloud的？那些优缺点让你去技术选型？

1）、目前成熟的互联网架构（分布式+服务治理Dubbo）

2）、我们把springCloud VS Dubbo进行一番对比

活跃度：

​ 看项目曲线波动

​ dubbo：https://github.com/dubbo

​ spring cloud：https://github.com/spring-cloud

对比结果：

@	Dubbo	Spring Cloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务网关	无	Spring Cloud Netflix Zuul
断路器	不完善	Spring Cloud Netflix Hystrix
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task

​ 以上列举了一些核心部件，大致可以理解为什么之前说Dubbo只是类似Netflix的一个子集了吧。当然这里需要申明一点，Dubbo对于上表中总结为“无”的组件不代表不能实现，而只是Dubbo框架自身不提供，需要另外整合以实现对应的功能，比如：

• 分布式配置：可以使用淘宝的diamond、百度的disconf来实现分布式配置管理。但是Spring Cloud中的Config组件除了提供配置管理之外，由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来。
• 服务跟踪：可以使用京东开源的Hydra
• 批量任务：可以使用当当开源的Elastic-Job
• ……

​ 虽然，Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。

RPC vs REST

​ 另外，由于Dubbo是基础框架，其实现的内容对于我们实施微服务架构是否合理，也需要我们根据自身需求去考虑是否要修改，比如Dubbo的服务调用是通过RPC实现的，但是如果仔细拜读过Martin Fowler的 microservices 一文，其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢？

先来说说，使用Dubbo的RPC来实现服务间调用的一些痛点：

• 服务提供方与调用方接口依赖方式太强：我们为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，因此不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，往往一个依赖很多服务的上层应用，每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。
• 服务对平台敏感，难以简单复用：通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。

相信这些痛点也是为什么当当网在dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一。

小结：Dubbo实现了服务治理的基础，但是要完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增加出来的压力，这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud，相对来说每个环节都已经有了对应的组件支持，可能有些也不一定能满足你所有的需求，但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

总的来说：

**最大区别：**SpringCloud拋弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问 题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的 微服务环境下，显得更加合适。

品牌机与组装机的区別

很明显，Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的拳头项目，它也能够与Spring Framework、 Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。使用Dubbo构建的 微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人 不怎么放心，但是如果你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的 兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

社区支持与更新力度

最为重要的是，DUBBO停止了5年左右的更新，虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级（比如 当当网弄出了DubboX),这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能 力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。

2、能干嘛

1、Distributed/versioned configuration(分布式/版本控制配置)

2、Service registration and discovery(服务注册与发现）

3、Routing(路甶）

4、Service-to-service calls(服务到服务的调用）

5、Load balancing(负载均衡配置)

6、Circuit Breakers(断路器)

7、Distributed messaging(分布式消息、管理)

8、。。。。。。。

3、去哪下

​ 官网文档：http://projects.spring.io/spring-cloud/

​ 参考资料：

​ 1）、中文版的组件说明：https://springcloud.cc/spring-cloud-netflix.html

​ 2）、开发的API说明：

​ 英文版：http://cloud.spring.io/spring-cloud-static/Dalston.SR1/

​ 中文版：https://springcloud.cc/spring-cloud-dalston.html

​ 3）、springcloud中国社区：http://springcloud.cn

​ 4）、springcloud中文网：http://springcloud.cc

4、怎么玩

1、服务的注册与发现（Eureka)

2、服务消费者（rest+Ribbon)

3、服务消费者（Feign)

4、断路器（Hystrix)

5、断路器监控(Hystrix Dashboard)

6、路由网关(Zuul)

7、分布式配置中心(Spring Cloud Config)

8、消息总线(Spring Cloud Bus)

9、服务链路追踪(Spring Cloud Sleuth)

ALL: http://springcloud.cc