🥇建築風格的選擇（第二部）| 專業主機

你好，哈布爾。今天，我繼續出版專門為課程新流的開始而撰寫的一系列出版物。《軟體架構師》.

介紹

架構風格的選擇是建構資訊系統時的基本技術決策之一。在本系列文章中，我建議分析建築應用中最受歡迎的建築風格，並回答何時最優選哪種建築風格的問題。在演示過程中，我將嘗試繪製一條邏輯鏈來解釋架構風格從單體到微服務的發展。

В 上次我們研究了單體應用並得出結論，單體應用存在許多問題：大小、連接性、部署、可擴展性、可靠性和剛性。

這次我建議討論將系統組織為一組模組/函式庫（以元件為導向的體系結構）或服務（服務導向的體系結構）的可能性。

以元件為導向的體系結構涉及將系統作為一組可用於目前和未來項目的元件來執行。將系統分解為元件時，需要考慮以下因素：它們的可重複使用性、可替換性、情境獨立性、可擴展性、封裝性和獨立性。

正確使用組件，解決了「大污垢」（大尺寸+高耦合）的問題，組件本身既可以代表組裝單元（模組、庫），也可以代表部署單元（服務）。部署單元並不總是映射到正在運行的進程：例如，Web 應用程式和資料庫部署在一起。

大多數情況下，單體是作為一組模組開發的。這種方法導致了獨立開發，但獨立擴展和部署、容錯以及獨立於整個技術堆疊的問題仍然存在。這就是為什麼該模組是部分獨立的組件。

這種單體應用的最大問題是，模組的劃分純粹是邏輯性的，很容易被開發人員違反。可能會出現一個核心模組，它逐漸變成一個垃圾轉儲，模組之間的依賴關係圖可能會成長，等等。為了避免此類問題，開發要么由非常成熟的團隊進行，要么在「架構師」的指導下進行，專職進行程式碼審查，擊敗違反邏輯結構的開發人員。

「理想的」整體是一組邏輯上獨立的模組，每個模組都會查看自己的資料庫。

如果系統應該以一組服務的形式組織，那麼我們正在談論以服務為導向的體系結構。其原則是以使用者為中心的應用互通、業務服務重複使用、技術堆疊獨立性和自治性（獨立演進、可擴充、獨立部署）。

以服務為導向的架構（SOA=服務導向的架構）解決了單體應用中所有已識別的問題：發生變更時只有一項服務受到影響，並且定義良好的 API 支援良好的元件封裝。

但並非一切都那麼順利：SOA 會帶來新的問題。遠端呼叫比本地呼叫更昂貴，並且在元件之間重新分配職責也變得更加昂貴。

順便說一下，獨立部署的可能性是該服務的一個非常重要的功能。如果服務必須一起部署，或按照一定的順序部署，那麼系統就不能被認為是服務導向的。在這種情況下，他們談論的是分散式單體（不僅從 SOA 的角度來看，而且從微服務架構的角度來看，都認為是一種反模式）。

以服務為導向的架構得到了架構社群和供應商的大力支持。這意味著存在許多課程和認證以及完善的模式。後者包括例如著名的企業服務總線（ESB=企業服務總線）。同時，ESB 是供應商的包袱；它不一定必須在 SOA 中使用。

以服務為導向的架構的流行度在 2008 年左右達到頂峰，此後開始下降，在微服務出現後（~2015 年），下降趨勢更加明顯。

在我們討論了以服務和模組的形式組織資訊系統的可能性之後，我建議最後轉向微服務架構的原則，並在下一部分中特別注意微服務架構和服務導向的架構之間的差異。