多年前刚入行智能家居的时候有所耳闻，用来做建筑自动化的协议，不过现在没人用了吧

@nothingistrue nio 确实完全优于 bio ，完全替代这毋庸置疑。2022 年的今天谁在 UI 线程读取文件？十年前都不这么做了好吧。
如果你真的基础扎实的话，你应该知道 memory hierarchy 中 CPU >> Memory >>> Disk ，即使是计算密集型应用，异步流式文件加载也可以尽可能的让计算过程提前开始，最简单的例子就是“读取 CSV 文件，统计数据”，省下来的 CPU 时间可以留给计算过程，让总计算时间缩的更短。

Scala 生态里的 HTTP Body 读写都是纯异步的😏

@jeesk 有做过社区分享，数据是 Prometheus 实时采集的 3 Pod CPU 合计，TPS 也是来自 Ingress 和 服务内暴露的。
我的应用是全异步，包括 HTTP 和 RPC 调用，数据库访问走 hikaricp JDBC 链接池，但技术栈是 Scala 这边的，Akka Stream 混合 ZIO 纤程调度，线程池仅有 N 个 fiber scheduler + 2N 个 Blocking 。

大多数人都是先把线程池用💩了，再学美团动态线程池💩上雕花，并不知道一开始就把事情做对，反而去质疑教科书是不是写错了。

楼主和楼内其他回帖人也犯了不少谬误

我先说下我的实战经验，我有一个 NIO 生产环境服务，落到 JDBC 有 100 QPS ，CPU 消耗不超过 0.2 核心😏

对大部分 CRUD 需要访问数据库，他人 API 的 IO 密集型应用来说，完全 NIO 模型对性能的提升都是碾压级别的，碾过 BIO 渣都不剩。
另一点，JDBC 虽然是阻塞的，但不影响你开固定链接池异步访问，你的应用依然可以按照教科书上 n 核心的 CPU 开 n 个线程的池。

如果你想了解更多 NIO 概念，那应该去看看《响应式设计模式》

同楼主在青岛
我 23 岁(2014)的时候写 VB.net 也焦虑的不行，后来去了青岛一家做 PLC 智能家居的公司（东软载波 2015 ），认识了几个牛人慢慢找到了前进的方向。

是《组合数学》和《 SICP 》帮我缓解的焦虑，2016 年来到上海，至今薪资已十倍增长。
在这里我也将这两门课推荐给楼主，希望能帮助楼主提高薪资，缓解焦虑。

我用过 > 9 种 AIO Http Client
Scala: http4s / tapir / akka-http / play ws client
Python: aio-http
Kotlin: ktor on CIO
Rust: reqwest
Javascript: axios / fetch

说实话使用体验非常流畅，Spring 新版的 WebClient 因为还是受到 Java 语言不灵活的限制，使用体验大概率是要比以上 9 种都要差一些的。

Reactive Stream 的使用体验就是，>100 TPS 的服务才占用 0.2 个 CPU 核心，以至于我开发的服务在公司里没什么存在感。而且错误处理和理论模型也比 Go 要强好多倍。

既然 Spring 新加了这功能，我觉得你不妨体验一下，至于封装嘛，建议抄一下 Axios 之类的设计，让同事们更好上手。不要固步自封，不然升级了和没升级有什么区别呢。

提升码功的教材有很多，我特别推荐《 SICP 》这一本，也是大一新生入门教材，也是帮助我收入十倍增长的一本书。

学 Java 大可不必，你的目的是增长见识而不是学一堆历史包袱。Java CRUD 生态里充斥着各种低质量过时的糟粕。
如果你真想增长见识的话，建议去学 Haskell / Scala / Rust ，这些语言并不需要你有 C / Java 基础，而且让你提前认识到“现代化”的计算机科学。

同时也可以学一点 NodeJS / Swift / Kotlin 或 WASM 等偏前端应用技术，做一些看得见摸得着的小东西出来，比对着黑框框死敲更有成就感。

@lanlanye CQRS 里有全量的 Event ，特殊情况，如 kafka 崩溃也可以从 CQRS 的事件存储重放

@jiayouniu 两个项目
一个记录变动历史的 kv 存储中间件
另一个资源管理服务，限制客户请求量，套餐等等

这俩项目都对高可用 /故障自动迁移有一定需求，所以直接用了 Cluster Sharding 架构实现
说实话我没了解过 DDD ，只是按照 Akka Projection 官方例子边学边做

刚做过两个 CQRS 项目的来回答一下

1. 建议同楼上 UUID ，我自己用的框架是创建 Entity 的时候就要指定 ID 了
2. 目前我直接把 Event 写入到 Kafka ，但你想拿 PostgreSQL / MySQL 做第一个读取端也没问题，有 debezium 这一类工具可以实现生成事件

我就说一本书，<SICP>
效果：薪资五年十倍

相关资料：
Rust -> https://doc.rust-lang.org/rust-by-example/error/multiple_error_types/wrap_error.html
Scala -> https://nrinaudo.github.io/scala-best-practices/adts/errors_extend_exception.html
Kotlin -> https://arrow-kt.io/docs/patterns/error_handling/

Algebraic Data Types 了解一下，Rust / Scala / Kotlin 都原生支持 ADT ，其他语言也有模拟方案。

@xianzhe 事实上太子的建议几乎都是说，尽可能使用 Scala 写法😂，我不知道是怎么理解成“写 scala 时能用 java 的方式写出来就不要去追求其他写法”。
他还建议用 ADT 呢 https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html#simple-sealed-trait

@xianzhe
一条一条看，杨博转述的太子博客
1. 尽量用不可变值（相当于 Java 的 final 变量）
这已经是 Scala 的方式了，在 Scala 当中优先使用 val 而不是 var ，优先使用 immutable 而不是 mutable 。
2. 采用静态函数和内置数据结构设计 API
尽量用 object 和 scala.collection ，也是 Scala 的方式
3. 尽量使用 JavaSE 和 Scala 标准库的内置数据结构
同上。多说一句，李太子是写库的人，他们对 0 依赖看的比搬砖工们更重要
4. 用 Option 代替异常处理和 null
也是 Scala 的方式，并且 Scala 的 Option 也是 Monad 哦
5. 尽量让函数立即返回值，而不要用异步编程
这是说尽可能，而不是一定不要。不管是谁，在 2022 年的今天实现一个数据库驱动或者 RPC 调用，这种 IO 任务首选当然是被 Future[T] 包裹起来，依然是 Scala 的方式
6. 手动传递参数，不要搞依赖注入
依赖注入不分什么方式，从库 /框架作者角度来看，依赖越少，用户依赖冲突的可能性就越低。当然最好是 0 依赖