在学习SpringCloud前先了解以下概念问题：
SpringCloud是做什么的？
从官网上找到答案：
Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry.
英语不好，简单翻译就是：
Spring Cloud为开发者提供了快速构建分布式系统中的一些通用模式（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式 会话，群集状态）。 分布式系统的协调导致了样板模式， 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。 他们将在任何的分布式环境中正常工作，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等托管平台。
什么是微服务?
简单来说微服务是系统架构上的一种设计风格，它的主旨是把原本独立的服务拆分成多个小型服务，这些个小型服务在自己独立的进程下运行，各个服务之间通过HTTP的RESTFUL API进行通信协作。被拆分的每一个小型服务都围绕着系统中的某一项或一些耦合度高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立的部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。
知道了微服务，那个微服务和独立的单体系统有什么区别呢？
在以往传统的系统架构中，我们针对一个复杂的业务需求通常使用对象或者业务类型来构造这个单体项目。在项目中我们通常将业务需求分为三个部分：前端展现，后端处理，数据库。在业务发展初期，将所有的业务放在一个应用里进行开发，部署，测试还是很容易实现的。但是，随着业务发展，需求增加，我们会在这个项目项目上不断的增加不同的业务模块，提供更多的接口模块。在这种情况下单体应用的问题就逐渐的体现出来了：由于单体应用是一个进程，我们修改一个很小的功能，为了部署上线总会影响其他功能的正常运行。并且单体应用中这些功能模块的使用场景、并发量，消耗的资源都各个不同，对于资源的利用又相互影响，这样使我们对各个业务的系统容量很难给出较准的评估。所以，单体应用，时间越长，业务发展越大，维护的成本就会越大，并且越来越难以控制。
为了解决单体应用变的庞大臃肿而导致的难以维护等问题，微服务架构诞生并被大家关注。
我们将系统中不同功能模块才分成多个不同的服务，这些服务都能够独立的部署运行和扩展。由于每个服务都在自己的进程内，在部署上有稳固的边界，这样每个服务的更新都不会影响其他的服务正常运行，并且由于是独立部署的，我们可以更精准的为每个服务评估性能容量，通过配合服务间的协作流程可以更容易的发现系统的瓶颈所在，以及给出较为准确的系统级性能容量。
如何实施微服务
对于单体应用的实施我们都非常了解了，也很简单。但是一旦单体应用被拆分成多个服务，那么久会引起许多单体应用不会出现的问题：
- 运维的新挑战：在微服务架构中，运维人员需要维护的进程数量会大大增加，对这些进程编排和组织不是一件容易的事。运维过程需要更多的自动化。对运维人员所具备的技能要求也大大提高。
- 接口的一致性：虽然我们拆分了服务，但是业务逻辑上的依赖并不会消除，只是从一个单体应用中的代码依赖变成了服务之间的通信依赖。而当我们对原有接口进行一些修改，那么交互也需要协调这样的改变来进行发布，以保障接口的正确调用。所以我们需要更完善接口和版本管理，或者严格的遵守开闭原则。
- 分布式的复杂性：由于拆分后各个微服务都是独立运行在各自的进程中，他们只能通过通信来进行协同工作，所以分布式环境问题都微服务架构系统设计时需要考虑的重要因素，比如：网络延迟，分布式事物，异步消息等一系列问题。
微服务的九大特性
- 服务组件化
- 按业务组织团队
- 做“产品”的态度
- 智能端点和哑管道
- 列表内容
- 去中心化自理
- 去中心化管理数据
- 基础设施自动化
- 容错设计
- 演进式设计
为什么选择SpringCloud?
微服务很火，那么一个微服务架构我们需要考虑很多问题，比如服务治理（dubbo/dubbox等）、分布式配置管理（Disconf/Diamond等）、批量任务、服务跟踪等等，当我们搜索微服务架构的实施方案是会发现，大部分的是分享的主要以理论和一些粗轮廓框架为主，针对于上面的问题整合了来自不同公司或者组织的很多开源框架，并加入自身业务的优化，所以找不到一个完全相同的架构方案。
前面分析过微服务的优点和缺点，这些缺点通常是这些框架出现的源头，都是为了解决或者弥补业务拆分后所引起的诸多问题来设计出的方案。当我们准备实施一个微服务架构的时候，为了避免前辈们踩过的坑，我们不得不在这些核心问题上选择不同的框架，那么选择又如此之多，这必然会导致技术选型初期需要花费大量精力来进行调研、分析、实践。
SpringCloud的出现可以说是对微服务架构的巨大支持和强力的技术后盾。我们不用再像以前一样针对某个问题来选择相应的架构来解决。SpringCloud是一个综合性解决微服务架构的框架，整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建一些非常优秀的边缘组件。
SpringCloud简介
SpringCloud简单来说就是一个分布式系统开发工具包，基于SpringBoot简化了配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等
Spring Cloud组成
Spring Cloud的子项目，大致可分成两类：
一类是对现有成熟框架”Spring Boot化”的封装和抽象，也是数量最多的项目；
二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。
SpringCloud子项目及介绍
Spring Cloud Config： 配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以 及Subversion。
Spring Cloud Bus： 事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。
Spring Cloud Netflix： 针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
Netflix Eureka： 云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。
Netflix Hystrix： 容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
Netflix Zuul： 边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。
Netflix Archaius： 配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
Spring Cloud for Cloud Foundry： 通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
Spring Cloud Sleuth： 日志收集工具包，封装了Dapper,Zipkin和HTrace操作。
Spring Cloud Data Flow： 大数据操作工具，通过命令行方式操作数据流。
Spring Cloud Security： 安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
Spring Cloud Consul： 封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
Spring Cloud Zookeeper： 操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。
Spring Cloud Stream： 数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
Spring Cloud CLI： 基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。
SpringCloud开发要素
Codebase： 从一个代码库部署到多个环境
Dependencies： 使用显式的声明隔离依赖，即模块单独运行，并可以显式管理依赖
Config： 在系统外部存储配置信息
Backing Services： 把支持性服务看做是资源，支持性服务包括数据库、消息队列、缓冲服务器等
Build, release, run： 严格的划分编译、构建、运行阶段，每个阶段由工具进行管理
Processes： 应用作为无状态执行
Port binding： 经由端口绑定导出服务，优先选择 HTTP API 作为通用的集成框架
Concurrency： 并发性使用水平扩展实现，对于web就是水平扩展web应用实现
Disposability： 服务可处置性，任何服务可以随意终止或启动
Dev/prod parity： 开发和生产环境保持高度一致，一键式部署
Logs： 将日志看做是事件流来管理，所有参与的服务均使用该方式处理日志
Admin processes： 管理任务作为一次性的过程运行（使用脚本管理服务启动和停止）