|
|
<h1><div style="text-align: center; color: #fa4861">Spring 响应式编程</div></h1>
|
|
|
|
|
|
|
|
|
# 0. 目录
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 1. 基本概念
|
|
|
- 数据流和响应式
|
|
|
- 数据流就是说明全链路都是以事件的方式进行驱动的
|
|
|
- 响应式编程核心特点: 不采用传统的同步调用方式处理数据, 而是由处于数据库上游的各层组件自动执行事件
|
|
|
- 响应式编程: 基于事件的发布订阅机制, 使用推的方式
|
|
|
- 优势: 生成事件和消费事件的过程是异步执行的,所以线程的生命周期很短，资源之间的竞争关系较少, 服务器的响应能力也就越高
|
|
|
- 响应式宣言和响应式系统
|
|
|
- 即时响应性（Responsive）、回弹性（Resilient）、弹性（Elastic）以及消息驱动（Message Driven）构成了响应式宣言的主体内容。
|
|
|
- 
|
|
|
- 具备上图中各个特性的系统，就可以称为响应式系统
|
|
|
|
|
|
# 2. 背压机制
|
|
|
- 流概念
|
|
|
- 由生产者生产并由多个消费者消费的元素序列(生产者消费者模型 | 发布者订阅者模型)
|
|
|
- 流的处理模式
|
|
|
- "拉模式": 消费者主动从生产者拉取元素
|
|
|
- "推模式": 生产者将元素推送给消费者[ 资源利用率更好]
|
|
|
- 流量控制
|
|
|
- 生产者生产数据的速率小于消费者
|
|
|
- 消费者数据没有压力, 也就不需要进行流量控制
|
|
|
- 生产者生产数据大于消费者消费数据 - [常见]
|
|
|
- 消费者可能因为无法处理过多的数据而发生崩溃
|
|
|
- 常见地解决方案是 **在生产者和消费者之间加队列的形式**
|
|
|
- 纯推模式下的数据流量会有很多不可控的因素, 需要在推模式和拉模式之间考虑一定的平衡性从而优雅的实现流量的控制
|
|
|
- 背压机制: 下游能够向上游反馈流量请求的机制
|
|
|
- 如果消费者消费数据的速度赶不上生产者生产数据的速度时, 他将会持续消耗系统的资源
|
|
|
- 响应式流的核心接口
|
|
|
```java
|
|
|
// Publisher<T>
|
|
|
|
|
|
public interface Publisher<T>{
|
|
|
public void subscribe(Subscriber<? super T> s);
|
|
|
}
|
|
|
|
|
|
|
|
|
// Subscriber<T>
|
|
|
|
|
|
public void onSubscribe(Subscriber s) // 回调方法
|
|
|
|
|
|
public void onNext(T t) {} // 向订阅者发送数据
|
|
|
|
|
|
public void onError(Throwable e) {} // 触发异常时候
|
|
|
|
|
|
public void onCompleted() {} // 数据流发送结束
|
|
|
|
|
|
|
|
|
// Subscription 对象是确保生产者和消费者针对数据处理速度达成的一种动态平衡的基础, 也是流量控制中实现背压机制的关键所在
|
|
|
|
|
|
public interface Subscription {
|
|
|
void request(long var1);
|
|
|
|
|
|
void cancel();
|
|
|
}
|
|
|
|
|
|
```
|
|
|
- 业界主流的响应式开发库包括: **RxJava, Akka, Vert.x 以及 Project Reactor**
|
|
|
|
|
|
# 3. 响应式编程应用场景
|
|
|
- 数据流处理是响应式编程的一大应用场景, 流式系统的主要特点是低延迟和高吞吐
|
|
|
- 网关的使用
|
|
|
- 网关的作用就是用来响应前端系统的流量并将其转发到后端服务
|
|
|
- Netflix Hystrix SpringCLoud Gateway 以及 SpringWebFlux
|
|
|
|
|
|
|
|
|
# 4. 基于 Spring 框架学习响应式编程
|
|
|
- 响应式编程并不是只针对系统中的某一个部分组件, 而是需要适用于调用链路上的所有组件
|
|
|
- 只要有一个环节不是响应式的, 那么这个环节就会出现同步阻塞
|
|
|
- Spring5 提供了 WebFlux + SpringData Reactive
|
|
|
- WebFlux不仅包含了对创建和访问响应式HTTP端点的支持, 还可以用来实现服务器推送事件以及 WebSocket
|
|
|
- Spring WebFlux 需要支持异步的运行环境
|
|
|
- 比如 Netty，Undertow 以及 Servlet 3.1 版本以上的 Tomcat 和 Jetty
|
|
|
- 非常适合开发 I/O 密集型服务
|
|
|
- 不要 WebFlux和 SpringMVC混合使用, 无法保证全栈式的响应式流
|
|
|
- 案例: CSS: (Customer Service System)客户服务系统
|
|
|
- 
|
|
|
- 开发重点
|
|
|
- Web层: 构建 RESTFUL 端点, 并通过响应式请求的WebClient客户端组件来消费这些端点
|
|
|
- Service层: 核心逻辑在于完成事件处理和消息通信相关的业务场景 account-service 消息的发布者, customer-service 则是消息消费者
|
|
|
- Repository层: 引入 MongoDB和Redis两款支持响应式流的 NoSQL 数据库, MongoDB为各个服务存储业务数据, Redis主要用于在 customer-service 中
|
|
|
- 
|
|
|
|
|
|
# 5. 了解 Reactor
|
|
|
- RxJava诞生的更早, 但是 Reactor 更有前途
|
|
|
- 使用 弹珠图来说明 响应式编程的策略(Marble Diagram)
|
|
|
|
|
|
# 6. 使用 Flux 和 Mono 构建响应式数据流
|
|
|
- Flux 创建
|
|
|
- 基于各种工厂模式的静态创建方法
|
|
|
- just() range() interval() 以及各种以 from- 为前缀的方法组等
|
|
|
- 采用编程方式动态创建Flux
|
|
|
-
|
|
|
- 注解方式进行编码
|
|
|
- 基于Java注解的方式进行编码, 编程模型和 Spring MVC 一致
|
|
|
- 基于函数式编程模型
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
