技改之路：從單塊應用到微服務，我的血淚總結--轉

原文地址：http://chuansong.me/n/346948051463

技改是技術改造的簡稱，是技術的蛻變。本文指的是在公司技術發展的某個瓶頸階段，按原有開發和組織方式已經無法玩下去，這時公司希望引進架構師或技術牛人，來破解當前困局。技術改造，對於公司和技術人員而言都非常難得，參與者多，主導者少。我有幸前後主導過3次OTA系統的技改，規模有大有小，每次環境和問題雖不一樣，但還是有套路可循。

《技改之路》少講技術多講路，我們不過多的關注技術細節和中介軟體的實現，而重點講述技術改造的過程和思考，以下是本次分享的Topic：

• 系統背景

• 前期工作

• 技改實施

• 總結

一、系統背景

1、技術規模

公司

• 國內領先的B2B機票分銷平臺

• 資本原始積累，財務良好，一直盈利

系統規模

• 200+應用

• 100+庫，1萬+表

研發規模

• 開發人員200人左右

• 伺服器有200臺左右

此案例是一箇中等規模的電子商務公司，老闆白手起家，資本原始積累，現在賺錢的網際網路公司很少哦。公司從2006年的幾個研發人員，到技改前的200個左右研發人員，業務發展良好，是國內領先的B2B機票分銷平臺，網際網路名聲雖不大，但處於悶聲發大財的狀態。

公司之前嘗試過2次系統重建，請了一批批的牛人，前後經歷過4年。公司消耗大，但都以失敗告終。此案例是我本人的第2次技改，效果不錯，整體進展順利，團隊技術水平也有1~2個檔次的提升，算是比較成功的實踐。另外，因為案例過於真實，有些UML會打上馬賽克，請多諒解。

2、單塊應用

3、主要問題

• 單塊應用，該合併的沒有合併，該拆開的沒有拆開，單個體量不合理，主平臺體量太大，其它又過小；

• 技術過舊：使用7年以前的技術，主平臺採用單塊應用，且體量過大，無法整體更新維護；

• 多版本共存：版本混亂，只敢新增，不敢修改；

• 整個系統非常脆弱，問題多，訪問量一大就掛；

• 管理問題：釋出困難、測試困難、修改困難、排錯困難。

二、前期工作

1、架構部組建

成立架構部：

• 內招幾名老程式設計師，外招幾個架構師

培養：

• 內部走出去，提高眼界；外部牛人請進來，落地瞭解歷史和業務

制度：

• 專案管理+知識分享： JIRA+WIKI

• 團隊建設、技術分享、工程師文化

2、總體規劃

架構是演化出來的還是設計出來的？對於創業場景，創業本身就是在未知中尋找機會，將不清楚變為清楚，系統的架構自然是演化出來的，而對於技術改造或Google搜尋等複雜工程場景，系統的架構當然要精心策劃。

公司電商系統總體架構，我們整整花了1個多月的時間，對專案做了總體的規劃，然後對內宣講推廣，讓每一個參與者瞭解自已的目標和價值。不手握地圖，你怎知站對了位置！

3、中介軟體構建

我們構建的中介軟體有：

job/redis/center Log/業務監控metrics/dashboad/除錯工具windbg/rabbitMQ/ORM工具dapper/MongoDB/jetermclient/公共類庫jFX/zookeeper/openTSDB/HBase/searcher工具solr/後設資料管理DDM/DLL管理nuget/自動釋出Jenkins/微服務架構JSOA/

中介軟體是應用系統的基礎設施，是應用的裝備和工具。農村建住房是一塊磚一塊磚的往上壘，城市建大house則是先打地基，然後再建主框架，最後才是壘磚，所以中介軟體的建設是大中型系統建設的前提。

以上中件間的構建過程貫穿於整個技改的生命週期，每一箇中介軟體可能需要花1~2個月，它們大部分都基於開源。請關注上面的順序，直面當前的問題，按需快速構建和推動。雖然使用開源，但中件間的引進和改造有自已的一套流程：調查 => 試用 => 選型 => 深入研究 => demo => wiki => 分享推廣 => 業務系統試用 => 改進完善 => 大規模推廣。

中介軟體的構建和增加，不僅對當前業務系統影響較小，還可以解決一部分業務難題，減輕資料庫的壓力。同時它還有利於建立技術氛圍和分享機制。一支有激情、愛技術的研發團隊，對技改的具體實施是非常重要的。

三、技改實施

1、資料庫改造

