新的篇章即將拉起，是時(shí)候給自己的這兩年來個(gè)總結(jié)了。

一、篇前總結(jié)

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

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

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

二、做中間件

在來這家公司之前，對(duì)做中間件還是滿懷憧憬的。當(dāng)時(shí)，做了幾年的業(yè)務(wù)，被產(chǎn)品、測(cè)試各種需求，搞的頭都大了。心想，一定要做技術(shù)底層的東西，不要再做這些亂七八糟的需求了。相信很多同學(xué)也一定有這樣的想法，覺得做中間件可以更加深入技術(shù)底層的東西，我可以告訴你，是的，你有時(shí)間看更多的源碼了。不用天天被產(chǎn)品和測(cè)試追著，被項(xiàng)目經(jīng)理追進(jìn)度了，因?yàn)槎夹枰阕约喊芽亍?/p>

但是，也有各種煩心事。

這兩年，做了兩年中間件。說是做中間件，其實(shí)中間經(jīng)歷了各種坎坷，方向也變了不少。說實(shí)話，做中間件，雖然看起來更加偏技術(shù)一些，但是比做業(yè)務(wù)來說更加心累，承受了更大的壓力。因?yàn)橹虚g件是為業(yè)務(wù)負(fù)責(zé)的，不能出錯(cuò)，一旦出錯(cuò)，就是基礎(chǔ)設(shè)施出了問題，基本上就是P0的故障了。

做中間件，自己就是產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、測(cè)試、開發(fā)、運(yùn)維，得自己去收集需求，去挖掘需求，要有一定的技術(shù)前瞻性，能夠?qū)?biāo)業(yè)界的標(biāo)桿產(chǎn)品，要能推動(dòng)中間件的推廣。也要能抗事，因?yàn)闃I(yè)務(wù)方的需求千奇百怪，你得去滿足他們。

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

三、這兩年做了啥

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

3.1 elastic-job的推廣

來的時(shí)候，公司的定時(shí)任務(wù)都是單機(jī)quartz的，相當(dāng)危險(xiǎn)。也是因?yàn)楫?dāng)時(shí)的業(yè)務(wù)量不大，所以單機(jī)也就單機(jī)跑著了。進(jìn)來的第一件事情，就是研究了下elastic-job，讓大家把定時(shí)任務(wù)都遷移到了這個(gè)上面。很可惜的是，由于開發(fā)者從當(dāng)當(dāng)離職了，elastic-job基本上不再維護(hù)了。不過穩(wěn)定性還是能夠得到保證的。這兩年，沒出什么問題。中間有個(gè)小插曲，業(yè)務(wù)方對(duì)elastic-job的分片理解不夠透徹，導(dǎo)致現(xiàn)在很多系統(tǒng)的定時(shí)任務(wù)分片數(shù)還是1，基本上也是單機(jī)運(yùn)行，不過有個(gè)故障轉(zhuǎn)移的能力。因?yàn)闃I(yè)務(wù)方在原來的基礎(chǔ)上，封裝了一層，里面寫死了分片數(shù)。開源框架里面的各種概念，還需要不斷地宣貫，業(yè)務(wù)方才能運(yùn)用到他們的業(yè)務(wù)邏輯代碼中。目前公司所有的定時(shí)任務(wù)，都已經(jīng)接入了elastic-job。

3.2 延遲隊(duì)列

這件事，是和elastic-job是同一時(shí)間做的，但其實(shí)他們是兩件事情。延遲隊(duì)列的需求，來源于業(yè)務(wù)方，具體的場(chǎng)景有不少，有興趣的同學(xué)可以自己網(wǎng)上搜搜，簡(jiǎn)單的基于redis的zset實(shí)現(xiàn)了下。后來業(yè)務(wù)方也自己實(shí)現(xiàn)了一套，原理類似。可以看出來，業(yè)務(wù)方同學(xué)也喜歡自己造輪子。

3.3 Kafka和Kafka監(jiān)控

