咋一看，2018年已過去半年。想起去年寫的一篇關(guān)于vertx集群的應(yīng)用，也得到了很多朋友的閱讀。也有人私下問我，說你們怎么在生產(chǎn)上使用的vertx，遇到過哪些問題等等。今天我將我們的升級版本及規(guī)劃和思想同大家分享下。
我從2016年正式接觸Vertx，那個時候看過Vertx2.x，后面出來的Vertx3.0更有亮點(diǎn)。我們嘗試使用Vertx來改建一個小型項目。當(dāng)時感覺良好，所以后面自己也開始投入時間進(jìn)行研究。
在去年我們從新規(guī)劃并且結(jié)合了之前項目的經(jīng)驗(yàn)融合在一起。我提出了符合我門自己的思路設(shè)計。我們不可能完全只使用Vertx來構(gòu)建項目，至少現(xiàn)在成本比較高。在剛開始，大家還比較接受但是到了后面，代碼風(fēng)格不統(tǒng)一，在審計和部署出現(xiàn)了很多問題。后期維護(hù)成本提升了，我門開始反思。
我們的小伙伴都是SSM、SSH的經(jīng)驗(yàn)者，所以他們在寫代碼時，絕多數(shù)是進(jìn)行復(fù)制，然后針對的修改業(yè)務(wù)邏輯。其次就是具體業(yè)務(wù)的實(shí)現(xiàn)用vertx比較棘手，比如同步結(jié)果，vertx需要而外的協(xié)程或者阻塞來實(shí)現(xiàn)，當(dāng)然有人說可以使用vertx-sync，至少我沒有用成功，并且和我們的所需要的場景還是不同。
項目周期性不易過長，我們也是邊研究邊投產(chǎn)，本身就帶來了的不確定性和隱式風(fēng)險。我們曾在嘗試內(nèi)部推Vertx，然后每個小團(tuán)隊各自使用，只要普及下Vertx的知識至于他們怎么用由他們正常發(fā)揮。最后我們看到的結(jié)果有點(diǎn)慘，就是每個人都使用自己的風(fēng)格在構(gòu)建。而Vertx本身就是簡潔，所以大家也都簡潔來開發(fā)項目。比如沒有實(shí)體，都是json進(jìn)行傳遞，數(shù)據(jù)校驗(yàn)復(fù)雜；約束性不強(qiáng)，代碼規(guī)范得不到統(tǒng)一，有人高度使用配置文件，有人是代碼定義；使用工具類各式各樣，不能形成統(tǒng)一的jar規(guī)范等等.....
所以，我們后來發(fā)力，貼合我們的業(yè)務(wù)，自己封裝了vertx+spring+mybatis的整合框架(再后來，我們也看到了github上有人已經(jīng)整合了，很多思路是一致的)，這樣我們發(fā)現(xiàn)團(tuán)隊慢慢的更超長的發(fā)揮了，畢竟和SSM沒有很大的區(qū)別，并且更簡單。但是還是避免不了問題，就是傳參映射實(shí)體、跨應(yīng)用調(diào)用(RPC)等等，這個本身就是Vertx 的不足。至于為何，需要自行去了解Vertx 的原理，畢竟他是基于事件驅(qū)動型，是一種解耦式的框架或工具類。
我們基于這個架構(gòu)誕生了我們的幾個項目。感覺還不錯，發(fā)布到生產(chǎn)能正常運(yùn)行，并且初步的壓力測試也比tomcat要高，這里偷偷竊喜下。但這個是單例，后面緊接而來的是一個集群項目。vertx自帶Ignite廣播室集群和hazelcast。后來我們使用的zookeeper來做集群，總體還算不錯，壓力測試每秒輕松能達(dá)到1000處理請求。但好景不長，有很多業(yè)務(wù)場景我們都在想如何使用vertx的特性來解決，比如說rpc的功能，我們自己也寫了一套，雖然整合到測試還是不錯的，結(jié)果一發(fā)布到生產(chǎn)，莫名的卡住各種問題（vertx是異步），后面直接使用vertx異步send 的方式，但這只適用那些不需要回執(zhí)的業(yè)務(wù)。再后來我們整合redis，使用redis的pub/sub的模式。但是redis的pub/sub也是有問題的，一旦服務(wù)斷開連接，那么之前的所有消息全部丟棄，這不是我們需要的，我知道有多種方式可以解決，但這不是我們今天要聊的重點(diǎn)。
好了，也該進(jìn)入正題了。目前我們使用的是Vertx3.5的版本，又增加了很多特性，比如他可以是一個單獨(dú)的webclient來使用，雖然前版本也支持，但這個版本還是更貼近httpclient的，之前我們內(nèi)部還自己封裝了一個版本httpclient的組件。然后官方也正是推出vertx-zookeeper組件、vertx-redis、vertx-kafka等。在前一段時間，我們重新規(guī)劃和搭建了一個分布式集群的框架。這里補(bǔ)充一下，要善于使用vertx 的長處，如果有些功能其他組件可以解決的，那么可以整合。
主要包括：
1、整體架構(gòu)圖
項目是物聯(lián)網(wǎng)架構(gòu)項目，所以涉及到的方面比較多，從硬件到數(shù)據(jù)解析、數(shù)據(jù)存儲、業(yè)務(wù)服務(wù)調(diào)用等方面。針對web、app及第三方開放接口，全面包含。目前這個項目還在孵化中，預(yù)計后面會逐步開源，所以這里給大家分享設(shè)計思想啊。
2、組件規(guī)劃
2.1、組件架構(gòu)圖
2.2、我們需要服務(wù)的自動注冊與發(fā)現(xiàn)，所以我們定制了一些特性注解；我們將API降級，直接在維護(hù)serveice函數(shù)的時候同時也維護(hù)API接口，在服務(wù)調(diào)度的時候直接利用反射+AOP調(diào)用；這里就不具體介紹了，可以看前一篇文章；當(dāng)然，因?yàn)槲覀兪钦蟬pring的，所有對spring是依賴的。利用AOP、反射來動態(tài)注冊或調(diào)用具體的實(shí)現(xiàn)服務(wù)，這個版本我們還提升的對參數(shù)的約束，從視圖(網(wǎng)關(guān))傳遞的參數(shù)以json往后傳遞，當(dāng)調(diào)用具體的執(zhí)行器時，進(jìn)行函數(shù)參數(shù)要求進(jìn)行轉(zhuǎn)換，全部以實(shí)體進(jìn)行通信。服務(wù)對外使用VO、持久化層使用DTO、PO，我們解決了一個痛點(diǎn)，那就是參數(shù)校驗(yàn)和實(shí)體應(yīng)用；
這里補(bǔ)充一下，為什么要這樣做。
第一、讓業(yè)務(wù)層的代碼更清晰；
第二、讓業(yè)務(wù)層的人員更關(guān)注業(yè)務(wù)，并且提升代碼質(zhì)量和統(tǒng)一進(jìn)行代碼規(guī)范約束；
第三、方便統(tǒng)一管理，包括可繼續(xù)集成和發(fā)布都是規(guī)范性的；
2.3、在整個架構(gòu)中，我們使用vertx定制了一個輕量級的網(wǎng)關(guān)，網(wǎng)關(guān)只負(fù)責(zé)接收請求，然后向下轉(zhuǎn)發(fā)。統(tǒng)一的接收器；整個流程大致如下：
2.4、目前剝離的項目大致模塊規(guī)劃
2.5、再補(bǔ)充一個消息組件架構(gòu)圖吧。在之前項目中，我們遇到一個痛點(diǎn)，就是消息中心。我們一直沒有設(shè)計好，導(dǎo)致重度依賴。所以我們重新規(guī)劃，重點(diǎn)是解耦式，對業(yè)務(wù)代碼低侵入式；
我們在消息這塊采用kafka集群，然后自行封裝一內(nèi)部調(diào)用的sdk，應(yīng)用層直接依賴，直接使用對應(yīng)的api即可，分為訂閱方、客戶端。先上個圖吧！
2.6、部署模式
相信大家對docker有一定了解，我們使用的是容器化部署。也在搭建自動化構(gòu)建發(fā)布平臺，使用Docker+Git+GitLab+Maven+jenkins+Sonar構(gòu)建可持續(xù)集成和發(fā)布來自動化管理，當(dāng)然也包括我們的代碼質(zhì)量審計；
寫到這，基本沒了，后面就是準(zhǔn)備將代碼開源的事情。寫得比較簡單，也希望能給大家?guī)硭悸钒伞Ｒ徊揭徊阶邅?，的確不容易，很多問題只有經(jīng)歷過了才知道怎么做的更好！
