微服務的炒作高峰期似乎已經過去了。 我們不再每週閱讀幾次貼文「我如何將我的龐然大物轉移到 150 個服務」。 現在我聽到了更多常識性的想法：“我不討厭單體，我只是關心效率。” 我們甚至觀察到了幾次遷徙 。 從一個大型應用程式遷移到多個較小的服務時，您將必須解決幾個新問題。 讓我們盡可能簡短地列出它們。
背景：從基礎化學到量子力學
使用後台進程設定基本資料庫和應用程式是一個相當簡單的過程。 我在 Github 上發布自述文件 - 通常在一小時後，最多幾個小時，一切正常，然後我開始一個新專案。 新增和運行程式碼（至少對於初始環境而言）是在第一天完成的。 但如果我們冒險進入微服務，初始啟動時間就會急劇增加。 是的，現在我們有了帶有編排功能的 Docker 和 K8 機器集群，但對於新手程式設計師來說，這一切要複雜得多。 對很多後輩來說，這是一種負擔，確實是不必要的複雜化。
系統不太容易理解
讓我們暫時關註一下我們的初級學生。 對於單體應用程序，如果發生錯誤，很容易找到它並立即進行偵錯。 現在，我們有一個服務正在與另一個服務進行通信，而另一個服務正在訊息總線上排隊處理另一個服務，然後發生錯誤。 我們必須將所有這些部分放在一起，最終發現服務 A 正在運行版本 11，而服務 E 已經在等待版本 12。這與我的標準綜合日誌有很大不同：必須使用互動式終端/偵錯器來行走一步一步地完成這個過程。 調試和理解本質上變得更加困難。
如果無法調試，也許我們會測試它們
持續整合和持續開發現在變得司空見慣。 我看到的大多數新應用程式都會在每個新版本中自動建立和運行測試，並要求在註冊之前進行和審查測試。 這些都是不應被放棄的偉大流程，並且對許多公司來說是一個重大轉變。 但現在，要真正測試該服務，我必須啟動應用程式的完整工作版本。 還記得那個擁有 8 個服務的 K150 集群的新工程師嗎？ 好吧，現在我們將教導我們的 CI 系統如何啟動所有這些系統來驗證一切是否真正有效。 這可能需要花費太多精力，因此我們將單獨測試每個部分：我相信我們的規格足夠好，API 很乾淨，並且服務故障是隔離的，不會影響其他部分。
所有的妥協都有充分的理由。 正確的？
遷移到微服務的原因有很多。 我看到這樣做是為了更大的靈活性、擴展團隊、提高績效、提供更好的永續性。 但實際上，我們已經在工具和實踐上投入了數十年的時間來開發不斷發展的單體。 我與不同技術領域的專業人士一起工作。 我們通常談論擴展，因為它們遇到了單一 Postgres 資料庫節點的限制。 大多數對話都是關於 .
但我一直有興趣了解他們的架構。 他們正處於向微服務過渡的哪個階段？ 有趣的是看到更多的工程師表示他們對他們的整體應用感到滿意。 許多人將從微服務中受益，而且其好處將超過遷移路徑中的障礙。 但就我個人而言，請給我我的整體應用程序，在海灘上的一個地方 - 我非常高興。
來源： www.habr.com