軟件開發(fā)可以描述為一個復雜的系統(tǒng)過程，需要在各個技術領域以及相關業(yè)務方面的專業(yè)知識。就像總體規(guī)劃的藍圖一樣，通過定義軟件的體系結(jié)構(gòu)，可以促進此軟件開發(fā)過程的組成部分。

[[384028]]

為什么我們需要軟件架構(gòu)

[[384029]]

> Big Ball of Mud

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

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

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

• 分層架構(gòu)
• 多層架構(gòu)
• 面向服務的體系結(jié)構(gòu)(SOA)
• 微服務架構(gòu)

分層架構(gòu)

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

• 表示層
• 業(yè)務邏輯層
• 數(shù)據(jù)鏈路層

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

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

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

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

> Layered Representation of Architecture

好處：

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

壞處：

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

多層架構(gòu)

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

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

單層系統(tǒng)

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

這樣的系統(tǒng)僅適用于小規(guī)模的單用戶應用程序，而不應用于多用戶復雜的應用程序。

2層系統(tǒng)

> 2-Tiered Architecture

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

• 客戶擁有表示，業(yè)務邏輯和數(shù)據(jù)鏈接層。
• 服務器保存數(shù)據(jù)存儲，例如數(shù)據(jù)庫

3層/ n層系統(tǒng)

> 3-Tiered Architecture

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

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

面向服務的架構(gòu)

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

它由5個元素組成，即：

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

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

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

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

服務通常分為兩種類型：

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

服務種類：

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

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

微服務架構(gòu)

根據(jù)Martin Fowler在2014年撰寫的文章中提供的定義，描述了微服務架構(gòu)。

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

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

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

微服務包括什么

能夠獨立擴展的隔離，簡潔和細粒度微服務的體系結(jié)構(gòu)組合。

架構(gòu)由5個部分組成，如下所示：

• 服務
• 服務巴士
• 外部配置
• API網(wǎng)關
• 貨柜

微服務的特征

微服務架構(gòu)應包含以下特征：

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

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

> Comparison of different architectures

好處：

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

缺點：

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

結(jié)論

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

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

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