[[185018]]

一、重構(gòu)中的外部準(zhǔn)備工作

技改在任何時候都是個敏感的事情。大量的問題需要擺平，天時地利人和，缺一不可。

1. 天時

即選擇合適時機(jī)進(jìn)行技術(shù)改造工作。在時機(jī)的選擇上，我們經(jīng)歷了三個階段。

（1）空閑時段

在開發(fā)企業(yè)應(yīng)用時，技術(shù)改進(jìn)也是常見的工作。企業(yè)應(yīng)用開發(fā)的特點(diǎn)是有忙有閑。在版本發(fā)布前都緊鑼密鼓進(jìn)行開發(fā)工作;在老版本發(fā)布之后，新版本剛剛啟動開發(fā)時，有相對空閑時間，可以進(jìn)行技術(shù)改進(jìn)。 而當(dāng)這一套方法搬到互聯(lián)網(wǎng)應(yīng)用開發(fā)上時，卻發(fā)現(xiàn)基本行不通?；ヂ?lián)網(wǎng)應(yīng)用開發(fā)是兩種情況：很忙和非常忙。預(yù)留大片的時間進(jìn)行技術(shù)改進(jìn)，幾乎是不現(xiàn)實(shí)的。如果有業(yè)務(wù)可以有空閑時間做技改，那基本上也就沒必要改了，因為這也意味著這個業(yè)務(wù)進(jìn)入穩(wěn)定和衰退期。

（2）隨需改進(jìn)

既然找不到空閑時段，另一個選擇是隨需進(jìn)行，也就是在項目開發(fā)過程中，對涉及到的模塊進(jìn)行改進(jìn)。而在實(shí)踐中，我們也發(fā)現(xiàn)這種做法難度很大。

• 遺留系統(tǒng)的模塊依賴關(guān)系往往令人匪夷所思，改進(jìn)過程中，經(jīng)常會發(fā)現(xiàn)需要對所依賴的底層模塊進(jìn)行大調(diào)整，導(dǎo)致改進(jìn)工作無法進(jìn)行。
• 就算是所依賴的模塊沒有問題，改進(jìn)工作也會導(dǎo)致更多的時間開銷，2~3倍都是正常的。這個延遲不是所有項目都能夠承受的。

（3）優(yōu)化團(tuán)隊

比較適合互聯(lián)網(wǎng)應(yīng)用開發(fā)的做法，是組建專門團(tuán)對進(jìn)行技術(shù)改進(jìn)。預(yù)留大約30%的開發(fā)能力來進(jìn)行技改。這些人可以是專門負(fù)責(zé)架構(gòu)改進(jìn)的，也可以從項目組中抽調(diào)輪崗。

• 改進(jìn)前，制定改進(jìn)計劃，循序?qū)⒔M(jìn)行。涉及到具體模塊改進(jìn)時，抽調(diào)負(fù)責(zé)該模塊的技術(shù)人員來參與。
• 如果模塊改進(jìn)和業(yè)務(wù)開發(fā)工作同時開展，則可以考慮將這兩個工作合并進(jìn)行。

技改不能一哄而上，也不能蜻蜓點(diǎn)水的做。他是一個持續(xù)的過程，循序?qū)⒔?，不要中斷。項目緊的時候挑選風(fēng)險小的任務(wù)來執(zhí)行，少安排幾個重構(gòu)點(diǎn)。項目松的時候重構(gòu)下核心接口，多安排些重構(gòu)。但是不要中斷。 一旦中斷，往往結(jié)果是沒有人會愿意繼續(xù)。重構(gòu)往往是個前人栽樹 后人乘涼的事，風(fēng)險又大，短期看不到效果，大家做著做著，往往就放棄了。所以持續(xù)改進(jìn)是必須的，避免半途而廢。

還有一個大家容易忽略的地方，對于特別看重績效的團(tuán)隊，按照產(chǎn)出來度量工作成果，那必須果斷避開績效考評的這段敏感時期。

2. 地利

所謂地利，從軟件角度，主要是基礎(chǔ)設(shè)施的建設(shè)。在針對現(xiàn)有系統(tǒng)進(jìn)行改進(jìn)，推動微服務(wù)架構(gòu)前，需要評估下當(dāng)前的基礎(chǔ)設(shè)施建設(shè)是否能夠滿足要求。 服務(wù)所需要的基礎(chǔ)設(shè)施包括:

（1）虛機(jī)環(huán)境或者docker

