视频分享在抖音上，其他平台懒得挪了，有兴趣的朋友可以帮忙搬过去。没打算挣钱。
这个项目用到的技术，我也是抱着学习的态度，一点点摸索。当然，相关技术栈已经用到公司的项目上3年多了，一直忙着做业务，没有时间梳理。当然，公司的代码写得也很烂。恰好，公司黄了，也有空好好整理下了。
我是先提出目标，再找资料做实验，实验通过后，再修改文档、录制视频。
对我而言，后端没有什么技术难点。所以，文档集中在前端。我尝试以前端的角度，使用RSocket做一些demo。
后端，使用springboot + rsocket + kotlin coroutines + graalvm实现了响应式架构。
前端，使用vue3 + rsocket-js访问了后端接口。且，模仿axios封装了rsocket请求。
graalVM可以让整个项目更容易部署，启动速度更快，运行时占用更少的内存。而云服务是按需收费的。
RSocket协议可以同时覆盖http、websocket、MQTT等协议的应用场景，支持响应式编程。
但，RSocket开放的接口不是Restful API，测试困难。不支持Swagger。
-
前后端交互使用RSocket协议
-
后端微服务之间使用RSocket协议
RSocket协议底层使用的websocket协议，所以，部署的服务是websocket集群
-
函数调用使用kotlin coroutines
将异步回调转为顺序代码，在几乎不更改开发习惯的基础上，实现异步编程。底层原理较复杂，但，看起来跟“顺序代码”差不多
-
访问数据库使用R2dbc协议
响应式编程，从前端到后端，一直到数据库，没有一个节点是阻塞的。
以“查询订单”为例。设，每个节点执行正常业务逻辑耗时1秒，且忽略网络交互的时间。
service等待dao的执行结果，所以service等待1秒，dao不需要等待；
同理controller需要等待service的执行结果，所以controller等待2秒。依次类推：
| 节点 | 执行 | 等待 | 响应时间 |
|---|---|---|---|
| app/网页 | 1 | 3 | 4 |
| controller | 1 | 2 | 3 |
| service | 1 | 1 | 2 |
| dao | 1 | 0 | 1 |
其中，"等待"就是阻塞
1. 使用响应式架构后，app还需要等待3秒吗？
答：是的，app还需要等待3秒（执行1秒，等待3秒）
2. 使用响应式架构后，app的响应时间是多少？
答：app的响应时间是4秒，执行1秒，等待3秒
3. 有什么区别？
答：使用响应式架构，等待的3秒，没有消耗资源
4. QPS提高了多少？
答：app的响应时间虽然还是4秒，但，只占用了1秒的资源。如果占用相同的资源，即4秒的资源，响应式架构的app可以同时运行4个请求，即，性能提高了4倍。
但，不能只考虑app一个节点。整个链路提高的性能是几何级增长的。即，整个链路提升的性能为4*3*2*1 = 24倍
5. dao是怎么通知service的？这种信息调度不消耗资源吗？
答：这种调度是“响应式编程”架构需要考虑的问题。其中，架构具体实现部分包括RSocket协议、kotlin coroutines等，对“调度”的侧重点不同。核心原理，是通过顶层设计，去掉业务开发代码中的“资源调度”（硬编码），交由框架处理，从而，彻底解决“阻塞”问题。
6. 怎么测试？
答：写测试用例，主要是功能测试。
解决“阻塞”问题的开发模型，可以简单理解为“发布订阅模型”，代码不是按编写顺序执行的。
比如，产品经理给开发人员布置任务的顺序，不代表开发人员完成任务的顺序。所谓的“顺序代码”与“异步编程”就是这个意思。
我们的代码看起来是“顺序代码”，实际是“异步执行”的。所以，测试时必须充分考虑业务场景，从性能、异步的角度考虑。已经不是点一下按钮等结果那么简单了，必须写测试代码。
所以，写测试用例，而不是在Swagger中点一点。
7. 前端怎么验证接口？
答：没有swagger，看不到具体有多少接口，怎么调用？只能看后端的源码。
前端只需要学习kotlin语法即可，从零开始，2个小时内，肯定可以看懂接口。
简单的接口，执行后端开发写好的测试用例，即可确认是否可用。
而且，RSocket接口支持Javascript、typescript，前端也可以自己写接口测试。