軟件架構(gòu)的重要性有哪些

這篇文章主要介紹“軟件架構(gòu)的重要性有哪些”，在日常操作中，相信很多人在軟件架構(gòu)的重要性有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”軟件架構(gòu)的重要性有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

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

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

> Big Ball of Mud

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

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

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

• 分層架構(gòu)

• 多層架構(gòu)

• 面向服務(wù)的體系結(jié)構(gòu)(SOA)

• 微服務(wù)架構(gòu)

分層架構(gòu)

此方法基于關(guān)注點(diǎn)分離的原理。軟件設(shè)計(jì)分為相互重疊的一層。每一層都承擔(dān)著專門的責(zé)任。架構(gòu)將軟件分為以下幾層

• 表示層

• 業(yè)務(wù)邏輯層

• 數(shù)據(jù)鏈路層

表示層擁有與外界交互的用戶界面。這也負(fù)責(zé)提供用戶體驗(yàn)，因?yàn)檫@是暴露給最終用戶交互的唯一層。

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

數(shù)據(jù)鏈接層負(fù)責(zé)與數(shù)據(jù)庫等持久性存儲(chǔ)進(jìn)行交互以及與域無關(guān)的雜項(xiàng)數(shù)據(jù)處理(即與業(yè)務(wù)無關(guān))。

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

> Layered Representation of Architecture

好處：

• 與其他方法相比，實(shí)現(xiàn)起來更簡單

• 由于各層之間的關(guān)注點(diǎn)分離而提供抽象

• 層之間的隔離使其他層免受一層的修改

• 由于耦合度低，軟件變得更易于管理

壞處：

• 沒有太大的可擴(kuò)展性

• 用這種方法構(gòu)建的軟件將傾向于具有缺乏易于修改的單體結(jié)構(gòu)

• 即使沒有必要從某些層傳遞數(shù)據(jù)，數(shù)據(jù)也必須一層一層地從另一層流出。此問題被稱為“污水池問題”

多層架構(gòu)

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

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

單層系統(tǒng)

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

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

2層系統(tǒng)

> 2-Tiered Architecture

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

• 客戶擁有表示，業(yè)務(wù)邏輯和數(shù)據(jù)鏈接層。

• 服務(wù)器保存數(shù)據(jù)存儲(chǔ)，例如數(shù)據(jù)庫

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

> 3-Tiered Architecture

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

可以將其與面向服務(wù)的高級體系結(jié)構(gòu)樣式相結(jié)合，以生成高度復(fù)雜的模型。當(dāng)軟件復(fù)雜且需要性能和擴(kuò)展性時(shí)，建議使用此體系結(jié)構(gòu)，因?yàn)檫@可能是在資源和時(shí)間上更昂貴的方法。

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

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

它由5個(gè)元素組成，即：

• 服務(wù)

• 服務(wù)巴士

• 服務(wù)庫服務(wù)目錄

• SOA安全性

• SOA治理

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

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

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

服務(wù)通常分為兩種類型：

• 原子服務(wù)：提供無法進(jìn)一步分解的功能

• 組合服務(wù)：多種大氣服務(wù)的集合，以提供復(fù)雜的組合功能

服務(wù)種類：

服務(wù)可以是以下類型，即：

• 實(shí)體服務(wù)

• 域服務(wù)

• 公用事業(yè)服務(wù)

• 綜合服務(wù)

• 申請服務(wù)

• 安保服務(wù)

微服務(wù)架構(gòu)

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

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

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

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

微服務(wù)包括什么

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

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

• 服務(wù)

• 服務(wù)巴士

• 外部配置

• API網(wǎng)關(guān)

• 貨柜

微服務(wù)的特征

微服務(wù)架構(gòu)應(yīng)包含以下特征：

• 通過服務(wù)進(jìn)行組件化

• 圍繞業(yè)務(wù)能力進(jìn)行組織

• 產(chǎn)品不是項(xiàng)目

• 智能端點(diǎn)和啞管道

• 分散治理

• 分散數(shù)據(jù)管理

• 基礎(chǔ)設(shè)施自動(dòng)化

• 失敗的設(shè)計(jì)

• 進(jìn)化設(shè)計(jì)

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

> Comparison of different architectures

好處：

• 由于高度隔離，提供低耦合

• 增強(qiáng)模塊化

• 一項(xiàng)服務(wù)中的故障不會(huì)對整個(gè)系統(tǒng)造成影響，因?yàn)樗鼈兪歉綦x的

• 提供高度的靈活性

• 提供高度的可擴(kuò)展性

• 易于修改可以加快進(jìn)化迭代的速度

• 可以實(shí)現(xiàn)更好的錯(cuò)誤處理

• 避免層層架構(gòu)和數(shù)據(jù)流僅通過有關(guān)服務(wù)的問題

缺點(diǎn)：

• 不同服務(wù)之間進(jìn)行通信時(shí)出現(xiàn)故障的可能性更高。

• 難以管理大量服務(wù)。

• 需要解決的問題，例如網(wǎng)絡(luò)延遲和負(fù)載平衡以及其他類似分布式體系結(jié)構(gòu)的問題

• 分布式環(huán)境下的復(fù)雜測試

• 實(shí)施需要更多時(shí)間

到此，關(guān)于“軟件架構(gòu)的重要性有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！