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

一、篇前總結

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

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

這兩年，呆在了一家公司。見證了公司業務的不斷發展，也見證了一些業務的失敗。成功的原因很多，失敗的原因也很多。真實見證了研究生老師所說的“四拍”：拍腦袋做決定、拍胸脯打包票、出了事情拍大腿、最后拍屁股走人。

二、做中間件

在來這家公司之前，對做中間件還是滿懷憧憬的。當時，做了幾年的業務，被產品、測試各種需求，搞的頭都大了。心想，一定要做技術底層的東西，不要再做這些亂七八糟的需求了。相信很多同學也一定有這樣的想法，覺得做中間件可以更加深入技術底層的東西，我可以告訴你，是的，你有時間看更多的源碼了。不用天天被產品和測試追著，被項目經理追進度了，因為都需要你自己把控。

但是，也有各種煩心事。

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

做中間件，自己就是產品經理、項目經理、測試、開發、運維，得自己去收集需求，去挖掘需求，要有一定的技術前瞻性，能夠對標業界的標桿產品，要能推動中間件的推廣。也要能抗事，因為業務方的需求千奇百怪，你得去滿足他們。

做中間件很煩，很難有成果，不管大廠小廠都一樣。聽說大廠的中間件就是客服，小廠的中間件基本就是開源的拿來改改，沒有太大的成就感。

三、這兩年做了啥

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

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 其他

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

四、總結

兩年的時間，轉瞬即逝。現在還記得當時從北京過來時的樣子，懵懵懂懂，現在感覺已經看盡了世間繁華，惟愿歲月靜好。感恩所有幫助過我的人，感恩家人，嶄新的序幕即將開啟，我將一往無前，繼續前行。

歡迎大家關注我的公眾號，有各種一線分享。

轉載于:https://www.cnblogs.com/f-zhao/p/10820672.html

總結

以上是生活随笔為你收集整理的做中间件的这两年总结（201704-201905）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。