不同服務(wù)的線上壓力和運(yùn)行環(huán)境需求不同，內(nèi)存，CPU，磁盤需求也不一樣。按照服務(wù)需要自動彈性創(chuàng)建所需要的環(huán)境，是微服務(wù)部署的前置條件。

（2）版本控制軟件

版本控制不僅僅是協(xié)調(diào)人和人之間的協(xié)作，同時也是保證線上運(yùn)行的系統(tǒng)必須是最終正式的版本。一旦出現(xiàn)問題，開發(fā)人員可以從版本控制服務(wù)器上下載到一致的代碼?，F(xiàn)在一般用git來實(shí)現(xiàn)。為什么不用SVN,網(wǎng)上有很多對比文章，不是本文重點(diǎn)。

（3）代碼評審軟件

每個微服務(wù)作為獨(dú)立的項目來開發(fā)，統(tǒng)一編碼規(guī)范，審核代碼邏輯等，在這場景下猶為重要。和git相配合，gitlab是優(yōu)先考慮的codereview軟件。

（4）集成發(fā)布

集群對微服務(wù)是必不可少的基礎(chǔ)環(huán)境，將一個服務(wù)部署到幾十，甚至上千臺機(jī)器上是必要的。這種情況下，人工部署是不現(xiàn)實(shí)的，依賴于集成發(fā)布環(huán)境，實(shí)現(xiàn)獲取版本，集成編譯，備份老版本，發(fā)布新版本，啟動服務(wù)，暫停服務(wù)和重啟服務(wù)。推薦使用jenkins。

（5）系統(tǒng)監(jiān)控

監(jiān)控自動化也是必要的基礎(chǔ)設(shè)施。對出問題的服務(wù)報警，在高峰期對核心服務(wù)進(jìn)行監(jiān)控，都必須借助監(jiān)控系統(tǒng)來處理。推薦使用zabbix。

（6）日志分析

排查錯誤和對系統(tǒng)進(jìn)行審查，日志處理是不可避免的。想跟蹤某個ID用戶的行為，在幾百臺機(jī)器上逐個查看日志也是不現(xiàn)實(shí)的。使用工具，如ELK，將日志收集到一個存儲中，提供檢索功能來查看日志，甚至對日志做統(tǒng)計分析，也是必須的設(shè)施。

（7）辦公環(huán)境

不用說，新老系統(tǒng)開發(fā)人員得在一起辦公，隨時交流。如果條件無法滿足，那至少必須建立順暢的溝通方式，比如QQ群，微信群等。郵件并不是一個好的選擇，電話會議也是不錯的。

3. 人和

最重要的因素?？傮w上包括三個方面內(nèi)容，上級領(lǐng)導(dǎo)的支持，團(tuán)隊成員的認(rèn)可，合作部門的理解。

（1）上級的支持

毫無疑問，上級領(lǐng)導(dǎo)支持是前提條件。重構(gòu)是高風(fēng)險的工作，往往不容易立即出新成果，而且還需要額外的投入。幾個月內(nèi)，沒有新東西，出貨速度變慢，沒有其他因素，不是重構(gòu)就是在怠工。從公司層面，更高層的人越能知道什么時機(jī)適合開展重構(gòu)工作。公司馬上要架構(gòu)調(diào)整了，系統(tǒng)快下架了，近期有重大活動需要支持，有人需要盡快出成果來晉升….都需要慎重評估是否可以進(jìn)行重構(gòu)，而這些事情，越高層的人掌握的信息越多，所以得到他們的支持是必須的。

（2）團(tuán)隊成員的認(rèn)可

其次是團(tuán)隊成員們認(rèn)可。特別是老系統(tǒng)的開發(fā)人員，他們認(rèn)可和毫無保留的支持是必要的條件。他們最清楚系統(tǒng)有哪些坑，哪些是必須改動的，哪些是沒有用的功能，哪些只是臨時的解決方案。這樣才可以在功能遷移時，有目的地進(jìn)行調(diào)整。

二、重構(gòu)中的內(nèi)部準(zhǔn)備工作

隨著系統(tǒng)改進(jìn)工作的進(jìn)行，一些架構(gòu)性的問題也越來越突出。在開發(fā)中，一個遺留接口是否要遷移到微服務(wù)架構(gòu)上，哪些接口應(yīng)該放到同一個項目上，項目應(yīng)該如何組織，日志、監(jiān)控等基礎(chǔ)性的工作應(yīng)該怎么統(tǒng)一規(guī)劃，都需要從架構(gòu)的層面來進(jìn)行設(shè)計。

