在学习一个新东西的之前，得了解两件事情，学的是什么？解决了什么问题？
那么接下来就围绕这两个问题来谈一谈Spring Cloud。
什么是Spring Cloud
现在微服务是一个非常火热的话题，说道微服务那必然少不了Spring Cloud，那Spring Cloud到底是什么呢？
Spring Cloud 不是一门技术，而是一种生态，在这个生态里面由许许多多的技术所组成。
那为什么要学Spring Cloud呢？这个生态又有哪些组成呢？在介绍生态之前先来了解一下，为什么学习Spring Cloud。
Spring Cloud 解决了什么问题？
说到这里，那不得不从头说起，从最初的Java SE 过度到 JavaWeb接着到框架（SSM、SSH），最后来到Spring Cloud。
分析一波：
- JavaWeb和JavaSE关系，硬要说技术点没有重叠，只是单纯的扩展，抬走，下一位。
- 框架与JavaWeb，很明显的感觉得到框架，大量的简化了访问接口，接受属性等。
虽然SSM写起来比 JavaWeb 原生的Servlet 好了许多，但是有一件事不可避免，那就是配置文件。
随着添加的内容越来越多，配置文件也越来越多，越来越复杂，所以前人们就搞了一个Spring Boot！
Spring Boot （约定大于配置），学到了SpringBoot 就能发现真正意义上的优化，避免了搭建项目的时间。
但是随着时间的流逝，一个正常企业的发展，项目的业务功能也越来越繁琐复杂，一个单体应用的程序服务器顶不住啦！
这时候就提出来另外一个解决方案，一个服务器顶不住，那就来两个，两个顶不住就来四个。
渐渐地，服务器顶住了，但是维护的成本也越来越高了，因为往往我们改动一个小小的功能，就要把整个项目重新打包，然后部署到每个服务器上，除了成本的提升还有另外一个问题。
在一个项目当中，有的功能占用的服务器资源非常少，而有的功能需要占用大量的资源，在这种情况下，大佬们又有了新的想法，既然有的功能常用，有的不常用，那么就把功能以模块的形式提取出来，然后占用少的可以分一起，占用多的可以多来几个服务器，这样压力也下去。嗨呀，简直妙啊！
这个解决方案一出来，很好很强。但是问题随之而来。
- 拆分后服务很多，客户端该访问谁？
- 服务这么多，服务与服务之间又如何通信？
- 服务那么多，又如何去管理？
- 某服务炸了，又咋整？
这时候 Spring Cloud 站出来了，它说统统都是我的。问题解决，天下太平！
解决方案
上面的内容只是讲述了，Spring Cloud 是什么，又有哪些问题。下面就是真正的解决方案。
Spring Cloud NetFlix 就是其中一套解决方案，是一站式的解决。（该项目没维护了，但是奈何足够强大成熟，所以用的人还是非常多）
Spring Cloud Alibaba 也是其中一套解决方案，同样的是一站式解决。（新秀，以后可能会替代 netFlix）
Apache Dubbo Zookeeper 半自动，没有包含所有功能，自行整合。
PS：注意上面我所说的是一套，并不是单独一个，是由多个东西组合而成。
Spring Cloud NetFlix
既然 NetFlix 可以解决上面的四大问题那就来一个一个来说明一下。
问题一：服务很多，客户端该访问谁？
采用一个Api网关 ：zuul 组件
问题二：服务这么多，服务与服务之间又如何通信？
采用：Feign，Feign基于HttpClinet也就是Http通信方式，同步（意味着会阻塞）、Ribbon
问题三： 服务那么多，又如何去管理？
采用：服务注册和发现 Eureka
问题四：某服务炸了，又咋整？
熔断机制：Hystrix等等。
总结
说到底，微服务的出现就是因为单体应用到最后功能的复杂化，导致应用的臃肿，各个功能模块使用的效率不同，在一起部署利用率不高。（悄悄的说还是网络不可靠！要是有本地化的网速这些还是事？）
根据上面出现的情况核心四个点就是：
- api网关分发
- 网络通信：http、rpc
- 服务的注册和发现
- 熔断机制
