基于WebFlux与Kotlin协程：不使用ReactiveCrudRepository的可行性问询

嘿，这个问题在Oracle生态里真的挺常见的——毕竟目前确实没有成熟的免费非阻塞Oracle驱动，要兼顾WebFlux的响应式架构和现有Hibernate的持久层，你的思路其实是很务实的过渡方案。咱们来仔细聊聊它的稳定性和是否属于不良实践：

方案可行性与稳定性 #

首先可以明确：你的方案是可行的，只要做好几个关键细节，稳定性完全有保障。

需要注意的核心点：

• 协程调度器的选择：你示例里用了Unconfined调度器，这是个坑！Unconfined会直接在WebFlux的事件循环线程上执行阻塞的DB查询操作，很容易把事件循环占满，导致整个应用的响应能力急剧下降。正确的做法是把阻塞操作放到IO线程池里，比如用Dispatchers.IO或者Spring提供的TaskExecutor对应的调度器：

  // Controller里的优化写法
  fun listProgrammingLanguagesReactive() = mono(Dispatchers.IO) {
      logger.info { "requesting list of programming languages" }
      val languages = service.getAllLanguages()
      logger.info { "responding with list of programming languages" }
      languages
  }
  

• 事务与协程的兼容：如果你的Service层涉及事务，要确保Spring事务能正确绑定到协程上下文。推荐把Service层的函数改成suspend类型，配合@Transactional注解使用，Spring对Kotlin协程的事务支持已经很完善了：

  // Service层优化后的写法
  @Transactional
  suspend fun getAllLanguages(): Collection<ProgrammingLanguage> = repository.findAll()
  

• 异常处理：阻塞的CrudRepository抛出的异常要能被WebFlux的全局异常处理器捕获，避免因为DB操作的异常导致协程链中断，影响其他请求。

是否属于不良实践？ #

这得分场景判断：

• 短期过渡方案：绝对不是不良实践！如果你的目标是先把Web层改造成响应式，后续等Oracle推出免费非阻塞驱动，或者项目有预算使用商业响应式驱动（比如Oracle官方的Reactive JDBC驱动）再替换持久层，这个方案非常务实，能帮你快速完成Web层的响应式改造，同时保留现有成熟的Hibernate代码。
• 长期架构方案：它确实有局限性——本质上还是阻塞的DB操作，只是用协程做了一层包装，没法真正发挥WebFlux的非阻塞优势。当你的系统DB压力大、查询耗时久的时候，IO线程池还是会被占满，只是不会阻塞事件循环而已。但如果你的业务DB压力不大、查询响应快，这个方案也能长期稳定运行，算不上“不良实践”。

额外优化建议 #

• 尽量让Service层的API更贴合协程风格，用suspend函数代替直接返回Mono，这样代码更清晰，也更容易测试和维护。
• 合理配置IO线程池的大小：参考你的Oracle连接池大小来调整，避免IO线程数远大于DB连接数，导致大量线程等待DB连接，浪费资源。
• 可以考虑在Repository层做一些缓存优化，减少DB查询的频率，进一步降低阻塞操作对系统的影响。

总的来说，你的方案是当前场景下非常合理的选择，只要注意调度器、事务和异常处理这几个细节，稳定性完全没问题。

内容的提问来源于stack exchange，提问作者Lukas Forst