重構中的外部和內部準備工作
一、重構中的外部準備工作
技改在任何時候都是個敏感的事情。大量的問題需要擺平，天時地利人和，缺一不可。
1. 天時
即選擇合適時機進行技術改造工作。在時機的選擇上，我們經歷了三個階段。
（1）空閑時段
在開發企業應用時，技術改進也是常見的工作。企業應用開發的特點是有忙有閑。在版本發布前都緊鑼密鼓進行開發工作;在老版本發布之后，新版本剛剛啟動開發時，有相對空閑時間，可以進行技術改進。 而當這一套方法搬到互聯網應用開發上時，卻發現基本行不通。互聯網應用開發是兩種情況：很忙和非常忙。預留大片的時間進行技術改進，幾乎是不現實的。如果有業務可以有空閑時間做技改，那基本上也就沒必要改了，因為這也意味著這個業務進入穩定和衰退期。
（2）隨需改進
既然找不到空閑時段，另一個選擇是隨需進行，也就是在項目開發過程中，對涉及到的模塊進行改進。而在實踐中，我們也發現這種做法難度很大。
- 遺留系統的模塊依賴關系往往令人匪夷所思，改進過程中，經常會發現需要對所依賴的底層模塊進行大調整，導致改進工作無法進行。
- 就算是所依賴的模塊沒有問題，改進工作也會導致更多的時間開銷，2~3倍都是正常的。這個延遲不是所有項目都能夠承受的。
（3）優化團隊
比較適合互聯網應用開發的做法，是組建專門團對進行技術改進。預留大約30%的開發能力來進行技改。這些人可以是專門負責架構改進的，也可以從項目組中抽調輪崗。
- 改進前，制定改進計劃，循序將近進行。涉及到具體模塊改進時，抽調負責該模塊的技術人員來參與。
- 如果模塊改進和業務開發工作同時開展，則可以考慮將這兩個工作合并進行。
技改不能一哄而上，也不能蜻蜓點水的做。他是一個持續的過程，循序將近，不要中斷。項目緊的時候挑選風險小的任務來執行，少安排幾個重構點。項目松的時候重構下核心接口，多安排些重構。但是不要中斷。 一旦中斷，往往結果是沒有人會愿意繼續。重構往往是個前人栽樹 后人乘涼的事，風險又大，短期看不到效果，大家做著做著，往往就放棄了。所以持續改進是必須的，避免半途而廢。
還有一個大家容易忽略的地方，對于特別看重績效的團隊，按照產出來度量工作成果，那必須果斷避開績效考評的這段敏感時期。
2. 地利
所謂地利，從軟件角度，主要是基礎設施的建設。在針對現有系統進行改進，推動微服務架構前，需要評估下當前的基礎設施建設是否能夠滿足要求。 服務所需要的基礎設施包括:
（1）虛機環境或者docker
不同服務的線上壓力和運行環境需求不同，內存，CPU，磁盤需求也不一樣。按照服務需要自動彈性創建所需要的環境，是微服務部署的前置條件。
（2）版本控制軟件
版本控制不僅僅是協調人和人之間的協作，同時也是保證線上運行的系統必須是最終正式的版本。一旦出現問題，開發人員可以從版本控制服務器上下載到一致的代碼。現在一般用git來實現。為什么不用SVN,網上有很多對比文章，不是本文重點。
（3）代碼評審軟件
每個微服務作為獨立的項目來開發，統一編碼規范，審核代碼邏輯等，在這場景下猶為重要。和git相配合，gitlab是優先考慮的codereview軟件。
（4）集成發布
集群對微服務是必不可少的基礎環境，將一個服務部署到幾十，甚至上千臺機器上是必要的。這種情況下，人工部署是不現實的，依賴于集成發布環境，實現獲取版本，集成編譯，備份老版本，發布新版本，啟動服務，暫停服務和重啟服務。推薦使用jenkins。
（5）系統監控
監控自動化也是必要的基礎設施。對出問題的服務報警，在高峰期對核心服務進行監控，都必須借助監控系統來處理。推薦使用zabbix。
（6）日志分析
排查錯誤和對系統進行審查，日志處理是不可避免的。想跟蹤某個ID用戶的行為，在幾百臺機器上逐個查看日志也是不現實的。使用工具，如ELK，將日志收集到一個存儲中，提供檢索功能來查看日志，甚至對日志做統計分析，也是必須的設施。
（7）辦公環境
不用說，新老系統開發人員得在一起辦公，隨時交流。如果條件無法滿足，那至少必須建立順暢的溝通方式，比如QQ群，微信群等。郵件并不是一個好的選擇，電話會議也是不錯的。
3. 人和
最重要的因素。總體上包括三個方面內容，上級領導的支持，團隊成員的認可，合作部門的理解。
（1）上級的支持
毫無疑問，上級領導支持是前提條件。重構是高風險的工作，往往不容易立即出新成果，而且還需要額外的投入。幾個月內，沒有新東西，出貨速度變慢，沒有其他因素，不是重構就是在怠工。從公司層面，更高層的人越能知道什么時機適合開展重構工作。公司馬上要架構調整了，系統快下架了，近期有重大活動需要支持，有人需要盡快出成果來晉升….都需要慎重評估是否可以進行重構，而這些事情，越高層的人掌握的信息越多，所以得到他們的支持是必須的。
（2）團隊成員的認可
其次是團隊成員們認可。特別是老系統的開發人員，他們認可和毫無保留的支持是必要的條件。他們最清楚系統有哪些坑，哪些是必須改動的，哪些是沒有用的功能，哪些只是臨時的解決方案。這樣才可以在功能遷移時，有目的地進行調整。
二、重構中的內部準備工作
隨著系統改進工作的進行，一些架構性的問題也越來越突出。在開發中，一個遺留接口是否要遷移到微服務架構上，哪些接口應該放到同一個項目上，項目應該如何組織，日志、監控等基礎性的工作應該怎么統一規劃，都需要從架構的層面來進行設計。
1. 確定目標
公司每一年都會有一個明確的戰略目標，這個目標最終會被分解到每個業務上去實施。 對于支付業務，我們的目標是：
（1）持續提升支付成功率
支付成功率是支付業務的***衡量指標。提升成功率的首要措施是提升系統的穩定性，在此基礎上，通過簡化支付流程、優化支付路由等措施，提升轉化率。
（2）持續降低支付成本
在保證支付的穩定的前提下，引入更多底成本的渠道，通過支持渠道優惠活動等措施，來降低支付成本。
（3）支持進入新市場
配合公司的市場拓展需求，為新市場提供支付支持。
2. 原則
為了和目標保持一致，我們制定了一些微服務的架構規則。當然，這些規則也是隨著團隊的進步、業務的變更做調整。 我們的原則是參考Heroku的12 Factor而制定的。
以下原則是在剛啟動微服務架構改進的時候制定的。
（1）虛機開發
所有開發工作必須在虛機上進行，不得使用個人物理機開發。這使得開發人員能夠隨時在任何地方調起開發環境，避免由于環境配置問題而影響問題修復。
（2）版本控制
使用Git做版本控制。 每個項目都有一個基準代碼庫，部署時從主干獲取代碼。上線時對主干打Tag，每個Tag對應一個線上可執行代碼。 測試環境、預部署環境和線上環境都使用相同的基準代碼。
（3）代碼審核
為了保證代碼質量，所有代碼必須通過至少兩位工程師的審核才可以簽入到主干版本中。執行日常代碼審核，避免在部署前進行突擊式審核。
（4）自動部署
開發人員不得直接將開發機上的構件推送到測試、線上環境。 build, release和run必須分離。 自動部署系統(Jenkins)將從版本控制服務器上下載代碼，編譯并發布到各個stage server上。
（5）橫向擴展
所有系統必須可以通過多進程部署的方式進行擴展。 這就要求：
- 所有系統可以運行在一個或多個進程中。 但所有進程必須是無狀態的，進程之間是無共享的。 對于Web來說，特別注意避免依賴session。如有需要，session需保存在membcached或者redis等內存緩存中。
- 所有進程運行時動態綁定到端口來提供服務。
- 避免使用守護進程或者PID文件。
（6）同構環境
確保開發、測試和線上環境的同構。這包括如下內容：
- 各stage下所使用的操作系統環境是一致的。
- 各stage下所使用的容器是一致的，包括JVM版本、容器版本;
- 各stage下所使用的數據庫及其版本是一致的。
- 測試和線上環境可以在部署實例數量上不同，但在測試環境中，對于每個系統，至少部署2個實例。
- 各個stage下的唯一差異是通過配置參數來控制的。
隨著基礎設施的完善，我們補充了如下原則：
（7）配置參數
與環境相關的配置信息，必須與代碼嚴格分離，包括數據庫、第三方證書、域名、和性能有關的配置(線程數、重試間隔等)。配置信息統一使用環境變量來存儲。
（8）冪等原則
所有的接口必須實現為冪等的，這包括：
- 該接口在同一個server上可以多次調用;
- 如果某一個server上調用出現網絡問題，客戶端可以進行重試并將請求轉發到另一個server上執行。
（9）啟動關閉
每個系統需提供啟動、關閉和驗證腳本。
- 系統在啟動時執行必要的環境檢查，包括不得使用root賬戶來啟動應用、端口是否被占用等。
- 啟動成功后，可以通過驗證腳本來確認運行狀態。
- 關閉腳本必須能夠優雅終止進程，這包括回退所有的連接、停止接收消息，完成所有待處理的消息，必要時執行回滾等操作。
（10）收集日志
所有日志信息都必須通過終端收集到日志服務器上。
（11）監控報警
所有線上運行的系統，必須配置監控和報警，并落實報警處理人員。
3. 制定規范
在原有的Java編碼規范的基礎上，針對本次技改，我們又制定如下規范：
- 支付系統監控報警規范。在支付系統的監控與報警 一文中有介紹。
- 支付系統Restful 接口設計規范。
- 支付系統RPC接口設計規范。 在微服務與RPC一文中有介紹。
這些規范在執行過程中也會不斷地進行補充和調整。除了在code review中確保這些規范被落地執行外，每周周會也會對異常執行情況進行分析，確保規范制定是符合實際需求的，并能夠與時俱進地進行調整。 當然，最重要的規范，是軟件過程的規范：支付系統開發的軟件過程規范。在微服務開發的軟件過程一文中有詳細介紹。
4. 團隊建設
微服務架構是否能夠順利實施，離不開團隊成員的支持，以及團隊能力的提升。團隊建設一直是整個技改過程的重中之重。 團隊建設本身是一個大話題。這里重點介紹我們在團隊分工上的工作。
團隊的分工和整個架構設計需保持一致(又是康威定律)。在架構設計上，我們采取的整體策略，是參考原有的SSH架構，將業務邏輯和接口實現分離，將進程內調用改造成進程外調用，并在此基礎上做切分。 這樣，在團隊劃分上，前期，是按照層來分工，分為如下三個小團隊：
- 接口服務團隊，開發對外的接口，對接業務系統以及Android，IOS,PCWeb等各端。隨著業務的發展在，這個團隊也會逐步按照端來進一步分解。
- 基礎服務團隊，為對外接口提供業務邏輯服務。這也是***的一個團隊，隨著業務的發展，這個團隊也會逐步按照業務進行拆分，分裂成賬戶、支付、交易等小團隊。
- 基礎設施團隊，負責支持上述工作的各種規范的制定，以及支持這些規范實現的基礎設施。
【本文為51CTO專欄作者“鳳凰牌老熊”的原創稿件，轉載請通過微信公眾號“鳳凰牌老熊”聯系作者本人】
