微服务的演变
SpringBoot和微服务没有关系，SpringCloud和微服务有关系
SpringCloud是一套解决微服务问题的技术
SpringCloud的底层使用了SpringBoot
微服务的演变
- 最开始的项目（如商城），单体项目，单服务器单数据库
- 快速开发，用户少，能用就行 ----> 公司业务变好，用户增加，访问量增加，项目经常卡死
- 增加应用负载能力（负载均衡），应用服务器集群（增加服务器数量）
- 灵活根据访问量增大来增加应用服务器集群的数量 ----> 数据量增加，新业务出现，数据库存取出问题（数据库承受不住过大访问）
- 数据库读写分离，并对数据库进行集群
- 数据库能承受的压力大幅提升 ----> 业务进一步增加，新功能使用数据库查询效率低，结果不准确；不同模块访问的频率不一样，需要频繁查询数据的模块觉得数据库查询效率太低，等问题
- 引入全文搜索，redis等技术（ES+Redis集群）
- 业务进一步扩大 ----> 不同业务模块代码耦合度太高，一个模块出问题，整个项目宕机；维护困难，每次更新代码都得在所有服务器重新部署；有些业务模块访问量太小，没必要部署在多台服务器，等问题
- 进行服务化，也就是把公司项目按照模块来进行分割，把每个模块都做成一个可独立运行，单独部署的应用程序（这就叫服务、微服务）。
- 可以根据需要部署服务器，被访问多的模块就多部署几个服务器；可以独立访问数据库，每个服务都有自己数据库.....
但是，服务化也有要解决的问题
-
服务之间怎么调用？【服务调用技术】订单服务想要调用到商品服务的数据，怎么调用？怎么调用更加的稳定，更加高效？
-
服务之间怎么负载均衡？【负载均衡技术】订单服务要调用商品服务，商品服务可能有很多个，怎么负载均衡
-
服务怎么被管理？【服务注册与发现技术】服务怎么定位？有故障了怎么处理？
-
故障怎么监控？【监控技术】微服务系统中业务模块很多，组件也很多，不同组件的指标不同，那么这些组件怎么进行监控
-
故障怎么定位？【链路追踪技术】微服务架构中，一个用户的请求会涉及到多个内部服务的调用，那么如何定位问题呢？
-
日志怎么分析处理？【日志分析技术】业务模块多了，日志也就多了，直接查看日志文件已经变的不显示了，那么如何对日志进行分析查找呢？
-
权限管理？【网关技术】微服务拆分服务之后，会有很多服务对外暴露接口，这些接口如何进行统一的权限处理呢？
-
服务调用出现问题怎么处理？【熔断，降级，限流】当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。怎么解决呢？
还有测试，自动化部署等等问题，都随着微服务的出现到来了
上面的每个问题要进行解决都需要在项目中引入一个或者多个新技术
而这些新技术我们一般称之为组件，也是微服务学习的重点，一整套技术，一套解决上述所有问题的解决方案，也就是SpringCloud。
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
官网：Microservices
