Spring 能做什么

Spring 的能力

整个 Spring 全家桶可以做什么？

• 微服务（microservices）：大型项目的各个功能模块拆分成一个一个单独的服务

• 响应式 reactive：这里涉及到异步阻塞的概念，想起多年前看到的一个例子

  老张爱喝茶，废话不说，煮开水。出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。
  1 老张把水壶放到火上，立等水开。（同步阻塞）老张觉得自己有点傻
  2 老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。（同步非阻塞）老张还是觉得自己有点傻，于是变高端了，买了把会响笛的那种水壶。水开之后，能大声发出嘀~~~~的噪音。
  3 老张把响水壶放到火上，立等水开。（异步阻塞）老张觉得这样傻等意义不大
  4 老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。（异步非阻塞）老张觉得自己聪明了。
  所谓同步异步，只是对于水壶而言。普通水壶，同步；响水壶，异步。虽然都能干活，但响水壶可以在自己完工之后，提示老张水开了。这是普通水壶所不能及的。同步只能让调用者去轮询自己（情况 2 中），造成老张效率的低下。所谓阻塞非阻塞，仅仅对于老张而言。立等的老张，阻塞；看电视的老张，非阻塞。情况 1 和情况 3 中老张就是阻塞的，媳妇喊他都不知道。虽然 3 中响水壶是异步的，可对于立等的老张没有太大的意义。所以一般异步是配合非阻塞使用的，这样才能发挥异步的效用。

• cloud 上云

• 做 Web 开发，最常见

• Serverless，无服务，也就是 Faas，function as a service，把一个方法作为服务上云，节约上云的成本

• event driven，在分布式系统中基于事件的方式构建一个实时数据流，就是 streaming data，这就是我在达梦做的数据流，事件驱动跟响应式结合在一起，非常好用

• batch 批处理

Spring 生态

基本上无所不包，甚至还包括 Spring for Android，Spring shell，真的，把 Spring 学透，基本上 Web 方面的需求都能搞定了，甚至 Web 以外的需求也能搞定

Spring Boot 的作用就是整合了 Spring 全家桶中的多个子项目（一个子项目就是一个场景下的解决方案），避免陷入复杂的配置问题，程序员专注于业务逻辑即可。

Spring 全家桶中的各个子项目相当于零件，你想用电脑，不需要自己组装零件，Spring Boot 直接给你一台电脑，你直接开始用就行了。

Spring5 重大升级

响应式编程

有两套技术栈，一套是 Servlet stack，servlet 技术栈，这是基于原生 Servlet 的技术栈，也就是老的技术栈，一套是全新的 Reactive stack，Reactive 技术栈，本课程也是基于这两种方式，进行的分类，先讲 Servlet stack，再讲 Reactive stack

内部源码设计

比如 Java8 开始，接口开始有默认实现，这样适配器模式就不需要了

PS：什么是适配器模式，A 接口里面又 12345 个方法，B 只想实现 12 方法，C 只想实现 34 方法，没有适配器模式的话，就只能在实现想要的实现的方法之后，其他方法就给个空实现，适配器模式就是在中间加一层，用 A' 实现 A，方法全都给空实现，然后 BC 继承 A'，注意是继承不是实现，然后重写自己需要的方法即可，这就是适配器模式。

PS：所以说 JDK 作为 Java 的基础，稍微有点风吹草动对整个生态的影响都是巨大的

为什么要用 Spring Boot

快速地创建生产级别的应用

Spring Boot 的优点

• 创建独立的 Spring 应用，这个没懂，难道以前的 Spring 应用不是独立的吗 TODO

• 内嵌 web 服务器（Tomcat, Jetty or Undertow），以前写 web 项目包括 Spring，都得先打成 war 包，然后把 war 包部署到 tomcat 服务器上，然后启动，现在 Spring Boot 内置 Tomcat，省去了你打包部署的步骤，6666，确实解决了痛点

• 提供 'starter' 依赖来简化对 jar 包的依赖的管理，以前我们要创建 web 应用，得导入一大堆的 jar 包，而且不能出现版本冲突（jar 包冲突真的是最恶心的），现在有了 starter，比如 web 场景，你不需要导入什么 servlet-api、json 处理 spring-mvc 这些 jar 包，只需要导入 web-starter 即可，那些包都被包含在里面，而且 spring 会帮你控制好 jar 包版本，6666666

• （只要可能）Spring 会自动配置 Spring 和第三方工具的对接，这是最最最 666 的功能，配置 redis、mysql，只用告诉系统地址和账号密码就可以，都不用做别的配置，真的是牛逼到顶了

• 提供生产级别的监控、健康检查及外部化配置，这个监控指的是，消耗了多少 CPU、内存等等，这个健康检测我还不知道啥意思 TODO，外部化配置是指，以前写程序，如果要改一个配置，得重新改代码，然后重新打包，换到生产环境上或者直接在生产上改配置（这非常不好）然后重启，现在只用改一个项目外部的配置文件，系统会自动应用修改后的配置，也是牛逼，这些功能能极大降低运维的工作量。

• 无代码自动生成（怕破坏项目纯净性），无 XML 配置

SpringBoot 是整合 Spring 技术栈的一站式框架

SpringBoot 是简化 Spring 技术栈的快速开发脚手架

Spring Boot 的缺点

• 迭代快

• 主要是封装太深，不好完全掌握。不过这也说明了，Spring Boot 是一座值得持续挖掘的金矿，以后多多研习 Spring 全家桶的源码，会有很多收获

时代背景

微服务

