前言

CNCF 與 Cloud Native 這兩個技術詞匯最近頻頻走進了程序員的視野，一切和他能搭上邊的軟件意味著標準、開放、時尚，也更能俘獲技術哥哥們的心；這篇文章不想去帶大家重溫這個詞匯后面的軟件體系，筆者覺得單憑用到了這些開源軟件，不等于我們自己的軟件就已經(jīng)是 Cloud Native，在使用啞鈴和成為肌肉男之間還隔著科學使用和自律鍛煉兩道工序；在此，筆者想根跟大家聊聊讓我們的應用真正變得 Cloud Native 時的理論依據(jù)：微服務的十二要素。這篇文章也是先從作者自身項目的角度（一個基于 EDAS 的微服務架構），來闡述對這十二條要素的前兩條 —— 倉庫(Code Base)與依賴(Dependency)的理解

Code Base 的原文釋義是:"一份基準代碼，多份部署，基準代碼和應用之間總是保持一一對應的關系；不同環(huán)境中的相同應用，應該來源于同一份代碼"。我的理解有兩個：

1. 一個應用，產(chǎn)生自同一個倉庫。

2. 一個倉庫，只產(chǎn)生一個應用。

為什么推演出這么兩個結論呢？讓我們先看一個實際的項目。

為什么是一個應用？

給大家舉一個一個倉庫包含多個應用的反例，筆者自己的一個項目是一個的微服務的架構，和大部分的微服務架構一樣，一開始是由一個單體的應用拆解而來，拆解之后，大致簡化成四個服務：微服務網(wǎng)關(Gateway)，兩個后臺服務(UserService, OrderService)，后臺管理控制臺服務(Admin)，簡單的架構示意圖如下：

在拆分的過程一開始為了項目上線的減少風險，將拆分之后的應用都放在了一個 GIT 倉庫中進行管理，同時也共用了同一個庫。重構之后倉庫的目錄如下：

~/workspace/java/app/?$?tree?-L?2.
├──?README.md
├──?service-api?#?通用的?API?接口定義│???├──?userservice-api?#?服務?UserService?的聲明│???├──?orderservice-api?#?服務?OrderService?的聲明│???├──?rpc-api?#?遠程服務調(diào)用相關的接口聲明│???├──?common-api?#?UserService?與?OrderService?都依賴的聲明|???.....
├──?service-impl?#?對應?API?的相關具體業(yè)務實現(xiàn)
│???├──?userservice-impl
│???├──?orderservice-impl
│???├──?common-impl
|???.....
├──?web-app?#?Web?應用工程│???├──?admin
│???├──?userservice
│???├──?orderservice
│???├──?gateway

一開始這些服務之間的發(fā)布和改動彼此都不受影響，這一過程持續(xù)了大約兩個迭代，隨著迭代的不斷進行和新人的加入，后來我們線上發(fā)現(xiàn)一個很奇怪的現(xiàn)象，每次用戶進入刷新訂單的地址列表的時候，會伴隨這一次用戶 Token 的刷新而導致用戶被踢出，線上的排查過程在 EDAS 的分布式鏈路跟蹤系統(tǒng) EagleEye 的幫助下，馬上就定位到了出問題的代碼：

//?User?Service?中public?class?User?{????public?void?refresh()?{????????//?刷新登錄?token
????}
}//?Order?Service?中public?class?OrderUser?extends?User?{????//?函數(shù)少了一個字母，導致?refresh?調(diào)用了父類的?refresh?
????public?void?refesh()?{????????//?刷新地址列表
????}
}

這個故障，我先邀請大家一起思考一下幾個問題：

1. 從編碼角度，如何避免上述重寫的方法因為名字誤寫造成故障？

2. 從設計角度，OrderUser 和 User，是否是繼承關系？

3. 這個問題的根因是什么？

