背景
前几个月，使用Vertx重构了公司的一个子系统，该系统负责公司核心数据subscriber的采集、处理、存储和搜索。这里介绍下重构该系统时的一些关键点。
架构
重构前系统部署图：
重构前系统主要有2部分组成，这2部分都会对Subscriber数据操作：
Java APP： 是个定时任务触发的APP，每2小时跑一次，每次启动后做以下的事情：
- 从MongoDB里加载已有的数据到内存。
- 读取准备好的Data文件，处理文件中的数据，和已加载的数据做合并，这个处理的过程会导致Subscriber数据有添加、删除和更新操作。
- 处理完Data文件后，将数据持久化到MongoDB和Elasticsearch。
JBoss服务：
- 从Kafka中来的消息数据，批量处理Kafka消息，会添加和更新Subscriber数据到MongoDB和Elasticsearch中。
- 从其他系统触发的API调用，接收一些API请求，这些请求也会增加、删除和更新Subscriber数据。在更新的时候，因为查询条件的多样性，为了提高查询Subscriber的速度，对MongoDB的Subscriber Collection建了各种索引。
重构原因
- 对同一种的数据的操作在2个不同的服务中，一种是war一种是jar，不利于维护。代码在不同的Rep和Project下，维护也不方便。
- Jboss现在是单实例部署，Jboss中还部署有其他的服务，Jboss的稳定性直接影响了该服务。为了提高查询速度，对数据建立了多种不同的索引，更新数据增加了数据库的负担。
- 定时任务JavaAPP每次在处理某个客户的Subscriber数据时候，都要从MongoDB加载数据到内存，耗时没有效率。因为是定时任务，对数据更新不够及时，会影响其他依赖Subscriber数据的服务。
- 数据更新冲突：在定时任务把数据加载到内存，正在处理时，此时如果Jboss也在更新数据会导致数据更新冲突（现在采用了一个很tricky的方式解决）。
重构后系统部署图
重构后，系统组件介绍和说明：
Adapter服务：
- 数据适配服务，统一接收来自文件、Kafka和API调用的数据，对数据进行预处理，发送相应的业务消息到Event Bus。
- 因为对Adapter的触发方式只有2种，一种是REST API,另一种是连接Kafka读取消息，所以Adapter服务可以通过部署多个实例来增加可用性，也顺便提高了整体性能。
Mapper服务：
- 数据处理服务，按数据分片进行部署，分片规则可以按客户大小来分，比如把10个大客户的数据部署在一个实例上，200个小客户的数据部署在另一个实例上，也可以按数据量平均分。
- 初始启动时候加载所属该实例的所有Subscriber数据到内存，从EventBus上接收来自Adapter的业务请求，处理请求并对数据进行更新。
- 数据更新策略：
- 来自API的请求都会实时的更新到MongoDB和Elasticsearch中。
- 来自文件和Kafka的数据更新量比较大，为了避免每次对数据更新的时候都去操作DB和ES，通过一个队列缓存所有的更新。触发队列持久化条件：一种是当缓存Size达到阈值时候触发，另一种是定时触发，触发后批量更新数据到MongoDB和Elasticsearch中。
- 内存、MongoDB和Elasticsearch中数据一致性：因为现在数据在内存中，使用了Vertx的MongoClient的异步回调机制，保证只有更新到MongoDB成功后才去更新Elasticsearch，保证MongoDB里数据的准确性是第一位的。而ElasticSearch中数据的准确性是通过“定时补偿机制”去保证：有其他定时执行的脚本去定时检查，并决定是否重新对某个客户的数据重建索引。
重构之后的可改进项：
- 耗内存，所有的Subscriber数据都分片加载到了JVM里。这部分可以把数据放到其他的存储中，比如redis，但就算是放到redis，也是耗内存。
- 如果系统出错，会导致数据在MongoDB和ElasticSearch之间不一致，需要其他方式去做“数据一致性补偿”。如果资源允许，可以把数据更新同步单独拿出来实现，使用类似处理“分布式系统数据一致性”的方式来改善这一点。
小结
一些技术关键点
1 异步非阻塞
Vertx的异步非阻塞机制有很好的并发性能。网络IO依赖了Netty，Java NIO的特性。
2 Vert.x-Web
Vertx-web可以很方便的去实现一个web app，很容易实现一些REST APIs。
3 Data access client
Vertx提供了访问各种存储的Client，这些client的API都是异步的，可以很方便的去访问MongoDB，JDBC，Redis等。
4 Event Bus
Vertx的一个核心功能，重构这个子系统时也很依赖这个功能。Event Bus可用于不同Verticle之间的通信，也可以用于Vertx cluster之间的通信。
5 功能解耦
系统中各个子功能可以按不同的Verticle去实现，不同的Verticle可以通过EventBus去通信解耦。Vertx支持动态的加载和卸载Verticle，也就可以实现在运行时动态的加载卸载某些功能。
6 集群模式
Adapter服务和Mapper服务是通过Vertx的Cluster模式组成了集群，集群中节点发现和通信通过Hazelcast管理。使用Vertx实现的服务，可以单实例部署，也可以组成集群提供服务。
参考