公司的消息隊(duì)列選擇，據(jù)說經(jīng)歷了幾個(gè)階段。在初期的時(shí)候，有在用RocketMQ，后來發(fā)現(xiàn)這個(gè)占用機(jī)器內(nèi)存太高了，而且是阿里維護(hù)的，說實(shí)話，當(dāng)時(shí)阿里的開源做的很不好，很可能做著做著就沒人維護(hù)了（參考當(dāng)年的Dubbo，不過公司還是毅然決然選擇了Dubbo）。所以后來，公司決定，采用Kafka作為唯一的消息隊(duì)列。

我來了之后，讓我做一些Kafka的監(jiān)控，主要監(jiān)控Kafka中消息的堆積，在消息有堆積的時(shí)候進(jìn)行報(bào)警。當(dāng)時(shí)公司有Kafka-Manager，但是Kafka-Manager是Scala寫的，只能看到堆積的數(shù)量，沒有監(jiān)控告警的功能。所以經(jīng)過調(diào)研，我們選擇了Kafka-Eagle，國(guó)人寫的一個(gè)Kafka監(jiān)控工具，改造了內(nèi)部的一些bug和告警機(jī)制，就匆匆上線了，效果也還可以。后來有其他同學(xué)接手了MQ這塊，他對(duì)Kafka-Eagle做了進(jìn)一步的一些改造，能夠批量添加告警信息，能夠釘釘告警，告警的效率也有了提升。

后來，我們又發(fā)現(xiàn)了另一款開源的告警工具-Burrow。這款工具，可以對(duì)一個(gè)時(shí)間窗口的消息堆積進(jìn)行告警，也就是能夠補(bǔ)充Kafka-Eagle的缺失。Kafka-Eagle只有等消息堆積到了一定數(shù)量的時(shí)候才會(huì)告警，而且是定時(shí)跑的（5分鐘一次），也就是設(shè)想這樣的場(chǎng)景，如果某個(gè)partition突然間不消費(fèi)了，但是消息的數(shù)量又不大，Kafka-Eagle是沒法告警出來的，但是Burrow能告警出來，因?yàn)樗歉鶕?jù)一個(gè)時(shí)間窗口的趨勢(shì)告警的。也很感謝那位同學(xué)的改造，做了一些易用性的改造，同時(shí)添加了郵件告警、釘釘告警等。

3.4 研究并推行了分庫(kù)分表

在公司的數(shù)據(jù)量不斷累積、公司業(yè)務(wù)不斷發(fā)展壯大的情況下，分庫(kù)分表是一個(gè)勢(shì)在必行的事情。

在我們決定使用Sharding-Jdbc之前，我們用過MyCat。在一定的歷史時(shí)期內(nèi)，是一個(gè)解決方案，但是僅僅用了一段時(shí)間后，就因?yàn)樗粩喑霈F(xiàn)的問題，而放棄了。在這說一句，MyCat的代碼質(zhì)量真的堪憂，可能開源的這批人，想著怎么去做解決方案，想著去開培訓(xùn)班賺錢了，代碼感覺是實(shí)習(xí)生寫的，代碼風(fēng)格不統(tǒng)一，讓人沒法看。

后來，我們一直在跟進(jìn)Sharding-Jdbc。當(dāng)時(shí)，這是由當(dāng)當(dāng)維護(hù)的一個(gè)開源項(xiàng)目，后來，負(fù)責(zé)人去了京東，后來Sharding-Jdbc改名為Sharding-Sphere，并在Apache孵化。選擇Sharding-Jdbc的原因，主要有幾個(gè)原因：

• 源碼可控，風(fēng)格統(tǒng)一
• 客戶端分片，性能影響小

我們引入Sharding-Jdbc也分了幾個(gè)階段，走了一些彎路。第一個(gè)階段，我們做了個(gè)Sharding-Jdbc的后臺(tái)頁(yè)面，對(duì)源碼進(jìn)行了一些改造，頁(yè)面上進(jìn)行數(shù)據(jù)源配置，并最終同步到ZooKeeper中。業(yè)務(wù)方配置namespace和數(shù)據(jù)源名稱，在啟動(dòng)時(shí)拿到配置，生成分庫(kù)分表數(shù)據(jù)源。第二個(gè)階段，對(duì)分片算法進(jìn)行了封裝，提供了簡(jiǎn)單的分片算法，比如Hash、Mod等，業(yè)務(wù)方配置算法，生成最終的算法。這個(gè)階段，對(duì)源碼也有一定的改動(dòng)。第三個(gè)階段，依賴于Sharding-Jdbc的Jar包，封裝算法，不改源碼。

