導讀

本文一文總結軟件架構設計常用概念、原則與思想，包括面向對象六大原則，DID原則，ACID、CAP、BASE理論，中間層思想，緩存思想等。

軟件架構設計常用概念、原則與思想

面向對象設計六大原則

單一職責原則(SRP)

定義是就一個類而言，應該僅有一個引起他變化的原因。也就是說一個類應該只負責一件事情；

開閉原則(OCP)

定義是軟件中的對象(類，模塊，函數等)應該對于擴展是開放的，但是對于修改是關閉的；當需求發生改變的時候，我們需要對代碼進行修改，這個時候我們應該盡量去擴展原來的代碼，而不是去修改原來的代碼，因為這樣可能會引起更多的問題；

里氏替換原則(LSP)

所有引用基類的地方必須能夠透明地使用其子類的對象；子類可以去擴展父類的功能，但是不能改變父類原有的功能，它包含以下幾層意思： 1.子類可以實現父類的抽象方法，但是不能覆蓋父類的非抽象方法； 2.子類可以增加自己獨有的方法； 3.當子類的方法重載父類的方法時候，方法的形參要比父類的方法的輸入參數更加寬松； 4.當子類的方法實現父類的抽象方法時，方法的返回值要比父類更嚴格；

依賴倒置原則(DIP)

高層模塊不應該依賴底層模塊，兩個都應該依賴抽象；抽象不應該依賴細節，細節應該依賴抽象；定義有點繞，說白了，就是要針對接口編程，而不是對實現編程；(抽象指的是接口或者抽象類，兩者皆不能實例化；而細節就是實現類，也就是實現了接口或者繼承了抽象類的類，它是可以被實例化的；高層模塊指的是調用端，底層模塊是具體的實現類，在java中，依賴倒置原則是指模塊間的依賴是通過抽象來發生的，實現類之間不發生直接的依賴關系，其依賴關系是通過接口來實現的，這就是通俗的面向接口編程)

接口隔離原則(ISP)

客戶端不應該依賴他不需要的接口；

迪米特原則(LOD)

一個對象應該對其他對象保持最小的了解；

Robert C Martin在21世紀早期將單一職責，開閉原則，里氏替換，接口隔離和依賴倒置5個原則定義為SOLID原則。

DID原則

Design(D)設計20倍的容量；Implement(I)實施3倍的容量；Deploy（D）部署1.5倍的容量。 DID為產品擴展提供了經濟，有效，及時的方法。

中間層思想

計算機系統軟件體系結構采用一種層的結構，有人說過一句名言：

Any problem in computer science can be solved by another layer of indirection.
計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決。

這句話幾乎概括了計算機系統軟件體系結構的設計要點，整個體系結構從上到下都是按照嚴格的層次結構設計的，不僅是計算機系統軟件整個體系是這樣的，體系里面的每個組件比如OS本身，很多應用程序、軟件系統甚至很多硬件結構都是按照這種層次的結構組織和設計的。 縱觀計算機體系，中間層思想無處不在，比如

• MVC三層架構
• 四層/七層網絡模型
• 添加緩存層提升系統性能
• ……

緩存思想

世界是相似的，在商業的世界中，有一句經典語錄叫 “現金為王”。在互聯網乃至整個軟件技術世界中，與之對應的一個說法就是 “緩存為王”。 縱觀整個系統，緩存無處不在。

CPU緩存

由于CPU的運算速度要比內存讀寫速度快很多，CPU總有等待數據的時候，而高速緩存則解決了CPU運算速度與內存讀寫速度不匹配的矛盾。當CPU調用數據時，先從緩存中調用，從而加快讀取速度。而且，CPU是有多級緩存的。

瀏覽器緩存

前端頁面緩存有兩層含義，一個是頁面自身對某些頁面元素或全部元素進行緩存，另一層意思是服務端將靜態頁面或動態頁面的元素進行緩存，然后給客戶端使用。這里的頁面緩存指的是頁面自身的緩存或者離線應用緩存。 HTML5 支持了離線緩存和本地存儲，使用這種特性可以很方便的創建頁面應用。

網絡中的緩存

• CDN緩存
• 反向代理緩存

服務端緩存

• 內存級緩存
• 分布式緩存

數據庫緩存

拿mysql來說。mysql使用查詢緩沖機制。將select語句和結果存在緩沖區。下次遇到相同select就直接從緩沖區拿數據。

ACID(酸)

ACID，指數據庫事務正確執行的四個基本要素的縮寫。數據庫必須同時滿足ACID支持強一致性，ACID指如下內容:

A:原子性（Atomicity）

原子性是指事務是一個不可分割的工作單位，事務中的操作要么都發生，要么都不發生。

C:一致性（Consistency）

事務前后數據的完整性必須保持一致。

I:隔離性（Isolation）

事務的隔離性是多個用戶并發訪問數據庫時，數據庫為每一個用戶開啟的事務，不能被其他事務的操作數據所干擾，多個并發事務之間要相互隔離。

D:持久性（Durability）

持久性是指一個事務一旦被提交，它對數據庫中數據的改變就是永久性的，接下來即使數據庫發生故障也不應該對其有任何影響。

CAP(帽子原理)

CAP原則又稱CAP定理，指的是在一個分布式系統中，CAP三個要素最多只能同時實現兩點，不可能三者兼顧。 CAP分別是指：

C:一致性（Consistency）

所有節點在同一時間的數據完全一致，這里的一致性指的是強一致性

A:可用性（Availability）

對于一個可用性的分布式系統，每一個非故障的節點必須對每一個請求作出響應。通常我們用幾個9來描述可用性，比如5個9的可用性意思為可用水平是99.999%，即全年停機時間不超過 (1-0.99999)36524*60 = 5.256 min。

P:分區容錯性（Partition tolerance）

分區容錯性指分布式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。比如現在的分布式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉滿足系統需求。

BASE(堿)

eBay的架構師Dan Pritchett源于對大規模分布式系統的實踐總結，在ACM上發表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以采用適合的方式達到最終一致性（Eventual Consitency）。

BA:基本可用(Basically Available)

基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。 電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。

S:軟狀態(Soft state)

軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。mysql replication的異步復制也是一種體現。

E:最終一致(Eventually consistent)

最終一致性是指系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

酸堿平衡理論

ACID是傳統數據庫常用的設計理念，追求強一致性模型。BASE支持的是大型分布式系統，提出通過犧牲強一致性獲得高可用性。 ACID和BASE代表了兩種截然相反的設計哲學，基于根據ACID與BASE提出了酸堿平衡理論，即在不同場景下，分別使用ACID與BASE解決分布式一致性問題。

轉載說明

原文鏈接：《一文總結軟件架構設計常用概念、原則與思想》
原文作者：Nauyus

總結

以上是生活随笔為你收集整理的【软件架构】软件架构设计常用概念、原则与思想的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。