當面對100個多庫時，我認為系統架構師關注到資料庫級別即可，建庫拆庫。資料庫按模組整體遷移，其實並沒有想象中那麼難，理想情況下只需修改資料庫的連結，而對於表和欄位的優化，可由應用架構師或技術主管，以SOA收口或應用重構來實現。

資料庫如何做到可伸縮，可大可小方便拆分呢，思考如下：

1. 上圖從內往外看，一個框即可以是一個庫，也可以是一個模組，還可以是一個表，根據當前業務規模和系統複雜度來實現；

2. 我們的大實體關係圖具體為：產品、使用者、訂單、結算、基礎設施。它們早期可以是一個庫，裡面有5個模組，中期可以分為5個庫，後期則可以更底級別分為更多的庫；

3. 命名規範：資料庫名：業務線縮寫+庫名；模組名：參考大E-R圖+專業詞彙縮寫；表名：模組縮寫+表名；自增編號：表名+ID；

4. 模組內可多表聯接，模組間減少聯接，資料庫間不允許聯接；

5. 每一個資料庫有且僅有一個Owner組，原則上只允許一個團隊才能Create，其它團隊訪問需要分級控制，L1為介面，L2為只讀庫，L3為直接讀寫“寫庫”。

資料庫規劃

資料庫是整個資訊系統中生命週期最長、最難修改的部分。所以讓時間來解決時間的問題，要加強設計，具體實施過程如下：

1. 在地圖即總體架構文件推廣後，我們就新建立了一批庫，這在早期還遭到DBA的抱怨；

2. 新增相關庫後，新表按新規則建立，特殊情況走特珠審批；

3. 去SP去關聯，讓資料庫減少計算，迴歸儲存本質；

4. 資料庫拆分，改表改欄位，採用模組整體遷移或應用重構；

5. 一年後，再去看資料庫，發現在沒有特別立項和驅動的情況下，已接近一半的表在新庫中。

資料變遷

狀態圖是資料的變遷，是資料與行為的互動，資料的變化會引起行為的變化，行為的變化會產生資料的不同。上圖是國內的訂單狀態變遷圖，它的價值不僅屬於資料庫層，還在於SOA服務化和核心業務流程。

2、服務改造

服務是動詞，是行為或活動的抽象，它的價值在於業務邏輯或行為的重用，具體實施過程如下：

1. 服務列表和服務協議，在設計階段使用Excel表格；

2. 統一Request/Response規範；

3. 服務實現，因沒有直接可見的業務價值輸出，最好以工單或專案來落地；

4. 服務治理，早期沒有工具時，使用WIKI做簡單管理，後期使用專業的服務治理工具。

領域模型

沒有領域圖的架構設計都是耍流氓，我們畫領域圖的架構師是2位老員工，沒有多少高大上，甚至於他們之前沒有畫過UML，但我們的狀態圖和領域模型都是出自他們之手。其實畫領域圖的關鍵是懂事物本身，並知道它們的關係。我們的領域圖與業務模型中的5大業務流程一一對應，包括：預訂流程，訂單處理流程，產品供應流程，財務結算流程，賬戶管理流程。

微服務

我們的微服務JSOA V2.0是基於ServiceStack當時最新的版本號4.0.50實現的，它本身支援輕量級協議和Metadata，以及Swagger，是微服務的一種架構實現。另外，它還可以再擴充套件以API Gateway的方式實現Open API。

微服務MSA與我們之前的SOA、ESB有什麼區別呢？

• ESB有匯流排和聰明的管道管理能力；

• SOA弱化了中間的管道和匯流排，強化了兩端；

• 微服務MSA使用通用的輕量級協議和更加web化（RESTFUL）。

3、應用架構改造

系統是什麼？系統=元素+關係。應用架構是什麼？應用架構=應用+架構。應用就是系統的最小單元，應用分級和應用編號則構成了應用關係即應用的架構，它有利於應用的管理、互動和追蹤。應用分為產品線，子系統和應用3級，每一級編號為2位，如100206。應用要從使用者的視角出發，先有使用者，然後有應用功能，這樣才是以使用者為中心去構建系統。

4、組織架構微調

組織架構沒有最佳實踐，只有適合於自已當前的選擇，以下是組織架構與技術架構對齊方面的思考：

1. 藝術與工程相關分離：UED；

2. 軟體開發與硬體相分離：運維；

3. 技術研發與業務研發相分離：架構部；

4. 需求，實施，驗收相分離：每業務線分產品組、開發組、測試組；