這塊前前后后加推廣，做了一段時(shí)間，目前公司一些比較核心的業(yè)務(wù)，已經(jīng)上了分庫(kù)分表，目前穩(wěn)定性也有一定的保證，當(dāng)然，推廣的過程中，也遇到了一些坑，這里不細(xì)說。

這段時(shí)間的積累，也為后面要做的事情，做了一些鋪墊。

3.5 數(shù)據(jù)同步

在上分庫(kù)分表之前，我們就對(duì)數(shù)據(jù)同步開始了一定的調(diào)研。因?yàn)闃I(yè)務(wù)的分庫(kù)分表，勢(shì)必會(huì)遇到以下幾個(gè)問題：

• 歷史數(shù)據(jù)的sharding
• sharding之后，數(shù)據(jù)聚合查詢

這是兩個(gè)典型的場(chǎng)景。

第一個(gè)的解決方案可以使業(yè)務(wù)方自己去做，也就是業(yè)務(wù)自己寫定時(shí)任務(wù)，在低峰期進(jìn)行數(shù)據(jù)遷移，寫到分庫(kù)分表中；另一個(gè)解決方案就是提供通用的中間件來做數(shù)據(jù)實(shí)時(shí)同步，這樣對(duì)業(yè)務(wù)方的影響最小。

第二個(gè)場(chǎng)景就是，分庫(kù)分表后的管理端查詢，查詢條件可能很復(fù)雜，這時(shí)候不可能通過分庫(kù)分表來查，需要把分庫(kù)分表的數(shù)據(jù)聚合到一個(gè)地方，給后端進(jìn)行查詢。

當(dāng)然，還有一個(gè)場(chǎng)景，就是數(shù)據(jù)庫(kù)的前后端隔離，前端庫(kù)面向外部用戶，后端庫(kù)面向管理端。這時(shí)候也需要進(jìn)行同步，當(dāng)然也可以通過掛從庫(kù)的方式來做。

這塊，我們首先調(diào)研的是，阿里開源的Canal，以及配套的Otter。但是Otter不支持分庫(kù)分表，它支持的是類似DRDS、MyCat的Sharding Proxy，對(duì)于客戶端的Sharding，很難支持，我們當(dāng)時(shí)對(duì)Otter進(jìn)行了改造。但是效果不好，因?yàn)镺tter本身里面的一些邏輯復(fù)雜，不太可控，而且Otter只支持增量同步，不支持全量同步，所以在做了一段時(shí)間后，決定自己研發(fā)數(shù)據(jù)同步的組件。

得益于在Sharding-Jdbc中的積累，我們對(duì)分庫(kù)分表的實(shí)踐經(jīng)驗(yàn)還是比較豐富的，所以整個(gè)開發(fā)的過程中比較順利。我們采用了全量+增量的同步模式，滿足了我們的業(yè)務(wù)場(chǎng)景。

涉及到數(shù)據(jù)這塊的中間件，細(xì)枝末節(jié)的東西很多，我們需要和DBA緊密配合，同時(shí)也需要不斷地實(shí)踐，才能做出一些成果出來。所幸，我們有了這樣的機(jī)會(huì)，感謝公司及領(lǐng)導(dǎo)。

數(shù)據(jù)同步的組件目前已經(jīng)服務(wù)了很多的業(yè)務(wù)系統(tǒng)，穩(wěn)定性和性能也有了一定的提升，后面還需要做一些優(yōu)化的工作，一些精細(xì)化的事情，當(dāng)然也有一些更加復(fù)雜的業(yè)務(wù)場(chǎng)景需要滿足（目前公司規(guī)模下，還未遇到），這塊留給后來人做吧。

3.6 其他

中間還做了一些其他的事情，包括配置中心、配置中心的封裝等。主要工作是看看源碼，進(jìn)行業(yè)務(wù)改造，自不必細(xì)說。目前主要還是負(fù)責(zé)數(shù)據(jù)中間件這塊。

四、總結(jié)

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

歡迎大家關(guān)注我的公眾號(hào)，有各種一線分享。

轉(zhuǎn)載于:https://www.cnblogs.com/f-zhao/p/10820672.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。