軟件開發可以描述為一個復雜的系統過程，需要在各個技術領域以及相關業務方面的專業知識。就像總體規劃的藍圖一樣，通過定義軟件的體系結構，可以促進此軟件開發過程的組成部分。

[[384028]]

為什么我們需要軟件架構

[[384029]]

> Big Ball of Mud

早期的開發人員用來設計無體系結構的軟件，這種軟件最初看起來像是沒有計劃開銷以及更快的原型制作的優點。但是，隨著他們深入到過程中，該軟件變得像泥濘的球一樣變得僵化和難以管理。隨著每項變更的成本越來越高，這種方法后來被稱為“泥漿大球”(Big Ball of Mud)

隨著時間的推移，這種項目變得難以管理，因此每次新迭代都會大大增加維護成本。這限制了軟件的發展，超出了項目開始時最初定義的范圍。

在軟件設計的多年發展過程中，開發人員提出了一些健壯的體系結構方法，以避免出現少體系結構的軟件設計問題(也稱為“泥濘大球”)。以下是一些最著名的

• 分層架構
• 多層架構
• 面向服務的體系結構(SOA)
• 微服務架構

分層架構

此方法基于關注點分離的原理。軟件設計分為相互重疊的一層。每一層都承擔著專門的責任。架構將軟件分為以下幾層

• 表示層
• 業務邏輯層
• 數據鏈路層

表示層擁有與外界交互的用戶界面。這也負責提供用戶體驗，因為這是暴露給最終用戶交互的唯一層。

顧名思義，業務邏輯層包含軟件應用程序的業務邏輯。該層將UI / UX與業務相關的計算分離開，從而提供了根據不斷變化的業務需求修改邏輯的靈活性，而不會影響其他層。

數據鏈接層負責與數據庫等持久性存儲進行交互以及與域無關的雜項數據處理(即與業務無關)。

數據和控制從設計的每一層流到另一層。這些層還增加了設計中的抽象度。由于穩定性在一定程度上與抽象成正比，因此也將軟件的穩定性提高到一定程度。

> Layered Representation of Architecture

好處：

• 與其他方法相比，實現起來更簡單
• 由于各層之間的關注點分離而提供抽象
• 層之間的隔離使其他層免受一層的修改
• 由于耦合度低，軟件變得更易于管理

壞處：

• 沒有太大的可擴展性
• 用這種方法構建的軟件將傾向于具有缺乏易于修改的單體結構
• 即使沒有必要從某些層傳遞數據，數據也必須一層一層地從另一層流出。此問題被稱為“污水池問題”

多層架構

這種架構方法根據客戶端服務器通信原理將軟件套件分為幾層。架構可以具有n層系統中的一，二層，將數據提供者和使用者之間的職責分開。

它利用請求響應模式在定義的層之間進行通信。與分層架構不同，它提供的可伸縮性可以是水平的(通過高性能節點擴展網絡)或垂直的(通過提高單個性能來擴展每個節點)

單層系統

在這種方法中，單個系統既可以充當客戶端又可以充當服務器，并且可以簡化部署，而無需進行系統間通信(ISC)。因此，提供了很好的通信速度。

這樣的系統僅適用于小規模的單用戶應用程序，而不應用于多用戶復雜的應用程序。

2層系統

> 2-Tiered Architecture

這樣的系統由兩個物理機組成，分別是服務器和客戶端。它提供了數據管理操作以及數據處理和表示操作之間的隔離。

• 客戶擁有表示，業務邏輯和數據鏈接層。
• 服務器保存數據存儲，例如數據庫

3層/ n層系統

> 3-Tiered Architecture

這樣的體系結構在水平和垂直方向上都是高度可擴展的。通常，實施n層體系結構比較昂貴，但可以提供高性能。因此，它在大型復雜軟件解決方案中是首選。

可以將其與面向服務的高級體系結構樣式相結合，以生成高度復雜的模型。當軟件復雜且需要性能和擴展性時，建議使用此體系結構，因為這可能是在資源和時間上更昂貴的方法。

面向服務的架構

SOA是基于服務的體系結構模型，其中組件和應用程序使用定義良好的服務進行通信。

它由5個元素組成，即：

• 服務
• 服務巴士
• 服務庫服務目錄
• SOA安全性
• SOA治理

客戶端通過網絡使用標準協議和數據格式發送請求。ESB處理的此請求可以被視為SOA的核心。ESB負責編排和路由。ESB使用服務存儲庫將請求定向到專用服務。該專用服務可以與其他服務或數據庫交互以組成響應有效負載(響應數據)。

完整的請求響應調用符合SOA治理和安全性規則，以完成確保安全性和正確性的事務。

> https://www.udemy.com/course/software-architecture-and-design-essentials/

服務通常分為兩種類型：

• 原子服務：提供無法進一步分解的功能
• 組合服務：多種大氣服務的集合，以提供復雜的組合功能

服務種類：

服務可以是以下類型，即：

• 實體服務
• 域服務
• 公用事業服務
• 綜合服務
• 申請服務
• 安保服務

微服務架構

根據Martin Fowler在2014年撰寫的文章中提供的定義，描述了微服務架構。

簡而言之，微服務架構風格是一種將單個應用程序開發為一組小型服務的方法，每個小型服務都在自己的進程中運行并與輕量級機制(通常是HTTP資源API)進行通信。這些服務圍繞業務功能構建，并且可以由全自動部署機制獨立部署。這些服務的集中管理幾乎沒有，它可以用不同的編程語言編寫并使用不同的數據存儲技術。

它基于服務組件化的原理。這種體系結構將軟件分解為可以定義為服務的各種組件。每項服務負有單一責任，每項服務本質上都是孤立的。一種服務的更改不應影響其他服務。

> https://divante.com/blog/monolithic-architecture-vs-microservices/

微服務包括什么

能夠獨立擴展的隔離，簡潔和細粒度微服務的體系結構組合。

架構由5個部分組成，如下所示：

• 服務
• 服務巴士
• 外部配置
• API網關
• 貨柜

微服務的特征

微服務架構應包含以下特征：

• 通過服務進行組件化
• 圍繞業務能力進行組織
• 產品不是項目
• 智能端點和啞管道
• 分散治理
• 分散數據管理
• 基礎設施自動化
• 失敗的設計
• 進化設計

建議與不同的團隊分別開發不同的微服務，并允許每個微服務隨時間同時演化，就像空氣中的各種氣泡一樣。由于數據通信是按照標準協議和數據格式進行的，因此一項服務的結構不會影響共同服務中的功能。

> Comparison of different architectures

好處：

• 由于高度隔離，提供低耦合
• 增強模塊化
• 一項服務中的故障不會對整個系統造成影響，因為它們是隔離的
• 提供高度的靈活性
• 提供高度的可擴展性
• 易于修改可以加快進化迭代的速度
• 可以實現更好的錯誤處理
• 避免層層架構和數據流僅通過有關服務的問題

缺點：

• 不同服務之間進行通信時出現故障的可能性更高。
• 難以管理大量服務。
• 需要解決的問題，例如網絡延遲和負載平衡以及其他類似分布式體系結構的問題
• 分布式環境下的復雜測試
• 實施需要更多時間

結論

每種軟件體系結構方法的設計動機都是為了解決先前體系結構中的突出問題。擁有不同方法的適當知識可以幫助您為項目設計高效的軟件架構。

“盡管不存在完善的軟件體系結構，但是，只要滿足項目的功能和非功能需求，任何體系結構方法都可以被認為是相對完美的”。

原文鏈接：https://medium.com/swlh/everything-aboutsoftware-architecture-dfd2b9351ef4