框架发展历程..

之前：

1. 三层架构 MVC模式
   1. 架构的作用：解耦
   2. 使用的开发框架：
      1. Spring---一个容器
         1. IOC：控制反转：由程序主动创建对象，变成程序被动的接收对象，需要什么拿什么就可以了
         2. AOP：切面（本质-动态代理）：在不影响业务的情况下进行功能扩展，一般情况下用于 日志、事物
         3. 是一个开源的Java框架，是一个容器
         4. 诞生的目的：解决企业级开发的复杂性问题
         5. 配置有些繁琐
      2. SpringBoot---自动装配
         1. SpringBoot是spring的升级版，简化Spring的复杂配置，新一代的JavaEE开发标准
         2. 特性：约定大于配置

发展：公司体系结构扩大，用户越来越多

2. 微服务架构---目前阶段

   1. 特点：将单个应用服务拆分，进行模块化，功能化
   2. 例如：服务：用户、支付、签到、娱乐...
   3. 用户越来越多，一个服务器支持不了，增加服务器，横向扩展，增加的是整个服务应用
   4. 问题：服务器A服务98%的资源，服务器B服务10%的资源，---此时需要做负载均衡
   5. 做业务功能拆分：将原有的整体的项目进行模块化 ， 功能化，用户、支付、签到、娱乐都是一个单独的项目，
   6. 问题：项目于项目之间如何通信？（没有拆分的时候是一个整体直接调用就行）本质---说到底也是调用接口，只是变成了远程调用接口
   7. 资源调度：哪一个服务模块需要的资源多就多分配一些
   8. 微服务架构问题：
      1. 分布式架构的核心问题：
         1. 如此多服务，客户端该如何进行访问？
         2. 如此多服务，服务间如何进行通信？
         3. 如此多服务，如何进行管理？
         4. 服务挂了，怎么办？
   9. 解决方案：
      1. Spring Cloud是一套生态，就是用来解决以上分布式架构的四个问题。
      2. Spring Cloud是基于Spring Boot的
      3. Spring Cloud NetFlix 第一套解决方案：
         1. API网关 ， zuul组件
         2. Feign HTTP的通信方式 同步并阻塞
         3. 服务注册与发现 ， Eureka
         4. 熔断机制 ， Hystrix
         5. 2018年底， 停止维护，生态逐渐脱节
      4. Apach Dubbo zookeeper 第二套解决方案
         1. API网关 ， 没有，要么使用第三方组件，要么自己实现
         2. Dubbo 一个高性能的基于Java的RPA的通信框架
         3. 服务注册与发现：zookeeper
         4. 熔断机制，没有　借助于Hystrix
         5. Dubbo并不完善
      5. SpringCloud Alibaba 第三套解决方案

3. 服务网格：Server Mesh

   1. 代表解决方案：istio

总结：

1. 使用微服务架构时的问题，要解决这些问题 所以用到很多组件：
   1. API网关，服务路由
   2. HTTP RPC框架，异步调用
   3. 服务注册与发现，高可用
   4. 熔断机制，服务降级