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

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

1. 天時

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

（1）空閑時段

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

（2）隨需改進

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

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

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

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

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

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

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

2. 地利

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

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

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

（2）版本控制軟件

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

（3）代碼評審軟件

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

（4）集成發(fā)布

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

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

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

（6）日志分析

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

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

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

3. 人和

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

（1）上級的支持

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

（2）團隊成員的認可

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

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

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

1. 確定目標

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

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

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

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

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

（3）支持進入新市場

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

2. 原則

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

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

（1）虛機開發(fā)

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

（2）版本控制

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

（3）代碼審核

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

（4）自動部署

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

（5）橫向擴展

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

• 所有系統(tǒng)可以運行在一個或多個進程中。 但所有進程必須是無狀態(tài)的，進程之間是無共享的。 對于Web來說，特別注意避免依賴session。如有需要，session需保存在membcached或者redis等內(nèi)存緩存中。
• 所有進程運行時動態(tài)綁定到端口來提供服務。
• 避免使用守護進程或者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ù)量上不同，但在測試環(huán)境中，對于每個系統(tǒng)，至少部署2個實例。
• 各個stage下的唯一差異是通過配置參數(shù)來控制的。

隨著基礎設施的完善，我們補充了如下原則：

（7）配置參數(shù)

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

（8）冪等原則

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

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

（9）啟動關閉

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

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

（10）收集日志

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

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

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

3. 制定規(guī)范

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

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

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

4. 團隊建設

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

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

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

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

本文題目：重構(gòu)中的外部和內(nèi)部準備工作
瀏覽地址：http://uogjgqi.cn/article/dppopes.html