1. 確定目標(biāo)

公司每一年都會有一個明確的戰(zhàn)略目標(biāo)，這個目標(biāo)最終會被分解到每個業(yè)務(wù)上去實(shí)施。 對于支付業(yè)務(wù)，我們的目標(biāo)是：

（1）持續(xù)提升支付成功率

支付成功率是支付業(yè)務(wù)的***衡量指標(biāo)。提升成功率的首要措施是提升系統(tǒng)的穩(wěn)定性，在此基礎(chǔ)上，通過簡化支付流程、優(yōu)化支付路由等措施，提升轉(zhuǎn)化率。

（2）持續(xù)降低支付成本

在保證支付的穩(wěn)定的前提下，引入更多底成本的渠道，通過支持渠道優(yōu)惠活動等措施，來降低支付成本。

（3）支持進(jìn)入新市場

配合公司的市場拓展需求，為新市場提供支付支持。

2. 原則

為了和目標(biāo)保持一致，我們制定了一些微服務(wù)的架構(gòu)規(guī)則。當(dāng)然，這些規(guī)則也是隨著團(tuán)隊的進(jìn)步、業(yè)務(wù)的變更做調(diào)整。 我們的原則是參考Heroku的12 Factor而制定的。

以下原則是在剛啟動微服務(wù)架構(gòu)改進(jìn)的時候制定的。

（1）虛機(jī)開發(fā)

所有開發(fā)工作必須在虛機(jī)上進(jìn)行，不得使用個人物理機(jī)開發(fā)。這使得開發(fā)人員能夠隨時在任何地方調(diào)起開發(fā)環(huán)境，避免由于環(huán)境配置問題而影響問題修復(fù)。

（2）版本控制

使用Git做版本控制。 每個項目都有一個基準(zhǔn)代碼庫，部署時從主干獲取代碼。上線時對主干打Tag，每個Tag對應(yīng)一個線上可執(zhí)行代碼。 測試環(huán)境、預(yù)部署環(huán)境和線上環(huán)境都使用相同的基準(zhǔn)代碼。

（3）代碼審核

為了保證代碼質(zhì)量，所有代碼必須通過至少兩位工程師的審核才可以簽入到主干版本中。執(zhí)行日常代碼審核，避免在部署前進(jìn)行突擊式審核。

（4）自動部署

開發(fā)人員不得直接將開發(fā)機(jī)上的構(gòu)件推送到測試、線上環(huán)境。 build, release和run必須分離。 自動部署系統(tǒng)(Jenkins)將從版本控制服務(wù)器上下載代碼，編譯并發(fā)布到各個stage server上。

（5）橫向擴(kuò)展

所有系統(tǒng)必須可以通過多進(jìn)程部署的方式進(jìn)行擴(kuò)展。 這就要求：

• 所有系統(tǒng)可以運(yùn)行在一個或多個進(jìn)程中。 但所有進(jìn)程必須是無狀態(tài)的，進(jìn)程之間是無共享的。 對于Web來說，特別注意避免依賴session。如有需要，session需保存在membcached或者redis等內(nèi)存緩存中。
• 所有進(jìn)程運(yùn)行時動態(tài)綁定到端口來提供服務(wù)。
• 避免使用守護(hù)進(jìn)程或者PID文件。

（6）同構(gòu)環(huán)境

確保開發(fā)、測試和線上環(huán)境的同構(gòu)。這包括如下內(nèi)容：

• 各stage下所使用的操作系統(tǒng)環(huán)境是一致的。
• 各stage下所使用的容器是一致的，包括JVM版本、容器版本;
• 各stage下所使用的數(shù)據(jù)庫及其版本是一致的。
• 測試和線上環(huán)境可以在部署實(shí)例數(shù)量上不同，但在測試環(huán)境中，對于每個系統(tǒng)，至少部署2個實(shí)例。
• 各個stage下的唯一差異是通過配置參數(shù)來控制的。

隨著基礎(chǔ)設(shè)施的完善，我們補(bǔ)充了如下原則：

（7）配置參數(shù)

與環(huán)境相關(guān)的配置信息，必須與代碼嚴(yán)格分離，包括數(shù)據(jù)庫、第三方證書、域名、和性能有關(guān)的配置(線程數(shù)、重試間隔等)。配置信息統(tǒng)一使用環(huán)境變量來存儲。

（8）冪等原則

