咋一看，2018年已过去半年。想起去年写的一篇关于vertx集群的应用，也得到了很多朋友的阅读。也有人私下问我，说你们怎么在生产上使用的vertx，遇到过哪些问题等等。今天我将我们的升级版本及规划和思想同大家分享下。
我从2016年正式接触Vertx，那个时候看过Vertx2.x，后面出来的Vertx3.0更有亮点。我们尝试使用Vertx来改建一个小型项目。当时感觉良好，所以后面自己也开始投入时间进行研究。
在去年我们从新规划并且结合了之前项目的经验融合在一起。我提出了符合我门自己的思路设计。我们不可能完全只使用Vertx来构建项目，至少现在成本比较高。在刚开始，大家还比较接受但是到了后面，代码风格不统一，在审计和部署出现了很多问题。后期维护成本提升了，我门开始反思。
我们的小伙伴都是SSM、SSH的经验者，所以他们在写代码时，绝多数是进行复制，然后针对的修改业务逻辑。其次就是具体业务的实现用vertx比较棘手，比如同步结果，vertx需要而外的协程或者阻塞来实现，当然有人说可以使用vertx-sync，至少我没有用成功，并且和我们的所需要的场景还是不同。
项目周期性不易过长，我们也是边研究边投产，本身就带来了的不确定性和隐式风险。我们曾在尝试内部推Vertx，然后每个小团队各自使用，只要普及下Vertx的知识至于他们怎么用由他们正常发挥。最后我们看到的结果有点惨，就是每个人都使用自己的风格在构建。而Vertx本身就是简洁，所以大家也都简洁来开发项目。比如没有实体，都是json进行传递，数据校验复杂；约束性不强，代码规范得不到统一，有人高度使用配置文件，有人是代码定义；使用工具类各式各样，不能形成统一的jar规范等等…..
所以，我们后来发力，贴合我们的业务，自己封装了vertx+spring+mybatis的整合框架(再后来，我们也看到了github上有人已经整合了，很多思路是一致的)，这样我们发现团队慢慢的更超长的发挥了，毕竟和SSM没有很大的区别，并且更简单。但是还是避免不了问题，就是传参映射实体、跨应用调用(RPC)等等，这个本身就是Vertx 的不足。至于为何，需要自行去了解Vertx 的原理，毕竟他是基于事件驱动型，是一种解耦式的框架或工具类。
我们基于这个架构诞生了我们的几个项目。感觉还不错，发布到生产能正常运行，并且初步的压力测试也比tomcat要高，这里偷偷窃喜下。但这个是单例，后面紧接而来的是一个集群项目。vertx自带Ignite广播室集群和hazelcast。后来我们使用的zookeeper来做集群，总体还算不错，压力测试每秒轻松能达到1000处理请求。但好景不长，有很多业务场景我们都在想如何使用vertx的特性来解决，比如说rpc的功能，我们自己也写了一套，虽然整合到测试还是不错的，结果一发布到生产，莫名的卡住各种问题（vertx是异步），后面直接使用vertx异步send 的方式，但这只适用那些不需要回执的业务。再后来我们整合redis，使用redis的pub/sub的模式。但是redis的pub/sub也是有问题的，一旦服务断开连接，那么之前的所有消息全部丢弃，这不是我们需要的，我知道有多种方式可以解决，但这不是我们今天要聊的重点。
好了，也该进入正题了。目前我们使用的是Vertx3.5的版本，又增加了很多特性，比如他可以是一个单独的webclient来使用，虽然前版本也支持，但这个版本还是更贴近httpclient的，之前我们内部还自己封装了一个版本httpclient的组件。然后官方也正是推出vertx-zookeeper组件、vertx-redis、vertx-kafka等。在前一段时间，我们重新规划和搭建了一个分布式集群的框架。这里补充一下，要善于使用vertx 的长处，如果有些功能其他组件可以解决的，那么可以整合。
主要包括：
1、整体架构图
项目是物联网架构项目，所以涉及到的方面比较多，从硬件到数据解析、数据存储、业务服务调用等方面。针对web、app及第三方开放接口，全面包含。目前这个项目还在孵化中，预计后面会逐步开源，所以这里给大家分享设计思想啊。

业务架构图.png

2、组件规划
2.1、组件架构图

组件架构图.png

2.2、我们需要服务的自动注册与发现，所以我们定制了一些特性注解；我们将API降级，直接在维护serveice函数的时候同时也维护API接口，在服务调度的时候直接利用反射+AOP调用；这里就不具体介绍了，可以看前一篇文章；当然，因为我们是整合spring的，所有对spring是依赖的。利用AOP、反射来动态注册或调用具体的实现服务，这个版本我们还提升的对参数的约束，从视图(网关)传递的参数以json往后传递，当调用具体的执行器时，进行函数参数要求进行转换，全部以实体进行通信。服务对外使用VO、持久化层使用DTO、PO，我们解决了一个痛点，那就是参数校验和实体应用；

注解代码.png

重点角色类.png

这里补充一下，为什么要这样做。

第一、让业务层的代码更清晰；

第二、让业务层的人员更关注业务，并且提升代码质量和统一进行代码规范约束；
第三、方便统一管理，包括可继续集成和发布都是规范性的；

2.3、在整个架构中，我们使用vertx定制了一个轻量级的网关，网关只负责接收请求，然后向下转发。统一的接收器；整个流程大致如下：

网关架构图.png

2.4、目前剥离的项目大致模块规划

模块规划.png

2.5、再补充一个消息组件架构图吧。在之前项目中，我们遇到一个痛点，就是消息中心。我们一直没有设计好，导致重度依赖。所以我们重新规划，重点是解耦式，对业务代码低侵入式；

我们在消息这块采用kafka集群，然后自行封装一内部调用的sdk，应用层直接依赖，直接使用对应的api即可，分为订阅方、客户端。先上个图吧！

设计图.png

2.6、部署模式
相信大家对docker有一定了解，我们使用的是容器化部署。也在搭建自动化构建发布平台，使用Docker+Git+GitLab+Maven+jenkins+Sonar构建可持续集成和发布来自动化管理，当然也包括我们的代码质量审计；

持续交付.png

写到这，基本没了，后面就是准备将代码开源的事情。写得比较简单，也希望能给大家带来思路吧。一步一步走来，的确不容易，很多问题只有经历过了才知道怎么做的更好！