正文
关于Spring Boot整合，请看我在度娘上的搜索推荐结果：
Spring Boot整合Spring Cloud
众所周知，Spring Cloud是构建在一个Spring Boot应用的基础之上的，广义上说可以认为是SB应用把Spring Cloud整合进来了。谈到技术整合相信各位小伙伴轻车熟路：Redis整合、ElasticSearch整合、MyBatis整合…Spring Cloud的整合方式有点不太一样。SC它并非作为一个组件那么直接的加入到Spring Boot的ApplicationContext上下文/容器里即可，而是拥有自己一套独立的ApplicationContext上下文，然后通过上下文之间的关系（父子关系）完成和Spring Boot的“整合”。
如果说Mybatis、Redis这种整合方式是单个、直接方式；那么Spirng Cloud这种便是批量的、间接的方式，而正因为Spring Cloud有自己的Context上下文，所以它自己也就拥有整合其它组件的能力，这是非常重要的。
其实把Eureka、Hystrix、Ribbon等和Spring Boot直接整合也是可行的，但是这并不符合SB单应用的定位，并且Spring Framework和Spring Boot团队并不擅长解决和网络、云计算相关的技术，因此专门开设Spring Cloud子项目负责“接管”，保证了Spring Boot的纯粹性。
概念辨析
在正式开始Spring Cloud内容学习之前，我觉得有几个概念性的知识点需要先辨析一下，这个工作很有必要。
应用 vs 上下文 vs 容器
作为一个Java coder，这三个概念应该是常绕耳边的。不可否认，这三个概念非常重要，它亦会在本系列文章中贯穿始终，因为它就是用来沟通的“语言”嘛。但是，常常听见并不代表真的理解，特别这种“近义词”，本处就对这几个概念作出辨析。
以个人理解作出的小总结，若有误请留言指正，A哥一直都是个虚心向任何人学习的好孩纸
应用Application
应用是个比较大概念，比如一个QQ、微信我们均可称为是一个应用，而此处我们一般指的是Spring应用。比如我们一个Spring Boot工程就是一个SpringApplication实例，也就是一个Spring应用，另外它也称为主应用，一个工程主应用只会有一个。
通常来讲，一个应用只有一个上下文，所以应用和上下文这两个概念常常被误以为是对等的，其实非也，他俩并非同一层面的东东。举个例子：以Spring Boot为例，有些监听器注册在SpringApplication应用上作用于监听应用的变化（如生命周期监听器、初始化器等），它们并没有放进Spring容器内所以对上下文无感；而有些监听器是被放进容器里的，它的作用区域便就是和容器、Bean相关喽
另外，需要知道的是SB和SC的context上下文均是通过SpringApplication来构建的，但该SpringApplication实例在构建出Context后一般随即就“消失了”，这也是很多小伙伴误认为应用 == 上下文的原因之一吧；另外，父子容器概念属于context上下文级别非应用级别
上下文Context
同理，我们一般指的是Spring上下文，也就是ApplicationContext。在SB/SC里，实际使用的是ConfigurableApplicationContext的子类：AnnotationConfigServletWebServerApplicationContext和AnnotationConfigApplicationContext（前者由Spring Boot提供，后者由Spring Framework提供）。ApplicationContext是具有层级关系（父子关系）的，ApplicationContext#getParent()证明了这一点。
ApplicationContext上下文里的内容非常“丰富”，如Environment环境、BeanFactory工厂、协议解析器等等它都有，毕竟具备这些能力才算一个“合格的”上下文嘛。另外针对于在SC环境下的上下文情况需要有如下共识：
- SB和SC各自拥有一个独立的上下文，它们之前互相隔离却又有联系：SC上下文是SB的父上下文
容器
容器这个概念就更抽象了，在Java界也有不少如web容器、servlet容器等等，但是大多数情况下（包括本系列文章）我们一般指的是IoC容器，也就是Spring容器。
说明：IoC容器的实现其实不仅仅只有Spring，还有也比较流行的Google的开源库Guice，也是个非常好用轻量级DI管理库，有一些第三方开源组件如Eureka、Ribbon、Druid等都是基于它构建的，有兴趣可自己玩玩，也可参考我文章有写到~
对于Spring容器，我们有时候也叫它Bean工厂，也即是BeanFactory嘛。实际上ApplicationContext继承了BeanFactory接口，所以也是个容器（高级别容器），因此在概念上：上下文和容器这两个概念一般是可以对等的。
- 槽点：Spring的Bean容器为毛命名为BeanFactory而不是BeanContainer呢？
对于一个应用（如SB应用），ApplicationContext上下文/容器是可以有多个的。上下文之间的“隔离性”是很好的，后面会看到Ribbon、Feign等它们均会有自己的上下文，也就是学SC一样，通过上下文级别间接的完成和Spring Boot应用的整合。
那么问题来了：何时直接整合？何时需要自己创建一个上下文来管理呢？该问题就作为课后作业，留给读者你自行思考哈~
父容器 vs 子容器
父子关系是一种分层思想，被广泛应用于Spring容器/上下文的组织中，如HierarchicalBeanFactory。ApplicationContext#getParent()能证明Spring的上下文也是具有层级结构的。
同义词：父上下文、子上下文。但是切记不可说成父应用和子应用，因为一个Spring Boot工程只会有一个应用，而一个应用内可以有N多个上下文，它们之间可以有关，亦可无关，这是合理的。
