2018年可視化的遺留系統微服務改造.pdf

《2018年可視化的遺留系統微服務改造.pdf》由會員分享，可在線閱讀，更多相關《2018年可視化的遺留系統微服務改造.pdf（54頁珍藏版）》請在三個皮匠報告上搜索。

1、?CONTENTS01引言02可視化的認識遺留系統03可視化的劃分遺留系統04可視化的拆解遺留系統引言遺留系統、微服務架構任何人類的設計都會腐化軟件當然也不例外拆成微服務微服務架構的九大特征通過服務進行組件化圍繞業務能力組織做產品而不是做項目智能端點與傻瓜管道去中心化地治理技術去中心化地管理數據基礎設施自動化容錯設計演進式設計可視化能幫我們什么掌握系統業務明確系統邊界小步改造系統可視化的認識遺留系統C4模型、用戶畫像、用戶旅程C4模型系統架構可視化國家級省級道路級市級C4模型系統架構可視化系統上 下文圖容器圖代碼圖組件圖已可視化用戶畫像和旅程系統功能用戶可視化用戶畫像用戶旅程已可視化突出用戶信

2、息，訴求和價值體現還原業務場景可視化的劃分遺留系統領域驅動設計、事件風暴工作坊、服務畫布好的設計低耦合如果做到了服務之間的松耦合，那么修改一個服務就不需要修改另一個服務。一個松耦合的服務應該盡可能少地知道與之協作的那些服務的信息。高內聚就是把相關的行為聚集在一起，把不相關的行為放在別處。如果你要修改某個服務的行為，最好只在一處修改。領域驅動設計領域驅動設計是一種處理高度復雜域的設計思想，試圖分離技術實現的復雜性,圍繞業務概念構建領域模型來控制業務的復雜性，以解決軟件難以理解，難以演化等問題。團隊應用它可以成功地開發復雜業務軟件系統，使系統在增大時仍然保持敏捷。事件風暴工作坊-Event Sto

3、rming是一種領域建模的實踐，是一種快速探索復雜業務領域的方法：-最初由Alberto Brandolini開發，經過DDD社區和TW的很多團隊實踐驗證后，于2015年11月進入ThoughtWorks技術雷達Powerful：可以讓實踐者在數小時內理解復雜的業務模型Engaging：把帶著問題的人和擁有答案的人共聚一堂構建模型Efficient：跟DDD的實現模型高度一致，并能快速發現Aggregate和 Bounded ContextEasy：標記都很簡單，沒有復雜的UMLFun簡介正確的人：業務人員，領域專家，技術人員，架構師，測試人員等關鍵角色都要參與其中開放空間：有足夠的空間可以將

4、事件流可視化，讓人們可以交互討論彩色即時貼：至少三種顏色活動準備尋找領域事件事件風暴命令風暴尋找聚合劃分限界上下文什么是事件？為什么用事件？如何進行事件風暴？事件：領域專家關心的，在業務上真實發生的事例1:客戶訂單已提交例2:對賬已完成，每月末夜間觸發1.確定要進行事件風暴的業務場景，場景需要單一而且清晰；2.用“XXX已XXX”的格式在橙色便利貼上寫下事件，工作坊參與者需要對事件定義達成一致；3.根據時間順序把事件便利貼貼到白板上；4.如果一個事件有同步發生的其它事件，把其它事件放在事件下方；5.如果發現了業務中的問題點，用紅色便利貼記錄為什么是一個問題；6.以上步驟完成以后，再從最后一個事

5、件開始來反向驗證事件的完整性（即：走查前后事件的關聯關系，防止有些事件被遺漏）。通過事件的方式對過去發生的事情進行溯源，因為過去所發生的對業務有意義的信息都會通過某種形式保存下來。事件風暴能夠讓領域專家和工作坊參與者一起明確在業務上究竟是什么領域模型發生了什么改變，最終的軟件系統需要關注業務過程中發生的業務數據的變化。事件風暴示例訂單 已創建訂單 已支付商城庫存 已扣減倉庫庫存 已占用商品 已創建訂單 已撤銷商城庫存 已增加出庫單已 生成出庫單已 發貨投訴單 已創建投訴單已 處理商城庫存 已編輯商品 已發布商品銷售 價格已編輯訂單 已發貨補貨申請 單已創建補貨申請 單已審批入庫單 已創建入庫單

