建站
咨詢
售后
建站咨詢
新聞中心
一、重構中的外部準備工作
技改在任何時候都是個敏感的事情。大量的問題需要擺平，天時地利人和，缺一不可。
1. 天時
即選擇合適時機進行技術改造工作。在時機的選擇上，我們經(jīng)歷了三個階段。
（1）空閑時段
在開發(fā)企業(yè)應用時，技術改進也是常見的工作。企業(yè)應用開發(fā)的特點是有忙有閑。在版本發(fā)布前都緊鑼密鼓進行開發(fā)工作;在老版本發(fā)布之后，新版本剛剛啟動開發(fā)時，有相對空閑時間，可以進行技術改進。 而當這一套方法搬到互聯(lián)網(wǎng)應用開發(fā)上時，卻發(fā)現(xiàn)基本行不通?；ヂ?lián)網(wǎng)應用開發(fā)是兩種情況：很忙和非常忙。預留大片的時間進行技術改進，幾乎是不現(xiàn)實的。如果有業(yè)務可以有空閑時間做技改，那基本上也就沒必要改了，因為這也意味著這個業(yè)務進入穩(wěn)定和衰退期。
（2）隨需改進
既然找不到空閑時段，另一個選擇是隨需進行，也就是在項目開發(fā)過程中，對涉及到的模塊進行改進。而在實踐中，我們也發(fā)現(xiàn)這種做法難度很大。
- 遺留系統(tǒng)的模塊依賴關系往往令人匪夷所思，改進過程中，經(jīng)常會發(fā)現(xiàn)需要對所依賴的底層模塊進行大調整，導致改進工作無法進行。
- 就算是所依賴的模塊沒有問題，改進工作也會導致更多的時間開銷，2~3倍都是正常的。這個延遲不是所有項目都能夠承受的。
（3）優(yōu)化團隊
比較適合互聯(lián)網(wǎng)應用開發(fā)的做法，是組建專門團對進行技術改進。預留大約30%的開發(fā)能力來進行技改。這些人可以是專門負責架構改進的，也可以從項目組中抽調輪崗。
- 改進前，制定改進計劃，循序將近進行。涉及到具體模塊改進時，抽調負責該模塊的技術人員來參與。
- 如果模塊改進和業(yè)務開發(fā)工作同時開展，則可以考慮將這兩個工作合并進行。
技改不能一哄而上，也不能蜻蜓點水的做。他是一個持續(xù)的過程，循序將近，不要中斷。項目緊的時候挑選風險小的任務來執(zhí)行，少安排幾個重構點。項目松的時候重構下核心接口，多安排些重構。但是不要中斷。 一旦中斷，往往結果是沒有人會愿意繼續(xù)。重構往往是個前人栽樹 后人乘涼的事，風險又大，短期看不到效果，大家做著做著，往往就放棄了。所以持續(xù)改進是必須的，避免半途而廢。
還有一個大家容易忽略的地方，對于特別看重績效的團隊，按照產(chǎn)出來度量工作成果，那必須果斷避開績效考評的這段敏感時期。
2. 地利
所謂地利，從軟件角度，主要是基礎設施的建設。在針對現(xiàn)有系統(tǒng)進行改進，推動微服務架構前，需要評估下當前的基礎設施建設是否能夠滿足要求。 服務所需要的基礎設施包括:
（1）虛機環(huán)境或者docker
不同服務的線上壓力和運行環(huán)境需求不同，內(nèi)存，CPU，磁盤需求也不一樣。按照服務需要自動彈性創(chuàng)建所需要的環(huán)境，是微服務部署的前置條件。
（2）版本控制軟件
版本控制不僅僅是協(xié)調人和人之間的協(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）上級的支持
毫無疑問，上級領導支持是前提條件。重構是高風險的工作，往往不容易立即出新成果，而且還需要額外的投入。幾個月內(nèi)，沒有新東西，出貨速度變慢，沒有其他因素，不是重構就是在怠工。從公司層面，更高層的人越能知道什么時機適合開展重構工作。公司馬上要架構調整了，系統(tǒng)快下架了，近期有重大活動需要支持，有人需要盡快出成果來晉升….都需要慎重評估是否可以進行重構，而這些事情，越高層的人掌握的信息越多，所以得到他們的支持是必須的。
（2）團隊成員的認可
其次是團隊成員們認可。特別是老系統(tǒng)的開發(fā)人員，他們認可和毫無保留的支持是必要的條件。他們最清楚系統(tǒng)有哪些坑，哪些是必須改動的，哪些是沒有用的功能，哪些只是臨時的解決方案。這樣才可以在功能遷移時，有目的地進行調整。
二、重構中的內(nèi)部準備工作
隨著系統(tǒng)改進工作的進行，一些架構性的問題也越來越突出。在開發(fā)中，一個遺留接口是否要遷移到微服務架構上，哪些接口應該放到同一個項目上，項目應該如何組織，日志、監(jiān)控等基礎性的工作應該怎么統(tǒng)一規(guī)劃，都需要從架構的層面來進行設計。
1. 確定目標
公司每一年都會有一個明確的戰(zhàn)略目標，這個目標最終會被分解到每個業(yè)務上去實施。 對于支付業(yè)務，我們的目標是：
（1）持續(xù)提升支付成功率
支付成功率是支付業(yè)務的***衡量指標。提升成功率的首要措施是提升系統(tǒng)的穩(wěn)定性，在此基礎上，通過簡化支付流程、優(yōu)化支付路由等措施，提升轉化率。
（2）持續(xù)降低支付成本
在保證支付的穩(wěn)定的前提下，引入更多底成本的渠道，通過支持渠道優(yōu)惠活動等措施，來降低支付成本。
（3）支持進入新市場
配合公司的市場拓展需求，為新市場提供支付支持。
2. 原則
為了和目標保持一致，我們制定了一些微服務的架構規(guī)則。當然，這些規(guī)則也是隨著團隊的進步、業(yè)務的變更做調整。 我們的原則是參考Heroku的12 Factor而制定的。
以下原則是在剛啟動微服務架構改進的時候制定的。
（1）虛機開發(fā)
所有開發(fā)工作必須在虛機上進行，不得使用個人物理機開發(fā)。這使得開發(fā)人員能夠隨時在任何地方調起開發(fā)環(huán)境，避免由于環(huán)境配置問題而影響問題修復。
（2）版本控制
使用Git做版本控制。 每個項目都有一個基準代碼庫，部署時從主干獲取代碼。上線時對主干打Tag，每個Tag對應一個線上可執(zhí)行代碼。 測試環(huán)境、預部署環(huán)境和線上環(huán)境都使用相同的基準代碼。
（3）代碼審核
為了保證代碼質量，所有代碼必須通過至少兩位工程師的審核才可以簽入到主干版本中。執(zhí)行日常代碼審核，避免在部署前進行突擊式審核。
（4）自動部署
開發(fā)人員不得直接將開發(fā)機上的構件推送到測試、線上環(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）同構環(huán)境
確保開發(fā)、測試和線上環(huán)境的同構。這包括如下內(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上可以多次調用;
- 如果某一個server上調用出現(xiàn)網(wǎng)絡問題，客戶端可以進行重試并將請求轉發(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í)行過程中也會不斷地進行補充和調整。除了在code review中確保這些規(guī)范被落地執(zhí)行外，每周周會也會對異常執(zhí)行情況進行分析，確保規(guī)范制定是符合實際需求的，并能夠與時俱進地進行調整。 當然，最重要的規(guī)范，是軟件過程的規(guī)范：支付系統(tǒng)開發(fā)的軟件過程規(guī)范。在微服務開發(fā)的軟件過程一文中有詳細介紹。
4. 團隊建設
微服務架構是否能夠順利實施，離不開團隊成員的支持，以及團隊能力的提升。團隊建設一直是整個技改過程的重中之重。 團隊建設本身是一個大話題。這里重點介紹我們在團隊分工上的工作。
團隊的分工和整個架構設計需保持一致(又是康威定律)。在架構設計上，我們采取的整體策略，是參考原有的SSH架構，將業(yè)務邏輯和接口實現(xiàn)分離，將進程內(nèi)調用改造成進程外調用，并在此基礎上做切分。 這樣，在團隊劃分上，前期，是按照層來分工，分為如下三個小團隊：
- 接口服務團隊，開發(fā)對外的接口，對接業(yè)務系統(tǒng)以及Android，IOS,PCWeb等各端。隨著業(yè)務的發(fā)展在，這個團隊也會逐步按照端來進一步分解。
- 基礎服務團隊，為對外接口提供業(yè)務邏輯服務。這也是***的一個團隊，隨著業(yè)務的發(fā)展，這個團隊也會逐步按照業(yè)務進行拆分，分裂成賬戶、支付、交易等小團隊。
- 基礎設施團隊，負責支持上述工作的各種規(guī)范的制定，以及支持這些規(guī)范實現(xiàn)的基礎設施。
【本文為專欄作者“鳳凰牌老熊”的原創(chuàng)稿件，轉載請通過微信公眾號“鳳凰牌老熊”聯(lián)系作者本人】
網(wǎng)頁標題：重構中的外部和內(nèi)部準備工作
網(wǎng)站路徑：http://www.5511xx.com/article/dppopes.html
