分享 | 道法术器响应式 Spring

曾有读者问我之前的文章《微服务网关演进之路》里提到的编程框架 SpringWebflux有没有比较好的学习资料或者文档。

我都是看官方文档和网上比较零碎的资料，对新手来说不友好。

也想过自己来写一个关于响应式编程的系列文章，奈何水平有限，很多东西我自己也是一知半解，就不来误人子弟了。

再后来发现了这样一个CSDN博客专栏，名叫 【道法术器】响应式Spring，作者刘康，写的非常好，特别适合入门，下面是博客原地址，分享给大家：

https://blog.csdn.net/get_set/category_9272724.html

总共有20多篇文章，这些文章通俗易懂，我也是认真看过几遍才来推荐的。

从什么是响应式编程、响应式流等概念说起，为什么需要响应式编程，还有什么其他方案以及优缺点等都说到了，还顺便把所需要的lambda、函数式等知识也给我们补齐了，后面还有一些小例子，甚至教我们如何单元测试，如何测试性能等等。

当然这个专栏偏入门和科普，只要有点 Java 基础就能看，如果你确实想动手实践一下，作者还翻译了 Reactor3（SpringWebflux 核心依赖） 的参考手册

https://htmlpreview.github.io/?https://github.com/get-set/reactor-core/blob/master-zh/src/docs/index.html

响应式编程是比较小众的技术，但如果你要用 Java 写个网关这样的服务，可以看看。Apache 开源的这款网关产品，也是基于 SpringWebflux 框架来写的

https://github.com/apache/incubator-shenyu

作者能把一个抽象的概念说的非常清楚，这点也是我们技术写作的追求，下面分享一段作者写的一段介绍IO到底有多慢的文字：

很多情况下，在大的空间和时间维度上，数量级经常会大到超出我们的认知范畴，我们的直觉总是不可靠的。

一、举两个空间维度的例子：

在大的尺度上，印象中，银河系的中心位置群星闪耀，就像赶集一样。但实际上，如果把恒星们缩小到沙粒的大小，那么密度也就相当于一个体育场有一两粒沙子。曾经看科幻片，总是担心光速飞行的飞船来不及拐弯或刹车撞到星球上，实际上，想要撞上才是相当不容易的。

而在小的尺度上，原子核具有原子绝大部分的质量。

但实际上，如果把一个原子也放大到体育场那么大，原子核才仅仅相当于一个乒乓球那么大，空旷的很！

二、从时间维度上：

往大了说，如果地球45亿年历史缩短为一年，那么人类有记录的浩瀚文明史不过相当于几秒钟而已。

往小了说，“一瞬间”与“一瞬间”可能会差好几个数量级。我们就从微观时间维度来了解一下“CPU眼中的时间”，你会发现，发生在计算机中的阻塞也许比你直觉印象中夸张的多。

CPU眼中的时间——

CPU绝对称得上是“闪电侠”，因为它们做事都有自己的一套时钟。我们故事的主人公是一个主频为2.5GHz的CPU，如果它的世界也有“秒”的概念，并且它的时钟跳一下为一秒，那么在CPU（CPU的一个核心）眼中的时间概念是啥样的呢？

CPU先生所在的组是硬件部计算组。对它来说，与其一起紧密合作的几个小伙伴还能跟的上它的节奏：

• CPU先生很利索，只需要一秒就可以完成一个指令，复杂的动作可能需要多个指令。
• 好在“贴身秘书”一级缓存反应比较快，能够秒懂CPU先生的意思。
• 来自“秘书组”的二级缓存虽然要十几秒才能“get”到CPU先生的点，但也不算太迟钝。
• 和内存组的合作已经习以为常了，跟内存请求的数据通常要4-5分钟才能找到（内存寻址），不过也还好啦，毕竟一级缓存那里能拿到80%想要的数据，其余的二级缓存也能搞定一大部分，不怎么耽误事儿。

CPU先生是典型的工作狂，任务多的时候，通宵达旦也毫无怨言，但是有什么事情让它等，那简直要他命了。恰恰一起共事的其他组（尤其是I/O组的磁盘和网卡）相对来说那效率是低的离谱啊：

• 关于I/O组的同事，CPU先生已经抱怨很久了，每次找SSD要东西，都要花费4-5天才能找到（寻址），等到数据传送过来，几周都过去了。机械磁盘更是过分地离谱，跟他要个数据，竟然要平均花费10个月才能找到，如果要读取1M的数据，竟然要20个月！这种员工怎么还不下岗？！
• 关于网卡，CPU先生知道它们也尽力了，毕竟万兆网络成本颇高。与机房内的其他小伙伴们用千兆网络互相沟通也算顺畅，给另一台机器的CPU朋友发送1K的书信，最快七八个小时就可以送过去了。但是1K的书信经过层层包裹，实际也写不了多少话。更要命的是，网卡们的沟通手续繁杂，每次网络沟通前的 “你好能听到我吗？——我能听到，你那边能听到我吗？——我也能听到你，那我们开始吧！” 这样的握手确认都要花掉很长的时间，不过不能当面沟通，也只能这样了。这还好，最恐怖的是与其他城市的小伙伴沟通，有时候传递消息要花费好几年呢！

由此可见，对于CPU先生来说，想要让工作充实起来实在不容易，不过多亏了内存组的小伙伴帮忙分批缓存往返于I/O组的数据，矛盾才有所缓解。

更多可去看他的博客，纯粹的分享好东西，CSDN 给作者发了私信没回我，如果觉得有点用处，记得给我点赞加关注哦~

如果想看到更多的分享，也欢迎加我微信，朋友圈也经常分享一些技术文章~