6、 已入庫訂單 已簽收訂單已 確認收貨倉庫庫存 已扣減倉庫庫存 已增加商品已 編輯退貨單已 創建退貨單已 審核訂單已 退貨入庫單 已創建入庫單 已入庫倉庫庫存 已增加尋找命令事件風暴命令風暴尋找聚合什么是命令？為什么用命令？如何進行命令風暴？命令：什么活動產生了事件 例1:提交客戶訂單例2:啟動夜間對賬事件是業務上的輸出，命令是業務上的輸入。命令以及相應角色可以明確最終軟件系統會有哪些功能給外界使用。命令和事件將會在后續的環節中指導API的設計。1.將命令寫在藍色即時貼上，可以是 用戶從UI界面進行的操作 外部系統觸發 定時任務2.將命令貼在所產生的事件旁邊；3.有的命令可能產生多個事件，將它們

7、連接；4.在這個過程中可以識別出觸發命令的外部系統（粉色即時貼）、persona（黃色即時貼）并進行表示；劃分限界上下文命令風暴示例訂單 已創建訂單 已支付商城庫存 已扣減倉庫庫存 已占用商品 已創建訂單 已撤銷商城庫存 已增加出庫單已 生成出庫單已 發貨投訴單 已創建投訴單已 處理商城庫存 已編輯商品 已發布商品銷售 價格已編輯訂單 已發貨補貨申請 單已創建補貨申請 單已審批入庫單 已創建入庫單 已入庫訂單 已簽收訂單已 確認收貨倉庫庫存 已扣減倉庫庫存 已增加商品已 編輯退貨單已 創建退貨單已 審核訂單已 退貨入庫單 已創建入庫單 已入庫倉庫庫存 已增加添加 商品支付寶 回調超過1小時 未

8、支付 編輯 商品產品運 營人員編輯庫存編輯銷售 價格發布商品 創建訂單 扣減庫存創建 出庫單占用庫存發貨扣減庫存發貨收貨撤銷訂單 增加庫存創建 退貨單審核 退貨單創建 入庫單入庫增加庫存買家系統系統系統出庫單已 配貨配貨倉庫 管理員倉庫 管理員系統系統物流系統 回調超過48小時 未確認 買家買家系統買家訂單 專員系統倉庫 管理員退貨系統系統創建 補貨單審批補 貨單創建 入庫單入庫增加庫存倉庫 管理員系統倉庫 管理員系統處理投訴單創建 投訴單客服 人員客服 人員產品運 營人員產品運 營人員產品運 營人員產品運 營人員產品運 營人員尋找聚合事件風暴命令風暴尋找聚合什么是聚合？如何尋找聚合？聚合是一

9、組相關領域模型的集合，是用來封裝業務的不變性。確保關聯關系緊密的領域模型能夠內聚在一起。1.按照事件順序依次通過提問來分析：這個事件會改變的領域模型是什么？明確領域模型（簡單理解就是事件中的涉及的業務名詞）這個領域模型是否可以獨立訪問？如果是就是聚合 如果不能獨立訪問應該需要通過哪個領域模型來訪問？當前領域模型就是與該可獨立訪問的領域模型為同一個聚合2.將命令貼在聚合的左面，是聚合的輸入；事件貼到聚合的右面，是聚合的輸出。3.再根據聚合的原則（下一頁描述）來檢驗上面的劃分結果是否匹配，如不匹配則基于劃分原則并結合業務重新調整聚合。使用聚合的目的是封裝業務的不變性，同時強迫大家盡可能的簡化領域模

10、型之間的關聯關系。在業務層面進行高內聚，低耦合的設計。為什么用聚合？劃分限界上下文聚合示例添加 商品商品 已創建商品已 編輯編輯 商品商品銷售 價格已編輯編輯銷售 商品 已發布發布商品訂單 已創建創建訂單訂單 已撤銷撤銷訂單訂單 已支付支付寶 回調商城庫存 已編輯編輯庫存商城庫存 已扣減扣減庫存商城庫存 增加庫存訂單 已發貨發貨訂單 已簽收訂單已 確認收貨收貨物流系統 倉庫庫存 已占用倉庫庫存 已扣減占用庫存扣減庫存創建 投訴單訂單已 退貨退貨處理投訴單倉庫庫存 增加庫存退貨單已 退貨單已 創建 退貨單審核 退貨單入庫單 已創建入庫單 已入庫入庫單 已入庫創建 入庫單入庫創建 入庫單補貨申請

