SpringBoot系列：10. 简述微服务架构发展史以及微服务要解决的核心问题

前言

1. 本章节主要简单回顾一下"微服务的发展"以及微服务要解决的几个核心问题。

1. 简单回顾架构发展史

1. 刚开始是三层架构MVC，接下去更新除了Spring框架

2. Spring：轻量级的Java开源框架，容器。
   ⑴ IOC(控制反转)
   - 数据都是从容器中获取，不需要像以前那样new出来。
   - 数据从容器获取，直接get即可得到。
   - 容器中不存在的数据，需要我们先将数据注入到容器中去。
   ⑵ AOP(切面)
   - 本质：动态代理
   - 不影响原业务代码，实现动态增加功能
   - 应用场景：日志，事务…

3. SpringBoot
   - Spring的升级版
   - 新一代JavaEE的开发标准，开箱即用，拿来就可以用。
   - 自动帮我们配置非常多的东西。
   - 特性：约定大于配置(比如某一个类必须放在某一个路径下才可以 被识别，不然用不了)

4. 公司体系变大，用户增多，慢慢出现了"微服务架构"。
   ⑴ 微服务解释
   - 模块化
   - 功能化
   ⑵ 对用户功能化和模块的说明
   (用户模块，支付模块，签到模块，娱乐模块…)原来我们会将这些模块写到一个SpringMVC大型项目中去，若一个服务器人太多了，一台服务器解决不了，就多增加一台服务器，无限增加，这样通过增加多台服务器来缓解单一服务器需要承载的压力。

---

1. 对于微服务模块与功能化演进，简单说明一下两点演进过程↓：
   ⑴ 框架演进一：当出现服务器A占用98%资源，服务器B占用10%资源时，就会出现资源分配不合理的情况，因此在分配服务器资源时应尽量做到每台服务器资源分配的均衡控制，要实现资源的合理分配，就需要使用"负载均衡"来解决此问题(多服务器来平摊压力)。
   ⑵ 框架演进二：若出现某一模块，比如"用户模块"中的用户非常多，而去签到的人非常少，此时就需要给用户多一点的服务器资源，然后给签到少一点的服务器资源—>因此只有将原来的整体项目采用模块化的方式，来解决"用户多，签到少"的情况–>因为采用模块化之后，用户就是一个单独的项目，签到也是一个单独的项目。当两个项目之间通信时，用户在服务器A点签到，就需要在B服务器去生成一条签到记录只有这样才能模块化。

2. 微服务架构的四个核心问题 及 解决

1. 微服务就是分布式

• 微服务架构会遇到的四个核心问题？
  ⑴ 问题一：服务(项目/模块)太多，客户端如何去访问？
  它需要一个共同的接口(API)来处理，解决这个问题。
  ⑵ 问题二：服务(项目/模块)太多，服务之间如何进行通信？
  ⑶ 问题三：服务(项目/模块)太多，如何进行统一的管理？
  -> 此时应该有一个统一的管理平台
  ⑷ 问题四：服务挂了，怎么办？

---

2. 微服务架构问题解决方案
   ⑴ SpringClody，是一套生态，用来解决以上分布式架构的四个问题，但是想使用SpringClod就必须掌握SpringBoot，因SpringCloudy是基于SpringBoot。
3. 以下说明几套解决上面分布式架构问题的方案↓：
   ➀ 第一套：由此出来一个公司"Spring Cloud Netflix"，提出了一套解决上面分布式问题的解决方案：
   - 问题一：提出"Api网关"来解决-(统一服务治理：zuul组件)
   - 问题二：提出"Feign"来解决–>(基于HttpClient–>基于Http通信方式，同步并阻塞)
   - 问题三：提出"服务注册与发现，Eureka"来解决。
   - 问题四：提出"熔断机制，Hystrix"来解决。
   ------>上面是该公司自己提出的一套解决上面分布式架构出现的四个问题。但是于2018年底，NetFlix宣布无限期停止维护，生态不在维护，就造成该技术与现在脱节了。导致很少人用。
   ➁ 第二套：Apache Dubbo zookeeper
   - 问题一：“Api网关"没有(只能找第三方组件或自己写实现)
   - 问题二：提出"Dubbo思想”，利用RPC框架来解决通信的问题
   - 问题三：提出"服务注册与发现：zookeeper"来解决。
   - 问题四："熔断机制"没有 (借用第三方的Hystrix来解决)
   ------>上面出的一套解决分布式架构的方案不完善，但是Dubbo之前停更现在又开始更新。
   ➂ 第三套：SpringCloud Alibaba 一站式解决方案
   ➃ 第四套：目前程序员又提出了一种方案：“服务网格”，下一代微服务标准，server Mesh，对应解决微服务架构出现的问题如下↓：
   - 解决上面问题的方案称为：istio(未来可能需要掌握)

2.1 微服务架构的小结

1. 小结：上面每一个公司出的各种方案，都是在解决同样的几个问题
   ⑴ 问题一：Api网关：服务路由
   ⑵ 问题二：Http或者RPC框架：类似异步调用(远程调用，两台电脑上面的方法互相被调用)
   ⑶ 问题三：服务注册与发现：解决高可用问题，设计到服务，方法之间的管理
   ⑷ 问题四：熔断机制：服务降级(就是服务崩了，怎么办)

2. 为什么要解决上面这些问题：
   ⑴ 关键本质：在于"网络不可靠"。