從單體應用程序遷移到微服務並不容易，如果你還沒有充分認識到微服務粒度應該有多大，否則你很難避免一堆「迷你」巨石單體！（微服務很大，每個微服務是變成一個單體應用）

下面這些是幫助我們管理幾十個微服務的一些關鍵原則。我們相信它們廣泛適用，並將在可預見的未來為我們服務。

不斷重構

我們編寫軟體以滿足客戶不斷變化的需求，而不僅僅是完成項目。因此，一旦項目結束，或者讓我們每隔幾年從頭開始重新開始，我們不是收集灰塵做維護，而是通過不斷刷新它來保持其商業價值和我們的投資。這意味著更新其技術：版本和框架，以及優化和錯誤修復。通過一些服務，這很容易。一旦您為每個開發人員超過一項服務，您需要一個新計劃; 每個開發人員需要2、5或10個，您開始需要一些組織和編排。

良好的自動化測試是最低限度的：堅固的單元，集成和各種黑盒測試將使您有信心追求持續交付，並且這種信心對您的開發團隊具有積極的感染力。

更安全的部署可以加快部署速度，縮短反饋循環。反過來，這些鼓勵小型部署：每個功能區域一個而不是每個項目一個，允許更多的專業化，更少的重複，更清晰的架構，以及這些組件在您的部門中可能更高的可重用性。

一致性和慣例

連續重構是有效的，但如果沒有一致性，則可能會造成浪費。管理框架和依賴關係的多個不同版本的代價很高，並且這些差異不太可能是有充分理由的。

我們在Java 8 / Kotlin和Maven中使用Spring Boot ，我們最好的決定之一是引入我們自己的「父」POM。這讓我們集中了Spring Boot版本、內部依賴項的版本和插件配置，生成了我們可以應用於所有服務的單個版本號，以及使一致性可測量的度量。

然後，我們通過引入少量的「入門POM」來引入我們服務所涵蓋的主要技術領域，例如使用SQL資料庫，使用Redis，使用JUnit 5.我們不僅僅使用單個SpringBoot啟動器替換多個依賴項。減少了我們的POM的規模和複雜性，但它整理了它們並幫助區分真正的技術選擇和慣例。

最後，我們採用了Spring Cloud Config。這使我們能夠將數百個單獨的應用程序屬性移動到單個Git存儲庫中，以實現最大可見性。它允許我們為所有當前和未來的服務構建和策劃一組共享的默認屬性，因此典型的服務只需要少量的自定義值。這些在服務啟動時解決，無論是在桌面上運行，還是在測試中運行，還是在生產中運行。

在新系統中，一致性是一個獎勵，但很可能是緊急的，只有成熟。然而，一旦達到一定的規模，這一點至關重要，而迅速發展的技術債務就是時候解決它了。

生成和驗證

只有在易於理解和無誤應用的情況下，約定才有用。一致性很好，但識別不一致的速度有多快？即使具有良好的黑盒測試覆蓋率，快速部署以及在幾分鐘內回滾不良部署的能力，在最後時刻找到我們的問題也是浪費。我們應該儘可能早地在構建/發布周期中檢測可避免的問題。

為此，我們使用內部Maven插件。在那些定製很少的領域，我們讓它在編譯時從模板生成服務配置。例如，記錄配置和Helm圖表。由於它可以完全看到正在構建的服務的代碼和依賴關係 - 更不用說使用ASM的位元組碼?- 它允許我們在編譯時強制執行我們自己的約定，在它們可以造成任何傷害之前查找違規。這些自定義靜態分析規則可以為我們的團隊提供比IDE提供的通用規則更多的價值，這些規則對我們的基礎架構或部署要求一無所知。

無論我們多聰明，開發人員都會犯錯誤。在Crunch中幫助我們的是從編譯時到部署時間，從服務引導到啟動，最後在運行時，我們自己的代碼 - 而不是通用代碼 - 正在努力驗證我們提供的內容。

發布列車

在過去的日子裡，我們嘗試逐個項目地維護個人服務和庫版本。這些版本變得毫無意義：它們沒有描述成熟度或功能，是主觀的，很少被維護。相比之下，在2018年，版本突然變得有意義。

我們稱之為發布列車的願望和能力是保留大量服務，所有服務都涵蓋不同的功能區域，或多或少在技術上保持一致。當Spring Boot版本發生變化，新的Java版本發布，或正在試用新的創新時，我們將儘快通過選擇一個或兩個服務作為我們的「豚鼠」進行測試。我們將嘗試通過共享庫，配置更改和自動生成來提供升級，例如通過我們的Maven插件，最少的服務代碼更改，將最終結果匯總到一個新的Parent POM版本中。

在許多情況下，單個版本號更改足以讓其他服務跟隨領導者，但即使需要更改代碼，行程方向也很明確。我們已經擴展了這種方法，使庫和實用程序成為相同的統一版本控制方案。與此方法提供的清晰度和可測量性相比，可能會丟失任何微妙的差異，而個人編號則會變得蒼白。

結論

無論你忙於其他項目，都不要讓你的軟體在藤蔓上枯萎。通過正確的測試和部署基礎架構，您可以使維護變得愉快，而不是繁瑣。通過不斷行動不斷償還技術債務，經常投入時間和精力可以帶來回報

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！