11、單已創建補貨申請 單已審批創建 補貨單審批補 貨單出庫單已 生成創建 出庫單出庫單已 配貨出庫單已 發貨發貨出庫單倉庫訂單補貨 申請單退貨單入庫單投訴單商品支付訂單訂單劃分限界上下文事件風暴命令風暴尋找聚合劃分限界上下文什么是限界上下文？如何探索限界上下文？業務的擴展會產生越來越多的領域模型，任何大型項目都會存在很多的領域模型。當不同領域模型對應的軟件代碼被放在一起后，軟件就變得龐大且復雜，代碼難于理解、且容易出現bug，所以需要通過限界上下文來明確定義領域模型的范圍和職責。為什么使用限界上下文？限界上下文可以分為限界和上下文兩個詞來理解，限界：指一個界限，具體的某一個范圍；上下文：場景、環境

12、；所以限界上下文是在某個場景或環境下的業務邊界。該邊界就是業務上的職責。1.基于前面輸出的聚合和領域模型，判斷這些領域模型要解決的業務問題，這些問題是否為同一個問題，如果是則放到一個限界上下文中（一個問題對應一個限界上下文），如果為否則拆分到不同的限界上下文中；2.如果一個聚合（領域模型）同時解決多個問題時，則需要根據限界上下文的劃分原則（后面幾頁會詳細描述）對聚合（領域模型）進行拆分，拆分后對應的領域模型劃分到不同的限界上下文中；3.上面環節中所定義的問題大?。ㄐ杩紤]問題的變化原因、內在邏輯等）需與領域專家共同討論完成。限界上下文示例銷售子域客服子域倉儲子域商品商品上下文投訴單投訴上下文物流

13、 回調物流上下文訂單退貨單訂單上下文支付上下文支付寶 回調倉庫庫存庫存上下文出庫單入庫單出入庫上下文補貨 申請單補貨上下文物流子域每一個限界上下文都是在明確邊界微服務設計原則1.對齊限界上下文2.業務變更頻率與相關度3.系統非功能性需求4.組織結構和康威定律5.團隊規模6.技術異構和現有系統復雜度服務畫布已可視化阿 士大1.買家 2.商戶1.買家創建訂單 2.商戶履行訂單訂單商品1.訂單 2.商品 3.*明確服務的范圍明確核心模型明確服務包含的數據表可視化的拆解遺留系統微服務架構、絞殺模式、代碼依賴分析、數據庫依賴分析、遺留系統拆解評分表、降龍八步庖丁解牛拆解的最高境界了解牛的生理構造避開筋腱

14、骨節交錯的組織從骨節的縫隙下手十九年刀依然鋒利再看一眼微服務架構我們要做應用代碼拆分我們要做數據庫拆分絞殺者模式“絞殺者模式”在既有系統資產的基礎上實現數字IT創新，面對創新的數字IT業務更加靈活。通過在新的應用中實現新特性，保持和現有系統的松耦合，僅在必要時將功能從原系統中剝離，以此逐步地替換原有系統。修繕者模式“修繕者模式”在既有系統資產的基礎上，通過剝離新業務和功能，逐步“釋放”現有系統耦合度，解決遺留系統質量不穩定和Bug多的問題。實現傳統IT性能提升，面對傳統的IT業務更加穩定靈活，降低維護成本。修繕模式適用于需求變更頻率不高的存量系統2018 ThoughtWorks Inc.Co

15、nfidential-please do not distribute.步驟3-聚合 32Digitalization is the use of digital technologies to change a business model and provide new revenue and value-producing opportunities;it is the process of moving to a digital business.面對巨大復雜的遺留系統，我們該如何開始拆解？代碼依賴模式我們推薦以模塊(java包)為基本單位，從代碼依賴的角度看，有三種模式：packag

16、e A class X public void foo()Y.bar();依賴其他模塊package B class Y public void bar()package A class X public void foo()package B class Y public void bar()X.foo();被其他模塊依賴package A class X public void foo()獨立存在 Structure101代碼依賴分析可視化代碼地圖自動分析每一層級包/類之間的依賴生成可視化表格 Structure101代碼依賴分析具體依賴細節 Structure101代碼依賴分析可以將包/

17、類進行自由組合，形成容器，查看容器之間的依賴服務A服務B具體依賴細節已可視化 Structure101代碼依賴分析與Intellij或Eclipse相結合，實時查看依賴，指導拆解過程已可視化數據庫依賴模式模塊AData Mapper/ORM相關聯但不屬于 模塊A的表模塊AData Mapper/ORM屬于模塊A的表以模塊(java包)為基本單位，從數據庫依賴的角度看，有兩種模式：屬于模塊A 的表掃描數據庫依賴UserMapper.javaUserMapper.xmlJAVA定義XML實現掃描數據庫依賴服務名mapper名方法名正確依賴表名錯誤依賴表名用戶服務com.xxx.UserMapper