5. 開發按業務職責相分離：預訂組、產品組、訂單組；

6. 專業技術委員會制：測試、產品、開發、輪流主持，設委員長；

四、總結

1、過程總結

第一步總體規劃：手握地圖，明確路線；

第二步資料庫：建庫拆庫，去join去SP；

第三步中介軟體：按需構建，先增加常用；

第四步服務：技改=工單，有業務價值輸出；

第五步應用：拆應用，建門戶Portal，重構應用；

第六步組織架構微調：組架技術與組織架構對齊，技改之後調整；

第七步固化：框架化，自動化，管理過程工具化如DevOps。

2、經驗感悟

• 從服務入手是錯的，從資料庫或中介軟體入手是正確的。服務屬於高階階段，方便行為的重用，是深層次優化，但太慢了；

• 從當前問題或故障入手，要先滅火，逆向分析dump工具很重要；

• 歷史要尊重，早期不可做大的改動，不能過多地影響現有業務。建議只做加法，建新庫和新中介軟體，這樣就不會有太多阻力和負擔；

• 一般不能全部重建，除非系統較小，系統規模大時只能拆分後分步重構；

• 技術並不是技改過程中最複雜的，人和事及關係才是麻煩的部分，歷史問題的後面是人；

• 每次環境和問題都不一樣，要有準備脫一層皮的心態。

3、通盤無妙招

技改是大折騰，於公司於個人而言都是，小改怡情，大改傷身，我們應該避免大的技術改造，但此現象又比較常見，特別是業務發展快的創業公司。所以真正高手下棋，應該是通盤無妙招，讓正確的事情很容易發生，基於自然的演化來實現技術的演進。

怎樣才能通盤無妙招，系統良性長久的發展？我們需要兩個力量，一個是技術，一個是業務，如果只重視業務，而很容易在技術上積勞成疾，如果完全技術驅動，則又容易忘記業務目標。所以它們應該相伴相生，共同發展，在大的技術改造實施之後，在框架和流程相對固化後，小的技術重構專案應該長期存在，這樣才能良性迴圈，讓系統進入自然演進的狀態。

互動問答

問題：請問張老師如果再來一次技改你會怎麼做？在你做過的技改過程中你覺得你最大的收穫是什麼？覺得做的不好的又是什麼？

這個問題非常好，為了更好回答您的問題，我簡單介紹一下本人的3次技改經歷。我的第1次技改是重建，專案從10月份到第二年8月，歷史10個月，可以說是技術成功專案失敗。第2次技改是重構，只管技術，少管人和業務，整體效果好，可以歸結為成功。第3次技改還是重構，既管技術又管人，且業務處於高速發展期，資源少，可以總結為技術與業務相伴相生，技術效果一般。

如果以後還有機會，自已就不再直接負責了，實在是太累，從內外各招幾個架構師，並按上面的工作流程和方式，然後把握好技術與業務的關係和資源佔用即可。回到具體問題：

• 如果再來一次，我會多參考第2次技改經驗，即PPT分享的過程總結；

• 技改後的收穫是脫胎換骨，技術和管理都有很大提升；

• 不好的地方：要更多的關注業務，以及平衡好業務與技術的關係。

問題：單塊應用向微服務遷移時，平滑過渡有什麼技巧？如何解決分散式事務一致性呢？還有關於微服務持續交付、測試、監控（語義監控）方面有落地工具嗎？

1. 平滑過渡的技術：直面當前系統的問題，不斷有價值輸出，然後參考上面的過程總結，先規劃，然後中介軟體和資料庫，最後是服務和應用；

2. 分散式事務一致性：使用替代方案，如最終一致；

3. 落地工具：MSA與SOA的治理沒有本質差別，還是DevOps/Trace/Metrics/，我們使用的是ServiceStack/JMetrics/CenterLog/Jenkins/。

問題：如果舊有模組關聯複雜，又影響現有系統效能，相關開發人員流失，不好梳理，改造有風險，重寫老闆不答應，該如何取捨呢?

• 舊有模組關聯複雜，又影響現有系統效能：先滅火解決當前故障, 逆向分析dump工具；

• 相關開發人員流失：引進中件間，建立分享機制和學習型團隊，講技改總體規劃，讓每個人瞭解自已的價值和目標；

• 不好梳理，改造有風險：內招幾個老員工成為應用架構師；

• 重寫老闆不答應：有業務價值輸入，技改==工單或專案，藉助業務專案來實現技改。