SpringCloud | 第一章: 初识 SpringCloud
前言
随着近几年微服务架构和Docker容器概念的火爆，让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在目前五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当年Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。
这个系列的文章，记录 SpringCloud 的学习历程。
什么是微服务
在了解微服务之前，先了解下传统的单体架构和分布式架构。
单体架构
传统的单体架构在当前还是比较常见，代表就是由一个应用，一个数据库，一个web容器就能运行，里面集成了所有的业务功能，通常是在一个服务或者war包中。修改某个功能时，需要所有服务重新打包。可能前期开发比较快，后期随着功能的增长，交互的周期会越变越长的。
优点
- 开发简单粗暴
- 人力成本低
- 性能较高，没有其他开销
- 较好维护，功能不复杂
缺点
- 扩展性，可靠性差
- 团队协作困难
- 部署不够灵活
适用场景
适用于短平快小项目
分布式架构
分布式架构，将应用程序根据不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。这样使整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有的组件通过交互来满足整体的业务需求。强调的是模块化部署，每个模块独立，分而治之。
优点
- 业务驱动
- 轻松扩展
- 容错机制
- 管理轻松
缺点
- 人员成本高
- 设备成本高
- 架构设计要求高
- 调试麻烦
适用场景
大业务、高并发、高可用场景。
微服务架构
微服务（MicroService）最早是由Martin Fowler 与James Lewis 于2014年共同提出，
微服务架构风格是一种使用系列微小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，为独立业务开发，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务可以使用的编程语言实现，以及不同数据存储技术，并保持分布式管理。
微服务架构则是分布式架构中的一种表现形式。
既然分布式架构已经可以解决大部分企业的需求了，那么我们为什么要研究微服务呢？先说说它们的区别；
- 微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务
- 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
- 微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。
- 微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
- 微服务的切分粒度会更小
Spring Cloud
SpringCloud是基于SpringBoot的一整套实现微服务的框架。它提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，基于SpringBoot，会让开发微服务架构非常方便。
- SpringCloud 是一个开发工具集,包含了多个子项目
- 基于SpringBoot 开发
- 对Netfilx开源组件进一步封装(爱看美剧的同学看见Netfilx应该很激动，没想到网飞这么厉害。)
本身SpringCloud包含了很多的组件，下面简单列举说明下(部分摘至纯洁的微笑)：
核心组件
SpringCloudGateway
Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Netflix ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。
SpringCloudNetflix
这可是个大boss，地位仅次于老大，老大各项服务依赖与它，与各种Netflix OSS组件集成，组成微服务的核心，它的小弟主要有Eureka, Hystrix, Zuul… 太多了
Netflix Eureka
服务中心，云端服务发现，一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务中心，任何小弟需要其它小弟支持什么都需要从这里来拿，同样的你有什么独门武功的都赶紧过报道，方便以后其它小弟来调用；它的好处是你不需要直接找各种什么小弟支持，只需要到服务中心来领取，也不需要知道提供支持的其它小弟在哪里，还是几个小弟来支持的，反正拿来用就行，服务中心来保证稳定性和质量。
Netflix Hystrix
熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。比如突然某个小弟生病了，但是你还需要它的支持，然后调用之后它半天没有响应，你却不知道，一直在等等这个响应；有可能别的小弟也正在调用你的武功绝技，那么当请求多之后，就会发生严重的阻塞影响老大的整体计划。这个时候Hystrix就派上用场了，当Hystrix发现某个小弟不在状态不稳定立马马上让它下线，让其它小弟来顶上来，或者给你说不用等了这个小弟今天肯定不行，该干嘛赶紧干嘛去别在这排队了。
Netflix Zuul
Zuul是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和Netflix流应用的 Web 网站后端所有请求的前门。当其它门派来找大哥办事的时候一定要先经过zuul,看下有没有带刀子什么的给拦截回去，或者是需要找那个小弟的直接给带过去。
SpringCloudConfig
俗称的配置中心，配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。就是以后大家武器、枪火什么的东西都集中放到一起，别随便自己带，方便以后统一管理、升级装备。
SpringCloudBus
事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。相当于水浒传中日行八百里的神行太保戴宗，确保各个小弟之间消息保持畅通。
SpringCloudforCloudFoundry
Cloud Foundry是VMware推出的业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题
其实就是与CloudFoundry进行集成的一套解决方案，抱了Cloud Foundry的大腿。
SpringCloudCluster
Spring Cloud Cluster将取代Spring Integration。提供在分布式系统中的集群所需要的基础功能支持，如：选举、集群的状态一致性、全局锁、tokens等常见状态模式的抽象和实现。
如果把不同的帮派组织成统一的整体，Spring Cloud Cluster已经帮你提供了很多方便组织成统一的工具。
SpringCloudConsul
Consul是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对.
Spring Cloud Consul封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
之后的文章，也基本上是讲解这些组件的使用了。
其他组件
当然，除了以上列举的，还有比如Spring Cloud Security、Spring Cloud Sleuth、Spring Cloud Data Flow、Spring Cloud Stream、Spring Cloud Zookeeper等等。
微服务两大阵营
Dubbo与SpringCloud
两者得对比（以下摘自纯洁的微笑）
| 核心要素 | Dubbo | Spring Cloud |
|---|---|---|
| 服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka |
| 服务调用方式 | RPC | Spring Cloud Netflix Eureka |
| 服务注册中心 | Zookeeper | REST API |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 服务网关 | 无 | Spring Cloud Netflix Zuul |
| 分布式配置 | 无 | Spring Cloud Config |
| 服务跟踪 | 无 | Spring Cloud Sleuth |
| 消息总线 | 无 | Spring Cloud Bus |
| 数据流 | 无 | Spring Cloud Stream |
| 批量任务 | 无 | Spring Cloud Task |
| …… | …… | …… |
从上图可以看出其实Dubbo的功能只是Spring Cloud体系的一部分。
这样对比是不够公平的，首先Dubbo是SOA时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而Spring Cloud诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了Spirng、Spirng Boot的优势之上，两个框架在开始目标就不一致，Dubbo定位服务治理、Spirng Cloud是一个生态。
如果仅仅关注于服务治理的这个层面，Dubbo其实还优于Spring Cloud很多：
Dubbo支持更多的协议，如：rmi、hessian、http、webservice、thrift、memcached、redis等。Dubbo使用RPC协议效率更高，在极端压力测试下，Dubbo的效率会高于Spring Cloud效率一倍多。Dubbo有更强大的后台管理，Dubbo提供的后台管理Dubbo Admin功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等诸多强大的功能。- 可以限制某个 IP 流量的访问权限，设置不同服务器分发不同的流量权重，并且支持多种算法，利用这些功能我们可以在线上做灰度发布、故障转移等。
所以Dubbo专注于服务治理；Spring Cloud关注于微服务架构生态。
如何选择
可能很多人正在犹豫，在服务治理的时候应该选择那个框架呢？如果公司对效率有极高的要求建议使用 Dubbo，相对比 RPC 的效率会比 HTTP 高很多；如果团队不想对技术架构做大的改造建议使用 Dubbo，Dubbo 仅仅需要少量的修改就可以融入到内部系统的架构中。但如果技术团队喜欢挑战新技术，建议选择 Spring Cloud，Spring Cloud 架构体系有有趣很酷的技术。如果公司选择微服务架构去重构整个技术体系，那么 Spring Cloud 是当仁不让之选，它可以说是目前最好的微服务框架没有之一。
最后，技术选型是一个综合的问题，需要考虑团队的情况、业务的发展以及公司的产品特征。最炫最酷的技术并不一定是最好的，选择适合自己团队、符合公司业务的框架才是最佳方案。技术的发展永远没有尽头，因此我们对技术也要保持空杯、保持饥饿、保持敬畏！
SpringCloud 版本说明
官网给出了目前各版本对应组件的版本信息:
SpringCloud E版 对应SpringBoot 1.5.xSpringCloud F版 对应SpringBoot 2.x
官网：Finchley builds and works with Spring Boot 2.0.x, and is not expected to work with Spring Boot 1.5.x
译：Finchley构建使用Spring Boot 2.0.x，预计不会与Spring Boot 1.5.x一起使用
因此选择最新的SpringBooot的版本应该是2.0.6.RELEASE，对应的SpringCloud版本为Finchley.SR2
参考资料
- 老齐的IT加油站
- 趔趄的猿
- 纯洁的微笑
- SpringCloud 中文文档