18、getUserByIdUSERN/A用戶服務com.xxx.UserMappergetUserProductsUserProduct數據庫依賴統計表使用工具 掃描UserMapper.xml已可視化拆解該從那個服務開始？業務 復雜度需求變化頻率使用 頻度系統集成關系數據遷移量代碼改動量拆解后 帶來的收益（業務價值）拆解中的 工作量成本（技術成本）遺留系統拆解評分表業務 復雜度需求變化頻率使用頻度系統集成關系數據遷移量代碼改動量業務維度 總體評分技術維度 總體評分改造意愿排名業務維度評分越高，表示越需要微服務化來更快、更好支撐業務需求，改造意義就越高技術維度評分越高，表示技術風險挑戰越高，同時反

19、應出微服務化接觸的空間越廣越深服務A58855821183853815161428554531613152325310104服務B服務C服務D已可視化遺留系統拆解給飛行中的飛機換引擎友誼第一 比賽第二降龍八步第一式用戶訂單商品第一式：1.明確要拆解的服務所涉及的模塊 2.驗證之前代碼依賴分析和數據庫分析的結果 3.約定“同一類型數據只有一處修改”，以數據為中心提高內聚性，同時避免寫沖突的出現遺留系統降龍八步第二式用戶訂單商品遺留系統第二式：1.在現存訂單模塊中添加新的方法，提供給用戶模塊使用，刪除用戶模塊直接使用訂單模塊的數據表 2.對用戶模塊和商品模塊做同樣的事情 3.需要在改動點添加自動化

20、測試保證功能正確 4.將數據庫的join推到代碼應用層面，勢必會比原來慢，需要關注性能問題?？紤]添加緩存，數據庫索引，甚至調整服務劃分來解決降龍八步第三式用戶訂單商品第三式：1.在訂單模塊中添加REST API，提供給用戶模塊使用，將用戶模塊對訂單模塊的代碼依賴改成REST API依賴 2.對用戶模塊和商品模塊做同樣的動作 3.確保所有依賴用戶模塊，和使用用戶模塊的依賴點都改成REST API后在進行下一步，否則會導致系統進入中間狀態遺留系統REST API降龍八步第四式用戶訂單商品第四式：1.將用戶模塊單獨部署成獨立運行的用戶服務，同時引入微服務基礎設施，如服務注冊，服務發現，API Gat

21、eway等。2.確保新的用戶服務鏈接原始數據庫用戶遺留系統微服務 基礎設施降龍八步第五式用戶訂單商品第五式：1.修改商品模塊，使用新的用戶服務，修改用戶服務使用訂單模塊 2.架空原有用戶模塊 3.出現問題隨時切換回原始用戶模塊遺留系統用戶微服務 基礎設施降龍八步第六式用戶訂單商品第六式：1.給用戶服務創建數據庫，從原始數據庫中同步用戶服務的數據遺留系統用戶微服務 基礎設施同步數據降龍八步第七式第七式：1.配置用戶服務，使用用戶服務數據庫 用戶訂單商品遺留系統用戶微服務 基礎設施降龍八步第八式訂單商品遺留系統用戶微服務 基礎設施第八式：1.新用戶服務運行一段時間后，刪除原始用戶模塊，完成拆解遺留

22、系統拆解注意事項1.遺留系統改造過程中，適當減少新需求的開發，減少改造難度2.遺留系統改造過程中，新需求開發必須按照新規則，如只通過REST API進行依賴，同一類型數據只能在某一模塊中修改，不依賴其他模塊數據庫等，減少改造工作量3.遺留系統中還會包含前端代碼和存儲過程，也需要通過代碼依賴分析和數據庫依賴分析進行拆解4.服務間依賴不一定只有REST API，可以通過異步消息、數據冗余等方式，根據實際情況進行選擇5.部署新微服務后，推薦讓新老系統并行一段時間，通過分流讓少部分流量進入新微服務，確保改造更加安全總結C4模型領域驅動設計事件風暴工作坊Structure 101微服務架構遺留系統拆分https:/ https:/ http:/www.ddd- https:/ https:/ https:/ https:/ https:/ YOU