手無寸鐵，如何強硬又體面地落地中間件

閱讀字數：2852 | 8分鐘閱讀

摘要

架構側的技術組件推動困難在整個行業內是很常見的事情。不同的角色，相異的團隊，大家所考慮的利益也各不相同。本次嘉賓將為大家分享如何在這種情況下優雅體面的落地中間件，以及各種技術細節。

面臨的問題

架構模型

一般的互聯網公司的架構都是一層層向上支撐的，最底層的技術架構是上面所有層的基礎，而中間件是技術架構向上支撐的一塊基石。

雖然從宏觀架構看，幾乎找不到中間件的位置，但實際架構實現的過程中幾乎都離不開中間件的支撐。因為技術向上支撐需要不同的解決方案，這些解決方案通過不斷的提煉並經由代碼具象化後所得到的就是中間件。

理想中落地的樣子

理想的情況下我們希望架構完成後研發能夠儘快的接入和上線，且運行時所有的一切都在掌握中不會出現漏洞，後續還能夠著手思考下次升級。

但是實際情況下業務研發會被PR、原型以及需求等約束，第一次接入可能還沒什麼問題，但是後續的架構升級在業務爆發時期研發就難以理會了。

就拿找剛來說，2014年的時候我們技術開發團隊還只有20多人，相互之間有什麼問題都可以快速解決，但是隨著之後公司的發展技術團隊規模越發龐大，同時業務規模的高速發展使得研發疲於應對，很難再去配合架構的接入。

面對這種情況，我們認為兩個解決方案，第一是在組織上以行政命令的方式推進。第二就是微服務，在機器上部署各種“服務”。

觀測工具用法

尋找領域內潛在的問題

經過與其他公司的同行溝通調研後，我們發現所有的公司在這方面的問題主要有兩點。

首先就是有大半的時間在等待接入發佈，因為每個應用的發佈時間完全不可控，少則兩週，多達一月，也有穩定無發佈的。

另外還要花費一定時間在人員溝通上，這是個很實際的問題，就像之前提到的一開始人員較少時溝通起來還是很方便的，一旦成員增加溝通難度會逐步增大，而且構成層級也會越來越深，可能要從經理到組長再到開發，甚至還有測試。

最後就會發現只剩下了很少的時間在常規工作上，來關注運行情況、收集運行數據以及依據數據繼續迭代改進。

鋪路爪Pavepaws

Pavepaws是一款中間件產品，用來徹底解決技術架構的升級和落地問題。它有這樣幾個特點，首先是無感升級，能夠進行自動化部署以及動態加載。其次是三方依賴隔離，能讓多版本依賴共存無衝突。最後是運行時可控，可以隨時升降級和bug熱修復。

鋪路爪核心組件

鋪路爪有4個核心組件，Java Runtime，利用Java本身的一些特性來完成類的替換和監聽等機制，然後是類加載的必經之路Class Loader。接下來是字節碼轉換器，用來在類被實際Runtime解析前對字段、方法等進行編輯修改，它其實也是Java Runtime提供的特性。最後是影子加載器，用來掛鉤ClassLoader，攔截loadClass等方法實現自由的類加載邏輯。

具體實現

正常的類加載邏輯是先由Java Runtime發起loadClass，然後再到ClassLoader。一般ClassLoader都會有自己的加載邏輯，所以需要通過ClassFileTransFormer對ClassLoader進行基於字節碼的方法切面，更改原先的加載邏輯，這樣的做法不僅幾乎沒有性能損失，還可以對任意非原生類任意方法操作。

之前的類加載中loadClass會到達ClassLoader，而現在則是到自己的加載器。我們會在服務器上設置一個專門的目錄，然後配合運維提供的文件推送服務把文件推送到服務器上專用的目錄中，最後由影子加載器在該目錄中尋找類，一旦找到就讓自身加載器處理，否則交給ClassLoader處理。這樣就優先實現了自己的資源查找邏輯，同時解決了前面提到的升級問題，這時只需要讓運維配合就行了。

雖然基本實現了需求，但是還存在一個問題，即第三方包的版本選擇。比如針對某個第三方包我們採用了一個版本，研發方面又是另一個版本，接入時就會發生衝突，總有一方會掛掉。解決這個問題最簡單的做法是遵循基本的設計原則，讓實現與接口分離。

進程內的微服務

前面提到過要解決接入的各種問題可以採用微服務的方式，為此我們實現了進程內的微服務，這不僅解決了因服務器上部署的微服務過多而產生的服務治理問題，同時讓研發只需使用接口而不用關心內部實現。

配置實施流程，形成閉合

到目前為止通過技術手段已經解決了一半的問題，但是還存在人員的溝通問題沒有搞定。所以為此一定要有配套實施流程，首先要與QA制定中間件升級流程，將中間件升級發佈與業務應用升級發佈隔開。其次與運維方面做好培訓，用於在突發風險時，即時關停或組件降級。然後做好流控系統為了在風險發生時，能夠即時通過調整策略進行止損。最後在有了QA流程後，研發這塊主要在升級前做到溝通，協調時間避免與大項目衝突。

大路朝邊，各走一邊

最終我們實現了業務系統與中間件發佈的獨立，中間件升級不在受制與業務系統的發佈週期，在任何環境都可以批量進行組件升級更新操作，而讓研發無感知，同時眾多的應用系統能夠提供更全更多的運行測試，發現未知問題。

不再需要“臉”的時代

現在我們的時間分配已經發生了變化，首先要花費5%的時間來避開大項目發佈，畢竟大項目上線時，人員比較緊張，不適合操作，萬一發現問題也容易影響研發人員排查。其次在人員的溝通推進上的時間減少，不在需要重複解釋各種問題，只要和業務線經理溝通確認好時間，最後統一郵件告知即可。這樣算下來剩下的90%的時間就能用來進行常規工作了。

閱讀更多 拓樸區塊鏈 的文章

關鍵字: 咖說 編程語言 中間件