本文來自開源云中文社區(qū)。
當涉及到將單體應(yīng)用程序重構(gòu)為微服務(wù)時，大多數(shù)工程團隊不知道從哪里開始。此外，最近的一項調(diào)查顯示，79%的現(xiàn)代化項目失敗，平均花費150萬美元和16個月的時間。
在盲目進行現(xiàn)代化項目之前，必須了解技術(shù)債務(wù)積累、創(chuàng)新和所有權(quán)成本、復雜性和風險等因素。
事件風暴練習、領(lǐng)域驅(qū)動設(shè)計（DDD）、Strangler Fig Pattern和其他都是要遵循的有用概念，但作為架構(gòu)師或開發(fā)人員，如何將單體應(yīng)用程序重構(gòu)為微服務(wù)？
完成這項工作的最佳實踐有很多種，在這篇文章中，我們將探討一些具體的行動，以智能地將單體分解為微服務(wù)。
這些操作包括識別服務(wù)域、將兩個服務(wù)合并為一個服務(wù)、將服務(wù)更精確地重命名以及刪除作為微服務(wù)提取候選的服務(wù)或類。最好的部分是：我們將使用人工智能（AI）和自動化來實現(xiàn)目標，而不是試圖手動完成這些工作。
最佳實踐1：自動識別服務(wù)和域
調(diào)查表明，使用白板上的便簽手動分析一個單體的時間太長，成本太高，很少成功。團隊中的哪一位架構(gòu)師或開發(fā)人員有時間和能力手工審閱數(shù)百萬行代碼和數(shù)萬個類？大型單體應(yīng)用程序需要一種自動化、數(shù)據(jù)驅(qū)動的方法來識別潛在的服務(wù)邊界。
讓我們選擇一個現(xiàn)成的、真實的應(yīng)用程序作為平臺，在其中探索這些最佳實踐。作為Java開發(fā)人員的教程示例，Oracle提供了一個醫(yī)療記錄（MedRec）應(yīng)用程序——也稱為Avitek醫(yī)療記錄應(yīng)用程序，它是一個使用WebLogic和Java EE的傳統(tǒng)單體。
使用vFunction，我們將啟動一個“學習”階段，使用基于調(diào)用樹和系統(tǒng)流的動態(tài)分析、靜態(tài)分析和機器學習來識別理想的服務(wù)域。
圖1：此服務(wù)圖顯示了為提取而標識的單個服務(wù)
在圖1中，我們看到一個服務(wù)圖，其中服務(wù)顯示為不同大小和顏色的球體，以及連接它們的線（邊）。每個球體表示vFunction自動識別為與特定域相關(guān)的服務(wù)。這些服務(wù)的名稱和詳細信息顯示在屏幕右側(cè)。
球體的大小表示服務(wù)中包含的類的數(shù)量。顏色表示每個服務(wù)中的類“排他性”級別，指的是僅存在于該服務(wù)中的類別的百分比，而不是跨多個服務(wù)共享的類別。
紅色代表低排他性，藍色代表中排他性和綠色代表高排他性。較高的類排他性表明服務(wù)之間的邊界更好，相互依賴性更少，代碼重復更少。綜上所述，這些特征表明，將高度獨占的服務(wù)重構(gòu)為微服務(wù)將不那么復雜。
圖2和圖3：實線和虛線表示服務(wù)之間的不同關(guān)系
這里的實線表示跨服務(wù)共享的公共資源（圖2）。常見資源包括bean、同步對象、只讀DB事務(wù)和表、讀寫DB事務(wù)和表、WebSocket、文件和嵌入式文件等。虛線表示服務(wù)之間的方法調(diào)用（圖3）。
中間的黑色球體表示仍處于單體中的類，其中包含不特定于任何特定域的類和資源，因此未被選為提取的候選對象。
通過使用自動化和人工智能來分析和公開以前包含在單體黑匣子中的新服務(wù)邊界，你現(xiàn)在可以開始在建議的參考架構(gòu)中操作服務(wù)，該架構(gòu)為基于數(shù)據(jù)驅(qū)動分析做出更好的決策掃清了道路。
最佳實踐2：整合功能并避免重復
當一切都在單體中時，能見度有限。如果能夠公開建議的服務(wù)邊界，你可以開始做出決策并測試設(shè)計概念，例如，識別多個服務(wù)中的重疊功能。
什么時候?qū)⒕哂蓄愃乒δ艿牟煌?wù)整合到單個微服務(wù)中才有意義？最基本的例子是，作為一名架構(gòu)師，你可能會看到將兩個看起來重疊的服務(wù)組合在一起的機會，我們可以根據(jù)類名和類排他性級別來識別這些服務(wù)。
圖4：兩個類似的服務(wù)已被確定要合并
在服務(wù)圖（圖4）中，我們看到了兩個類似的聊天服務(wù)，它們用白色圓圈勾勒出來：PatientChatWebSocket和PhysicanChatWebSocket。我們可以看到，Physican聊天服務(wù)（紅色）具有0%的動態(tài)排他性，而Patient聊天服務(wù)（藍色）具有略高的排他性（33%）。
這兩個服務(wù)都沒有使用任何共享資源，這表明我們可以將這些資源合并到一個服務(wù)中，而不會因為我們的操作而糾纏任何東西。
圖5：確認合并服務(wù)的決定可以通過按下按鈕立即回滾
通過合并兩個類似的服務(wù)，你可以合并重復的功能，并在新合并的服務(wù)中增加類的排他性（圖5）。由于我們在本例中使用vFunction平臺，邏輯綁定這些服務(wù)所需的一切都得到了處理——類、入口點和資源都得到了智能更新。
圖6：新合并的單個服務(wù)現(xiàn)在表示兩個以前的聊天服務(wù)
合并服務(wù)就像將一個服務(wù)拖放到另一個服務(wù)上一樣簡單，在vFunction平臺重新計算對該操作的分析后，我們看到球體現(xiàn)在是綠色的，動態(tài)排他性為75%（圖6）。這表明新合并的服務(wù)在類級別上互連較少，并使我們有機會以較低的復雜性提取此服務(wù)。
最佳實踐3：為服務(wù)創(chuàng)建準確和有意義的名稱
我們都知道給事物命名很難。在處理單體服務(wù)時，我們實際上只能使用類名來了解發(fā)生了什么。僅憑這些信息，很難準確識別哪些類和功能可能屬于特定的域。
在示例中，vFunction從圖7中屏幕右側(cè)的類名中自動導出服務(wù)域名。作為架構(gòu)師，你需要能夠根據(jù)偏好和需求重命名服務(wù)。
圖7：將合并的服務(wù)更精確地重命名
現(xiàn)在讓我們回到上一節(jié)中合并的兩個聊天服務(wù)。雖然以前我們有一個用于患者和醫(yī)生聊天的服務(wù)，但現(xiàn)在我們有了一個代表這兩個配置文件的單一服務(wù)，因此PatientChatWebSocket的名稱不再準確，可能會導致將來使用此服務(wù)的其他開發(fā)人員產(chǎn)生誤解。我們可以選擇一個更好的名稱，例如ChatService（圖7）。
圖8：將自動識別的服務(wù)重命名為更有意義的服務(wù)
在圖8中，我們可以看到另一個名為JaxRSRecordFacadeBroker（+2）的服務(wù)。這里的（+2）部分表示我們有屬于多個類的入口點。你可能會發(fā)現(xiàn)此名稱具有不必要的描述性，因此可以簡單地將其更改為RecordBroker。
通過以更準確和更有意義的方式重命名服務(wù)，可以確保工程團隊能夠以直接的方式快速識別和處理未來的微服務(wù)。
最佳實踐4：確定不應(yīng)作為單獨微服務(wù)的功能
什么品質(zhì)表明，以前包含在一個整體中的功能應(yīng)該成為一個微服務(wù)？并不是所有的東西都應(yīng)該成為一個微服務(wù)，所以什么時候你想刪除一個作為分離和提取候選的服務(wù)？
你可能會決定某些服務(wù)實際上不屬于單獨的域，例如，一個只過濾消息的過濾器類。因為這不是任何特定服務(wù)所獨有的，所以你可以決定將來將其移動到公共庫或其他服務(wù)。
當刪除作為未來提取為微服務(wù)的候選功能時，您決定不將此類視為接收流量的單獨入口點。讓我們看看AuthenticationAdministrationController服務(wù)（圖9），它是一個簡單的控制器類。
圖9：刪除一個非常簡單的非特定服務(wù)
在圖9中，我們可以看到所選類的紅色排他性很低，而且它是一個非常小的服務(wù)，只包含一個動態(tài)類、一個靜態(tài)類，沒有資源。你可以決定它本身不應(yīng)該是一個單獨的服務(wù)，并通過將其拖放到中間的黑色球體上來刪除它（圖10）。
通過將這個類重新定位到單體，我們已經(jīng)確定這個特定的功能不滿足成為單個微服務(wù)的要求。
在本文中，我們展示了架構(gòu)師和開發(fā)人員可以遵循的一些最佳實踐，以便將單體應(yīng)用程序重構(gòu)為有界的上下文和精確的域，用于未來的微服務(wù)提取。
通過使用vFunction平臺，使用人工智能和數(shù)據(jù)驅(qū)動分析，許多繁重的起始和手動工作已經(jīng)自動化。這確保了架構(gòu)師和開發(fā)團隊可以將時間集中在基于智能建議的參考架構(gòu)上，而不是在沒有適當?shù)?ldquo;全局”上下文的情況下花費數(shù)千小時手動分析小塊代碼。
原文鏈接：
https://thenewstack.io/monoliths-to-microservices-4-modernization-best-practices-2/
