DevOps在需求階段就要考慮運維的問題，運維的需求要如何反應在架構中，所以軟體架構也是DevOps需要關注的一個重要部分。

一、關於軟體架構

軟體架構是對軟體整體結構與元件的抽象描述，用於指導軟體系統的設計、開發、部署、運維和使用。關於軟體架構的定義，有2個比較官方的說法：

1、軟體架構是“系統在其環境中的最高層概念”（IEEE定義）

2、軟體架構是“一種由軟體基本元素以及外部可見的屬性和它們直接的關係構成的一種結構”（卡耐基梅隆大學軟體研究所SEI 定義）

架構的目標來源於需求，軟體架構必須要能夠反應應用的功能性需求、非功能性需求（效能、穩定性、可靠性、可維護性等），及如何部署和開發等。

二、軟體架構的模型

軟體架構從不同的關注點（視角）看，有不同的檢視，通常有5種架構模型：

1、邏輯檢視

反應功能性需求，即系統提供哪些功能或服務。

2、開發檢視

軟體需要開發哪些模組（子系統、程式庫等），及如何組織。

3、程序檢視

從效能、可用性等非功能需求的角度描述的系統。強調系統的併發、分佈、完整性和容錯性，以及把邏輯檢視中的抽象元素放到程序試圖中時，哪個控制執行緒去執行一個操作。

4、物理檢視（部署檢視）

把程序檢視的程序對映到一組基於網路的計算節點上，主要考慮非功能需求，如可用性、可靠性（容錯性）、效能（吞吐量）及橫向擴充套件性等。

5、場景檢視

利用物件場景圖和物件互動圖，描述系統中一些重要用例的場景，對最重要的一些需求進行抽象。

三、軟體架構的發展與演進

軟體架構隨著軟體系統的功能和非功能需求的變化，需要不斷的發展和演進。特別是隨著使用者數量（併發量）、資料量、流量及系統複雜性的激增，如何在有限的資源下更好的執行、維護系統，保證系統的可用性，是軟體架構面臨的挑戰。

隨著軟體應用及技術的發展，軟體架構演進經歷了單體架構、分層架構、SOA架構、分散式架構幾個階段的發展。

單體架構的應用軟體的全部功能被打包在一起，部署在同一個JVM或同一臺機器上。

分層架構也叫N層架構，根據應用的功能分為多層，通常包括展示層、業務層、持久層、資料庫層，有時候還有一個服務層，每一層都有著特定的角色和職能，每一層中的元件只會處理本層的邏輯。

SOA架構（面向服務的體系結構）是構造分散式計算的應用程式的方法，它將應用程式的功能作為服務傳送給終端使用者或者其他服務。SOA架構中一般會涉及企業訊息匯流排（ESB）和服務編排（Service Orchestration）。SOA架構是在企業需要把許多系統集中到一起工作的實踐中演化而來的，每個系統都是高內聚的，對外以暴露介面的方式提供服務。SOA架構強調系統服務化和系統之間用良好定義的介面進行互動。

在流量爆炸的網際網路時代，無論從開發角度、效能角度，還是維護角度，單體架構都無法滿足網際網路軟體系統的進一步擴充套件，需要真正的分散式架構。分散式系統是建立在網路之上的軟體系統，系統具有高度的內聚性和透明性。核心理念是讓多臺伺服器協同工作，完成高併發或大資料量計算等單臺伺服器無法處理的任務。

四、微服務架構

微服務架構是分散式架構的一種，微服務架構能更好的支援網際網路業務對十二正規化的應用，特別適合對可用性、效能、擴充套件性、伸縮性要求比較高的應用場景。

微服務架構把單體應用垂直拆分成多個小的模組，每個模組都是一個完整的、自包含的服務，每個服務可以被獨立的開發、部署，對外提供API，並且可以獨立被呼叫，可以獨立演化。

微服務的核心模式包括API閘道器、配置中心、服務註冊與發現、熔斷器、分散式追蹤等。

五、微服務與強一致性的統一

微服務架構在帶來諸多優勢的同時，也帶來很多調整。如當系統被拆分為多個服務的時候，強一致性保障的事物是一個挑戰。如果使用分散式事務，那麼就不得不犧牲系統的可擴充套件性，並放棄更高的高效能。通常的原則是：功能上比較內聚的，尤其是擁有強一致性事務的功能，會放在同一個微服務裡。但如果要求高併發（如12306網站），把所有強一致性事務的功能放在一個微服務裡，反而是一個災難。此時，採用一些緩解措施，可以適當的犧牲這種強一致性，轉而變成一種最終一致性。CQRS架構便是一種最終一致性架構。

實施微服務架構，需要有良好的DevOps和底層基礎架構來支撐。