RxJava在服务端是否有使用场景和优势

1.Hystrix使用RxJava简洁的window API来构建metric应该算是一种不错的后端使用场景，说实话, RxJava虽然很酷, 但服务端使用RxJava的优势真心很少.

2.主要的原因还是大多数的Java服务端还是以同步逻辑为主, 迁移成本太高了.RxJava的响应式优势只有在异步逻辑占主导时才会体现出来. 异步和同步的夹杂使用, 还不如整体使用NodeJS的异步处理协调.其次, RxJava一大堆的数据处理API对习惯了同步逻辑的程序员来说, 学习成本也是相当高的.再加上后端的类库大多都是同步的API, 兼容RxJava的API的类库寥寥无几.所以基于RxJava的后端类库也是少之又少.

2.目前后端基于RxJava构建的最著名的类库是Hystrix, 它提供的API也是通过Command模式来作为同步的方式来调用.外部调用者无需关心内部的RxJava实现. 这样做应该也是为了降低使用者学习成本吧.

兼容RxJava API的rxjava-jdbc, 虽然使用起来代码会简洁不少, 但现在的项目已经很少直接使用jdbc了, 也是英雄无用武之地.

如果想在后端使用响应式编程的话. 不妨看看vertx, 它基本用自己的响应式打通了后端的各个环节, 它规划的技术栈还是很全面,基本上覆盖到后端开发的功能.

1、Rxjava逻辑会比较清晰，蛋代码可读性比较差；用在后台的业务处理上，后台业务通常复杂，步骤多，这会让逻辑更清晰，但是前端基本上没有必要用，而且代码可读性比较差；

2、ReTrofit每次发起请求都会创建OkHttp，不会复用，导致单条数据的请求性能低了一倍以上；

3、Rxjava+ReTrofit组合起来运行的性能非常低，特别是并发的时候，性能更低，测试发现并发100条要1200ms，不使用的话并发130ms；

4、Rxjava+ReTrofit组合当需要读取本地缓存的时候，读缓存是通过URL作为KEY来读取，这样就需要写两遍的URL，一遍是框架用的，一遍是用于缓存的，使用起来更不方便；

以上是本人使用过程中的经历，有没有高手解惑，目前决定放弃这套组合，自己实现一套

---