SpringCloud介绍
微服务是什么
单体项目
在互联网刚开始的年代，传统的单体项目，一般是一个服务器，对少量的用户足矣。这时候，开发一套系统，可以提供少量的(相比于现在)服务。并发性不大，服务器性能不需要太好都可以跑得好好的。这个时代我没有经历过。
单体项目分布式
互联网稍稍发展起来了，一台服务器好像支撑不大住。这时候，聪明的程序员们就说，如果一个系统撑不住，那就启动两个来为客户服务呀。所以架构就变成这样，用户，可以把请求落到两个随便一毛一样的系统上面，提供服务是一致的。这时候一般考虑 sessionid 的共享。
初代前后端分离
下一个发展阶段，即很多企业发现，如果一台机器，需要做数据库操作，还需要做界面层的渲染，服务器的压力太大。这时候出现了初代前后端分离，后端访问数据库的速度可以使用 redis 加成，而前端项目，大部分是渲染成页面提供给用户。所以这时候的架构演变成下面：这种情况可以根据不同的需求进行拓展，拓展前端，拓展后端都还行。
微服务时代
很快，需求出现爆炸性的增长，后端服务器如果还是单体项目，无论是部署，拓展都显得特别笨重。如果后端服务需要新增一个实例，那么我们都需要手动重新配置前端服务。如果突然之间需要新增多个实例，那么程序猿将会累死累活。所以这时候，急需一个可以自治的生态系统，将拓展的事情交给程序去设定。 这时候，Java 界男神 Martin Fowler 提出了 microservice 架构(原文链接)。即我们将公司所在领域，按照一定的子域进行划分，每个子域自成一个小服务。此时，拓展就变得简单，我们可以给并发量大的服务拓展多几个服务，而并发小的，或者任务不重但是缺一不可的，单机或者少一点服务存在。而上一层路由层，通过网络与不同服务之间进行通讯，共同服务于用户。 而微服务还有另外一个元素，那就是自治能力、监控能力。打个比方，如果前端服务需要增加多台，系统可以自动发现，并将其加入”服务团队”中，快速的进入工作状态。 所以微服务架构急切需要一种，自带管理者，统一入口的软件架构。而在当今社会，常见的就有 Dubbo SpringCloud 以及 SpringCloudAlibaba 等一系列的生态框架出现。 那么架构现状，也发生了质的变化：
最终前后端分离
正在此时，前端由于 vue AngularJS react 的兴起，也没闲住，也发生了剧烈的变化。ES (JS 的现代叫法)不再单纯的操作 document 而是将 document 交给框架，开发者只需要关注数据的变化即可，框架会自动根据数据的变化去修改 document 的展示。所以这时候，会出现前端直接分离出来，由前端开发者自己开发，自己编织架构，后端只提供数据服务的局面。走到这里，前端真正的独立出来，后端开发者不再需要编写 MVC 的页面。前端开发者后期维护也变得简单，因为一个前端项目修改不再需要前端和后端结对编程了。
微前端化
由于业务量爆棚，前端也出现了后端的老路。然后前端也就走了后端的发展路线，一个前端再也支撑不住，所以前端也要分出来不同的业务团队，这时候，前端也就进行了微服务化。不同的业务有不同的模块，然后一个总视图进入前端，统领所有的业务服务模块。这块就不画出来了。
SpringCloud是什么
SpringCloud 是一系列套件的统称，不单单是一门技术框架。而这些套件，恰好是我们做微服务系统的时候，常常使用的套件，包含 注册中心 配置中心 路由器 熔断器 监控 等微服务所需要的框架。套件什么的，做好部署运维，那么就可以将精力集中在业务服务的开发。
为什么选择SpringCloud
常见的面试题就是：为什么使用 SpringBoot ？ 标准答案：因为 Spring 官方提供了自动装配的规范，由第三方框架(MyBatis 等)去实现。然后版本号规约放置于 SpringBoot 的顶级父类里，这样当我们使用对应版本的 SpringBoot 的时候，依赖进来的需要使用的第三方框架也是框架官方提供的，兼容性不错的版本。 而恰恰好，SpringCloud 就是这样集成而来的，所以兼容性问题，并不需要关心太多。 当初选择这个框架，是因为我感觉上手简单，而且套件齐全。公司项目肯定想要稳定，拓展性好的框架。因为 Spring 框架让我放心，因为他是 Spring 公司的。其二，官方提供套件的合成，也不会出现有些不兼容的现象。因为 SpringBoot 的加成，统一的父类，放心的整合。 在快速做一个小服务也是十分的方便，只要把统一的配置放置于 config-server 我在开发新的业务服务的时候，不需要过多的关注他的配置的东西 (比起 Spring 时代的 xml 地狱简直不要太方便)
SpringCloud常用组件
微服务套件
推荐框架
作用
可替换框架
注册中心
Eureka
微服务系统的中心，可用于服务的注册以及服务之间的发现
ZooKeeper Consul
配置中心
ConfigService
业务服务的配置中心，将业务服务通用、系统配置放置于此，服务启动即可发现并应用配置
Apollo
路由器
Gateway
微服务生态总入口，需要请求服务只能通过于此。相对的，权限控制、登陆拦截都落在此处。
Nginx Nodejs自开发
熔断器
Hystrix
熔断器，用于熔断服务的连接。如果服务负载量过大、频繁报错，将会像保险丝一样断开服务，让他休息一会儿再起来
-
熔断监控
Turbine
熔断器的监控视图，用于监控熔断器的情况，以便人为干涉
-
消息通知
Stream
用于服务之间的消息通知，进行封装后可以不需要关注分布式锁(谁来处理的问题)
-
契约开发
Contract
微服务中，进行 TDD 开发的模拟第三方服务返回数据的套件
-
老夫认为，项目刚刚初始，Eureka Config Gateway Stream 都是初始就要考虑的必备品。