原文地址：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收口或應用重構來實現。

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

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

我們的大實體關系圖具體為：產品、用戶、訂單、結算、基礎設施。它們早期可以是一個庫，里面有5個模塊，中期可以分為5個庫，后期則可以更底級別分為更多的庫；

命名規范：數據庫名：業務線縮寫+庫名；模塊名：參考大E-R圖+專業詞匯縮寫；表名：模塊縮寫+表名；自增編號：表名+ID；

模塊內可多表聯接，模塊間減少聯接，數據庫間不允許聯接；

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

數據庫規劃

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

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

新增相關庫后，新表按新規則創建，特殊情況走特珠審批；

去SP去關聯，讓數據庫減少計算，回歸存儲本質；

數據庫拆分，改表改字段，采用模塊整體遷移或應用重構；

一年后，再去看數據庫，發現在沒有特別立項和驅動的情況下，已接近一半的表在新庫中。

數據變遷

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

2、服務改造

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

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

統一Request/Response規范；

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

服務治理，早期沒有工具時，使用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、組織架構微調

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

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

軟件開發與硬件相分離：運維；

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

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

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

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

四、總結

1、過程總結

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

第二步數據庫：建庫拆庫，去join去SP；

第三步中間件：按需構建，先增加常用；

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

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

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

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

2、經驗感悟

• 從服務入手是錯的，從數據庫或中間件入手是正確的。服務屬于高級階段，方便行為的重用，是深層次優化，但太慢了；

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

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

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

• 技術并不是技改過程中最復雜的，人和事及關系才是麻煩的部分，歷史問題的后面是人；

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

3、通盤無妙招

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

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

互動問答

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

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

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

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

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

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

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

平滑過渡的技術：直面當前系統的問題，不斷有價值輸出，然后參考上面的過程總結，先規劃，然后中間件和數據庫，最后是服務和應用；

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

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

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

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

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

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

• 重寫老板不答應：有業務價值輸入，技改==工單或項目，借助業務項目來實現技改。

轉載于:https://www.cnblogs.com/davidwang456/articles/6548428.html

總結

以上是生活随笔為你收集整理的技改之路：从单块应用到微服务，我的血泪总结--转的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。