所有的接口必須實(shí)現(xiàn)為冪等的，這包括：

• 該接口在同一個server上可以多次調(diào)用;
• 如果某一個server上調(diào)用出現(xiàn)網(wǎng)絡(luò)問題，客戶端可以進(jìn)行重試并將請求轉(zhuǎn)發(fā)到另一個server上執(zhí)行。

（9）啟動關(guān)閉

每個系統(tǒng)需提供啟動、關(guān)閉和驗證腳本。

• 系統(tǒng)在啟動時執(zhí)行必要的環(huán)境檢查，包括不得使用root賬戶來啟動應(yīng)用、端口是否被占用等。
• 啟動成功后，可以通過驗證腳本來確認(rèn)運(yùn)行狀態(tài)。
• 關(guān)閉腳本必須能夠優(yōu)雅終止進(jìn)程，這包括回退所有的連接、停止接收消息，完成所有待處理的消息，必要時執(zhí)行回滾等操作。

（10）收集日志

所有日志信息都必須通過終端收集到日志服務(wù)器上。

（11）監(jiān)控報警

所有線上運(yùn)行的系統(tǒng)，必須配置監(jiān)控和報警，并落實(shí)報警處理人員。

3. 制定規(guī)范

在原有的Java編碼規(guī)范的基礎(chǔ)上，針對本次技改，我們又制定如下規(guī)范：

• 支付系統(tǒng)監(jiān)控報警規(guī)范。在支付系統(tǒng)的監(jiān)控與報警 一文中有介紹。
• 支付系統(tǒng)Restful 接口設(shè)計規(guī)范。
• 支付系統(tǒng)RPC接口設(shè)計規(guī)范。 在微服務(wù)與RPC一文中有介紹。

這些規(guī)范在執(zhí)行過程中也會不斷地進(jìn)行補(bǔ)充和調(diào)整。除了在code review中確保這些規(guī)范被落地執(zhí)行外，每周周會也會對異常執(zhí)行情況進(jìn)行分析，確保規(guī)范制定是符合實(shí)際需求的，并能夠與時俱進(jìn)地進(jìn)行調(diào)整。 當(dāng)然，最重要的規(guī)范，是軟件過程的規(guī)范：支付系統(tǒng)開發(fā)的軟件過程規(guī)范。在微服務(wù)開發(fā)的軟件過程一文中有詳細(xì)介紹。

4. 團(tuán)隊建設(shè)

微服務(wù)架構(gòu)是否能夠順利實(shí)施，離不開團(tuán)隊成員的支持，以及團(tuán)隊能力的提升。團(tuán)隊建設(shè)一直是整個技改過程的重中之重。 團(tuán)隊建設(shè)本身是一個大話題。這里重點(diǎn)介紹我們在團(tuán)隊分工上的工作。

團(tuán)隊的分工和整個架構(gòu)設(shè)計需保持一致(又是康威定律)。在架構(gòu)設(shè)計上，我們采取的整體策略，是參考原有的SSH架構(gòu)，將業(yè)務(wù)邏輯和接口實(shí)現(xiàn)分離，將進(jìn)程內(nèi)調(diào)用改造成進(jìn)程外調(diào)用，并在此基礎(chǔ)上做切分。 這樣，在團(tuán)隊劃分上，前期，是按照層來分工，分為如下三個小團(tuán)隊：

• 接口服務(wù)團(tuán)隊，開發(fā)對外的接口，對接業(yè)務(wù)系統(tǒng)以及Android，IOS,PCWeb等各端。隨著業(yè)務(wù)的發(fā)展在，這個團(tuán)隊也會逐步按照端來進(jìn)一步分解。
• 基礎(chǔ)服務(wù)團(tuán)隊，為對外接口提供業(yè)務(wù)邏輯服務(wù)。這也是***的一個團(tuán)隊，隨著業(yè)務(wù)的發(fā)展，這個團(tuán)隊也會逐步按照業(yè)務(wù)進(jìn)行拆分，分裂成賬戶、支付、交易等小團(tuán)隊。
• 基礎(chǔ)設(shè)施團(tuán)隊，負(fù)責(zé)支持上述工作的各種規(guī)范的制定，以及支持這些規(guī)范實(shí)現(xiàn)的基礎(chǔ)設(shè)施。

【本文為51CTO專欄作者“鳳凰牌老熊”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號“鳳凰牌老熊”聯(lián)系作者本人】

戳這里，看該作者更多好文