以上的幾個問題中，第一個問題的答案，很多同學都知道，就是使用 Java 自帶的 Annotation?@Override，他會自動強制去檢查所修飾的方法簽名在父子類中是否一致。第二個問題，需要從領域邊界來說，這是一個典型的邊界劃分的問題，即：訂單中的用戶，和會員登錄中的用戶，是不是相同的“用戶”？會員中的用戶，其實只需要關心用戶名密碼，其他都是這個用戶的屬性；而訂單中的用戶，最重要的肯定是聯(lián)系方式，即一個聯(lián)系方式，確定一個人。雖然他們都叫做用戶，但是在彼此的上下文中，肯定是不一樣的概念。所以這里的?OrderUser?和?User?是不能用繼承關系的，因為他們就不是一個 "IS A" 的關系。
__倉庫共享__，加上沒有多加思考的模型，導致依賴混亂；如果兩個?User??對象之間代碼上能做到隔離，不是那么輕易的產(chǎn)生“關系”，這一切或許可以避免。

為什么是一個倉庫？

嚴格意義上說，一個應用的所有代碼都肯定來源于不同的倉庫？我們所依賴的三方庫如（fastjson, edas-sdk 等）肯定是來源于其他的倉庫；這些類庫是有確切的名稱和版本號，且已經(jīng)構建好的"制品"，這里所說的一個倉庫，是指源碼級別的“在制品”?？赡茉诤芏嗟捻椖恐胁粫嬖谶@樣的情況，以 GIT 為例，他一般發(fā)生在 submodule 為組織結構的工程中，場景一般是啥呢？在我們這個工程中確實是有一個這樣的例子：

為了解掉第一個問題，我們決定拆倉庫，倉庫的粒度按照應用粒度分，同時把 common 相關的都拆到一個叫做 common 倉庫中去；業(yè)務服務都好說，這里特殊處理的是 admin 應用，admin 是一個后臺管理應用，變化頻度特別大，需要依賴 UserService 和 OrderService 一大堆的接口。關于和其他倉庫接口依賴的處理，這里除了常見的 Maven 依賴方式之外，還有另外一個解決方案就是 git submodule，關于兩個方案的對比，我簡單羅列在了下表之中：

我覺得如果這個項目組只有一兩個人的時候，不會帶來協(xié)作的問題；上面的方案隨便哪一個都是不需要花太多時間做特殊討論，挑自己最熟悉最拿手的方案肯定不會有錯，所謂小團隊靠技術嗎，說的就是這么個道理；我們當時是一個小團隊，同時團隊中也有同學對 submodule 處理過類似的情況，所以方案的選擇上就很自然了。

后來隨著時間的推移，團隊慢慢變大，就發(fā)現(xiàn)需要制定一些流程和和規(guī)范來約束一些行為，以此保障團隊的協(xié)作關系的時候；這時候發(fā)現(xiàn)之前靠一己之力打拼下來的地盤在多人寫作下變得脆弱不堪，尤其是另外一個 submodule 變成一個團隊進行維護的時候，submodule 的版本管理幾乎不可預期，而且他的接口變動和改動是完全不會理會被依賴方的感受的，因為他也不知道是否被依賴；久而久之，你就會明白什么叫做你的項目被__腐化__了。簡單理解__腐化__這個詞就是，你已經(jīng)開始害怕你所做的一切改動，因為你不知道你的改動是否會引來額外的麻煩。從這個角度也可以去理解為什么一門語言設計出來為什么要有 __private__、__public__這些表示范圍的修飾詞。正因為有這些詞的存在，才讓你的業(yè)務代碼的高內(nèi)聚成為的有可能，小到設計一個方法一個類、再引申到一個接口一個服務、再到一個系統(tǒng)一個倉庫，這個原則始終不變。

上述問題帶來的解法很簡單，就是變成顯示依賴的關系，所謂顯示依賴是指的兩個依賴之間是確定的。什么是確定的？確定 ==?No Supprise?！對，不管什么時候，線上還是線下，我依賴你測試環(huán)境的接口返回是一個整數(shù)，到了線上，返回的也必須是一個整數(shù)、不能變成浮點數(shù)。而讓確定性變得可行的，不是君子協(xié)定；只能是一個版本依賴工具。比如說 Java 中的 Maven 正式的版本依賴。

結語

職責內(nèi)聚、依賴確定，是我們的應用變得真正 Cloud Native 的前提。沒有了這些基本的內(nèi)功，懂的開源軟件再多、對微服務棧再熟悉，也會有各種意想不到的事情出來，試想一下，如果應用的職責到處分散，那到時候擴容到底擴誰呢？如果依賴方變得及其不確定，誰又來為每次發(fā)版的不確定的成本買單？Be Cloud Native，請從應用代碼托管的住所開始。

?