作中間件的這兩年總結（201704-201905）

新的篇章即將拉起，是時候給本身的這兩年來個總結了。

1、篇前總結

這兩年，從北京來到了杭州。從一個北漂變成了杭漂，買了房，買了車，養了條柯基，在這座江南城市生了根。父母健康，家庭和氣。日子過得舒適，感謝父母，感謝媳婦。

這兩年，完成了研究生的課程，經過了研究生的答辯。不枉咱們杭州北京來回跑，飛機高鐵臥鋪的來回切換。每次都從南京轉車，一晚臥鋪的臥鋪到北京。飛機取消了好幾回。在學校前面的賓館住了好屢次，成了他們的VIP。認識了不少其餘行業的人，加了不少其餘的非技術羣，開闊了眼界，再也不侷限於技術的小圈子裏。堅決了，只有作實業，才能興國的理念。

這兩年，呆在了一家公司。見證了公司業務的不斷髮展，也見證了一些業務的失敗。成功的緣由不少，失敗的緣由也不少。真實見證了研究生老師所說的「四拍」：拍腦殼作決定、拍胸脯打包票、出了事情拍大腿、最後拍屁股走人。

2、作中間件

在來這家公司以前，對作中間件仍是滿懷憧憬的。當時，作了幾年的業務，被產品、測試各類需求，搞的頭都大了。心想，必定要作技術底層的東西，不要再作這些亂七八糟的需求了。相信不少同窗也必定有這樣的想法，以爲作中間件能夠更加深刻技術底層的東西，我能夠告訴你，是的，你有時間看更多的源碼了。不用每天被產品和測試追着，被項目經理追進度了，由於都須要你本身把控。

可是，也有各類煩心事。

這兩年，作了兩年中間件。說是作中間件，其實中間經歷了各類坎坷，方向也變了很多。說實話，作中間件，雖然看起來更加偏技術一些，可是比作業務來講更加心累，承受了更大的壓力。由於中間件是爲業務負責的，不能出錯，一旦出錯，就是基礎設施出了問題，基本上就是P0的故障了。

作中間件，本身就是產品經理、項目經理、測試、開發、運維，得本身去收集需求，去挖掘需求，要有必定的技術前瞻性，可以對標業界的標杆產品，要能推進中間件的推廣。也要能抗事，由於業務方的需求千奇百怪，你得去知足他們。

作中間件很煩，很難有成果，無論大廠小廠都同樣。據說大廠的中間件就是客服，小廠的中間件基本就是開源的拿來改改，沒有太大的成就感。

3、這兩年作了啥

我這兩年，主要作了幾件事。

3.1 elastic-job的推廣

來的時候，公司的定時任務都是單機quartz的，至關危險。也是由於當時的業務量不大，因此單機也就單機跑着了。進來的第一件事情，就是研究了下elastic-job，讓你們把定時任務都遷移到了這個上面。很惋惜的是，因爲開發者從噹噹離職了，elastic-job基本上再也不維護了。不過穩定性仍是可以獲得保證的。這兩年，沒出什麼問題。中間有個小插曲，業務方對elastic-job的分片理解不夠透徹，致使如今不少系統的定時任務分片數仍是1，基本上也是單機運行，不過有個故障轉移的能力。由於業務方在原來的基礎上，封裝了一層，裏面寫死了分片數。開源框架裏面的各類概念，還須要不斷地宣貫，業務方纔能運用到他們的業務邏輯代碼中。目前公司全部的定時任務，都已經接入了elastic-job。

3.2 延遲隊列

這件事，是和elastic-job是同一時間作的，但其實他們是兩件事情。延遲隊列的需求，來源於業務方，具體的場景有很多，有興趣的同窗能夠本身網上搜搜，簡單的基於redis的zset實現了下。後來業務方也本身實現了一套，原理相似。能夠看出來，業務方同窗也喜歡本身造輪子。

3.3 Kafka和Kafka監控

公司的消息隊列選擇，聽說經歷了幾個階段。在初期的時候，有在用RocketMQ，後來發現這個佔用機器內存過高了，並且是阿里維護的，說實話，當時阿里的開源作的很很差，極可能作着作着就沒人維護了（參考當年的Dubbo，不過公司仍是毅然決然選擇了Dubbo）。因此後來，公司決定，採用Kafka做爲惟一的消息隊列。

我來了以後，讓我作一些Kafka的監控，主要監控Kafka中消息的堆積，在消息有堆積的時候進行報警。當時公司有Kafka-Manager，可是Kafka-Manager是Scala寫的，只能看到堆積的數量，沒有監控告警的功能。因此通過調研，咱們選擇了Kafka-Eagle，國人寫的一個Kafka監控工具，改造了內部的一些bug和告警機制，就匆匆上線了，效果也還能夠。後來有其餘同窗接手了MQ這塊，他對Kafka-Eagle作了進一步的一些改造，可以批量添加告警信息，可以釘釘告警，告警的效率也有了提高。

