最近工作有个小项目，其场景主要是封装内部的接口请求，然后做个转换之后，就请求外部请求，之后再 将外部响应转换成内部的统一格式，其实有点类似一个简单网关的应用，虽然也有一些业务逻辑在里面， 但是主要场景还是请求的转发处理，是一个 IO 密集型的应用，而且外部请求的延迟相对比较大而且不可控。 我想，这不正合适 Spring 5 出来的那个新特性的一个应用场景么。于是决定探究下 Spring Web on Reactive Stack: Spring WebFlux.
Spring WebFlux 作为一个响应式(reactive-stack) web 框架补充，在 5.0 的版本开始加入到 Spring 全家桶。这是一个完全非阻塞的，支持 Reactive Streams, 运行在诸如 Netty, Undertow, 以及 Servlet 3.1+ 容器上的。Spring WebFlux 可以让你使用更少的线程去处理并发请求，同时能够让你使用更少的硬件资源来拓展 你的应用。
下图是他们的一个区别。
Apache Kakfa 是一个分布式流处理平台，既可以当做普通的消息中间件用于消息发布订阅，也可以存储并处理流式数据，其分布式设计使得其有较好的容错性，水平拓展性等。 通常可以用于当做消息订阅发布用于业务系统中，或者用于大数据方向，接受存储大量的流式数据并和对应的大数据处理框架结合使用，eg. Kafka + Samza
从物理部署层面来讲，其主要有如下几个模块：
下面分别从这几个模块来讲解 Kafka 相关的实现[基于 Kafka 2.4]。
Apache RocketMQ 是阿里开源的一款高性能、高吞吐量的分布式消息中间件。相比于 Kafka，其拥有更好的实时性和消息可靠性。更适用于和 Money 相关的系统。它支持如下特性：
支持消费组模式的消费，即一个消费组集群内只有一个实例会收到那一条消息。
只支持特定 Level 的延时设置，默认有 “1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h” 18个 Level。先扔到对应的延时队列，后台线程根据延时再将其挪到实际的 Topic 中。
只保证在单个 Broker 的单个 Queue 内是有序的，全局不保证有序。和 Kafka 一样.。
[主从同步 + 同步刷盘] 模式保证了持久数据的安全性。4.5 版本后加入 Dleger 更是支持了 主从自动切换。
RocketMQ的消费者可以根据Tag进行消息过滤，也支持自定义属性过滤。消息过滤目前是在Broker端实现，减少了r无用消息的网络传输。
已消费过的消息，可以根据时间或 key 等维度来重新消费。在处理系统环境异常时很有用。
先发送到一个特殊的系统 Topic 中，然后利用 2PC + 事务回查机制，判断将消息转到真正的 Topic 还是抛弃。
消费失败并重试一定次数还是失败的的消息会先放到死信队列，需要手动进行重发
每个消费组有一个 “%RETRY%+consumerGroup” 的重试队列。重试的消息会按照延迟的时间先放到 “SCHEDULE_TOPIC_XXXX” 队列中，然后才会被保存至 “%RETRY%+consumerGroup” 的重试队列中。
消息消费有 ACK 机制，消费结束才返回对应的 ACK 相应。和 Kafka 不太一样，Kafka 追求消息的大量快速处理，默认都是异步，整合成一批来消费生产的。
最近自己的香港阿里云服务器到期了，也不打算续期了，是在太贵。最低配一年一千多，其实我也没啥事要做，再续期的话就不划算了，遍放弃了。但是，科学上网的需求还是有的啊。于是便想要买个 VPS 自己整个跳转用用，对于这个 VPS 我只有两个要求：
首先我是按照自己的要求 google 了一番合适的 VPS 的，有下面几个链接比较有用：
当然，按照我的要求，我选择了 BuyVM 家最便宜的一个 VPS。配置收费如下：
这个配置用来部署一些小工具和用来科学上网是足够了。(这个，有个比较坑的地方就是，他的网速貌似不是很稳定，下载速度有时候有 1M/s，有时候只有 50k/s 这样子。。。。)