• 微服务是一种架构风格
• 一个应用拆分为一组小型服务
• 每个服务运行在自己的进程内，也就是可独立部署和升级
• 服务之间使用轻量级 HTTP 交互
• 服务围绕业务功能拆分
• 可以由全自动部署机制独立部署
• 去中心化，服务自治。服务可以使用不同的语言、不同的存储技术

其中很重要的两点

• 自动化部署，微服务架构拆分出来的模块会非常多，会有几十上百个，一个个手动部署肯定不行，所以自动化部署是非常有必要的

• 不同的服务都可以用不同的语言开发，只要能和其他服务交流就行，所以一般选择 http 来作为通信协议。

分布式

PS：微服务是一种架构风格软件架构，分布式是一种部署方式，

分布式的难点 - 单体应用不会遇到的业务场景 - 一个全新的世界

• 远程调用：A 部署在 10 台机器上，B 部署到台机器上，C 部署到 3 台机器上，A 是购物车，B 是订单，C 是用户信息，A 远程调用 B，B 调 C，就需要用 HTTP
• 服务发现：A 要调 B，B 在四台机器上，有可能其中一台挂了，有可能挂了又起了，所以需要确定此时此刻哪一台可以调用，这就是服务发现机制
• 负载均衡：假如 B 四台都能调，那此时此刻调哪台最合适呢，有的服务器已经在处理很多请求了，有的正在处理的请求不多，我们需要确定哪台负担最少，
• 服务容错：以前是线性的，A 调用 B，不通就直接抛异常，但是在分布式环境下，B 不行，有可能是代码问题，也有可能是网络问题，所以我们要调用其他的正在跑着 B 服务的机器，如果所有的机器都不通，那就返回一个什么状态信息，
• 配置管理：A 服务部署到 10 台机器上，不能能 A 的代码改了我部署 10 次，所有服务的配置都放到配置中心中，配置中心中的配置改了，所有的服务自动根据配置中心里的配置更新自己的配置
• 服务监控：服务部署到这么多机器上，这些服务占用的 CPU，内存，包括服务的健康状况等，我们要能把整个应用网都监控起来
• 链路追踪：A 调用 B，B 调用 C，C 还要调用 D，那 D 报错了，我们就要追踪整个链路，来看是哪一部出现了问题。
• 日志管理：
• 任务调度：比如 A 要执行一个定时任务，那这个定时任务是 10 台机器中某一台处罚还是全部触发，是需要串行触发还是并行触发。
• ......

分布式的解决

Spring Boot + Spring Cloud + Spring Cloud Data Flow

Spring Boot 创建非常多的微服务模块，Spring Cloud 把他们互联互调起来，节点之间的数据交换，使用 Spring Cloud Data Flow，做成响应式数据流。

云原生 - cloud native

云其实是一个部署概念，上面的微服务分布式的软件开发好了，如何部署到云上，原生开发的应用，如何部署到云上，

云上的困难，更多的是服务器运维的问题。

上云的困难

• 服务自愈：比如 A 部署到 5 台机器上，B 部署到 3 台机器上，C 部署到 2 台机器上，A 调 B，B 调 C，有一天有一台 C 炸了，那 C 能不能自愈呢，自愈就是 C 自己能不能在别台服务器再起一个 C 服务，
• 弹性伸缩：流量高峰来了，A 要大量的调用 B，B 要大量的调用 C，但是 C 只有两台，那 C 可不可以自动在另外三台服务器上各起一个 C 服务来分流，流量高峰过了之后自动关闭，这实在是 6666，
• 服务隔离：C 所在的服务器上可能也部署了其他服务比如 D、E，那如果 D、挂了或者 E 挂了，不要影响到 C。这就是服务隔离
• 自动化部署：ABC 分别部署在这么多台服务器上，不可能手工部署，只能自动部署
• 灰度发布：B 服务有版本更新，有了一个新的版本，如果一次把所有的 B 服务都换成了新版，那要是出问题了就全挂了，所以我们先替换一部分服务器上的 B 服务，因为负载均衡，只会有一部分用户调用了这个新版本的 B，即使出问题了也不是所有人出问题，长期运行没问题了，新老版可以并存了，我们再替换所有的 B 服务，这就是灰度发布，妙啊！这样上线又可以测试又保证了服务不会挂，实在是高。
• 流量治理：A 调用 B，B 调用 C，如果 B 有台服务器性能很差，处理不了太多请求，我们可以控制这台服务器的流量，只让少量流量到它这里来，别的强一点的服务器处理多一点流量，包括各个服务器之间，流量进出率的监控，根据进出率，我们可以进行扩容缩容（什么是扩缩容，TODO），有需要的话还可以在一台新的服务器上再拉起一个 B 服务等。
• ......

上云的解决

大厂学院 的课程推销：拥抱云原生

如何学习 Spring Boot

学习技术应该以官方文档为主，本课程也是从官方文档中来的，真的是惊喜，这不就相当于带着我从官方文档开始学吗！！！！太好了，我以后也要找这种从官方文档来的教学视频！！

[Spring Boot 官方信息](Spring Boot)

GA：general availability 是官方开始推荐广泛使用了版本，也就是稳定版

官网文档架构

本视频使用 2.3 版本学习，文档地址

参考文档的附件

这个课程是不可能把官方文档讲完了，老师讲个大概，一些没有覆盖到的地方，我们自己去看

Spring Boot 发版真的是频繁，the project release notes section，列出各版本的升级日志，告诉我们从一个版本升级到另一个版本改了哪些东西