後來，咱們又發現了另外一款開源的告警工具-Burrow。這款工具，能夠對一個時間窗口的消息堆積進行告警，也就是可以補充Kafka-Eagle的缺失。Kafka-Eagle只有等消息堆積到了必定數量的時候纔會告警，並且是定時跑的（5分鐘一次），也就是設想這樣的場景，若是某個partition忽然間不消費了，可是消息的數量又不大，Kafka-Eagle是無法告警出來的，可是Burrow能告警出來，由於它是根據一個時間窗口的趨勢告警的。也很感謝那位同窗的改造，作了一些易用性的改造，同時添加了郵件告警、釘釘告警等。

3.4 研究並推行了分庫分表

在公司的數據量不斷累積、公司業務不斷髮展壯大的狀況下，分庫分表是一個勢在必行的事情。

在咱們決定使用Sharding-Jdbc以前，咱們用過MyCat。在必定的歷史時期內，是一個解決方案，可是僅僅用了一段時間後，就由於他不斷出現的問題，而放棄了。在這說一句，MyCat的代碼質量真的堪憂，可能開源的這批人，想着怎麼去作解決方案，想着去開培訓班賺錢了，代碼感受是實習生寫的，代碼風格不統一，讓人無法看。

後來，咱們一直在跟進Sharding-Jdbc。當時，這是由噹噹維護的一個開源項目，後來，負責人去了京東，後來Sharding-Jdbc更名爲Sharding-Sphere，並在Apache孵化。選擇Sharding-Jdbc的緣由，主要有幾個緣由：

• 源碼可控，風格統一
• 客戶端分片，性能影響小

咱們引入Sharding-Jdbc也分了幾個階段，走了一些彎路。第一個階段，咱們作了個Sharding-Jdbc的後臺頁面，對源碼進行了一些改造，頁面上進行數據源配置，並最終同步到ZooKeeper中。業務方配置namespace和數據源名稱，在啓動時拿到配置，生成分庫分表數據源。第二個階段，對分片算法進行了封裝，提供了簡單的分片算法，好比Hash、Mod等，業務方配置算法，生成最終的算法。這個階段，對源碼也有必定的改動。第三個階段，依賴於Sharding-Jdbc的Jar包，封裝算法，不改源碼。

這塊前先後後加推廣，作了一段時間，目前公司一些比較核心的業務，已經上了分庫分表，目前穩定性也有必定的保證，固然，推廣的過程當中，也遇到了一些坑，這裏不細說。

這段時間的積累，也爲後面要作的事情，作了一些鋪墊。

3.5 數據同步

在上分庫分表以前，咱們就對數據同步開始了必定的調研。由於業務的分庫分表，勢必會遇到如下幾個問題：

• 歷史數據的sharding
• sharding以後，數據聚合查詢

這是兩個典型的場景。

第一個的解決方案可使業務方本身去作，也就是業務本身寫定時任務，在低峯期進行數據遷移，寫到分庫分表中；另外一個解決方案就是提供通用的中間件來作數據實時同步，這樣對業務方的影響最小。

第二個場景就是，分庫分表後的管理端查詢，查詢條件可能很複雜，這時候不可能經過分庫分表來查，須要把分庫分表的數據聚合到一個地方，給後端進行查詢。

固然，還有一個場景，就是數據庫的先後端隔離，前端庫面向外部用戶，後端庫面向管理端。這時候也須要進行同步，固然也能夠經過掛從庫的方式來作。

這塊，咱們首先調研的是，阿里開源的Canal，以及配套的Otter。可是Otter不支持分庫分表，它支持的是相似DRDS、MyCat的Sharding Proxy，對於客戶端的Sharding，很難支持，咱們當時對Otter進行了改造。可是效果很差，由於Otter自己裏面的一些邏輯複雜，不太可控，並且Otter只支持增量同步，不支持全量同步，因此在作了一段時間後，決定本身研發數據同步的組件。

得益於在Sharding-Jdbc中的積累，咱們對分庫分表的實踐經驗仍是比較豐富的，因此整個開發的過程當中比較順利。咱們採用了全量+增量的同步模式，知足了咱們的業務場景。

涉及到數據這塊的中間件，細枝末節的東西不少，咱們須要和DBA緊密配合，同時也須要不斷地實踐，才能作出一些成果出來。所幸，咱們有了這樣的機會，感謝公司及領導。

數據同步的組件目前已經服務了不少的業務系統，穩定性和性能也有了必定的提高，後面還須要作一些優化的工做，一些精細化的事情，固然也有一些更加複雜的業務場景須要知足（目前公司規模下，還未遇到），這塊留給後來人作吧。

3.6 其餘

中間還作了一些其餘的事情，包括配置中心、配置中心的封裝等。主要工做是看看源碼，進行業務改造，自沒必要細說。目前主要仍是負責數據中間件這塊。

4、總結

兩年的時間，轉瞬即逝。如今還記得當時從北京過來時的樣子，懵懵懂懂，如今感受已經看盡了世間繁華，唯願歲月靜好。感恩全部幫助過個人人，感恩家人，嶄新的序幕即將開啓，我將勇往直前，繼續前行。

歡迎你們關注個人公衆號，有各類一線分享。