目錄

• 軟件架構
• 單體架構
• 分布式應用
• 微服務架構
• Serverless架構
• 總結
• Reference

軟件架構

軟件架構就是軟件的基本結構，合適的架構是軟件成功的最重要因素之一。這里列舉了目前流行的4種軟件架構。

單體架構

典型的三級架構：前端（web/手機端）+ 中間業務邏輯層 + 數據庫。

這是典型的Java Spring MVC 或者Python Django框架的應用。

單體架構應用容易部署測試，但是隨著需求不斷增加，會變得十分臃腫，可維護性、靈活性會逐漸降低。
復雜性高：一個百萬行級別的單體應用，整個項目包含的模塊非常多，模塊之間的邊界、依賴關系容易模糊。可能添加一個簡單功能都會帶來隱藏的BUG
技術債務：隨著時間推移、需求變更和人員更迭，會逐漸形成技術債務，已經使用的系統設計或代碼難以被修改，因為應用程序種的其他模塊可能會以意料之外的方式使用它
部署頻率低：每次功能的變更或者缺陷的修復都會導致重新部署整個應用。全量部署的方式耗時長、影響范圍大、風險高，這使得單體應用項目上線部署的頻率較低。部署頻率低又會導致兩次發布之間會有大量的功能變更和缺陷修復，出錯率比較高
可靠性差：某個應用BUG，如死循環、內存泄露，可能會導致整個應用崩潰
擴展能力受限：單體應用只能作為一個整體進行擴展，無法根據業務模塊的需要進行伸縮。應用中有的模塊是計算密集型，需要強勁的CPU；有的模塊是IO密集型，需要更多的IO資源以及內存。這些模塊部署在一起的話，不得不在硬件上做出妥協
阻礙技術創新：單體應用往往使用統一的技術平臺和方案，使用相同的開發語言和框架，想要引入新框架或技術平臺較難

分布式應用

中級架構，具有中間層分布式 + 數據庫分布式，是單體架構的并發擴展，將一個大的系統劃分為多個業務模塊，然后分別部署在不同的服務器上，各個業務模塊之間通過接口進行數據交互。數據庫也采用分布式數據庫，通過Nginx代理應用，將用戶請求均衡地負載到不同地服務器上。

這種架構提供了負載均衡的能力，大大提高了系統的負載能力，解決了網站高并發的需求，另外還有以下特點：
解耦：模塊炒粉，使用接口通信，降低了模塊之間的耦合度
責任清晰：拆解為若干個子項目，不同的團隊負責不同的子項目
擴展方便：增加功能時只需要增加一個子項目，調用其他系統的接口就可以
部署方便：分布式部署
提高代碼復用性：比如service層，如果不采用分布式服務方式架構，就會在pc、android、ios每個端都要寫一個service層邏輯，開發量大，難以維護一起升級，此時可以用分布式rest服務方式，共用一個service層
缺點就是系統之間的交互要使用遠程通信，接口發開增大工作量，但是利大于弊端

微服務架構

微服務架構主要是中間層分解，將系統拆分成很多小應用（微服務），微服務可以部署在不同的服務器上，也可以部署在相同的服務器的不同容器上。但應用的故障不會影響到其他應用，單應用的負載也不會影響到其他應用，代表框架Spring cloud、Dubbo。
微服務有以下特點：

易于開發和維護：一個微服務只會關注一個特定的業務功能，所以業務清晰、代碼量較少。開發和維護單個微服務比較簡單。
單個微服務啟動較快：單個微服務代碼量少，所以啟動快
局部修改容易部署：單體應用只要有修改就得重新部署整個應用，而某個微服務修改只需要重新部署整個服務即可
技術棧不受限制
使用微服務也是有代價的：
運維要求高：更多的服務意味著更多的運維投入，微服務中需要保證幾十個幾百個服務的正常運行和協作
分布式固有的復雜性：微服務構建的仍然是分布式系統，系統容錯、網絡延遲、分布式事務也比較頭疼
接口調整成本高：微服務之間通過接口進行通信，如果修改某一個微服務的API，那么所有使用該接口的微服務都需要進行調整
重復勞動：很多服務可能都會使用到相同的功能，但是這個功能并沒有達到分解為一個微服務的程度，所以各個服務都會開發這個功能，從而導致代碼重復。盡管可以使用共享庫，但是共享庫在多語言環境下不一定能用

Serverless架構

Serverless架構能夠讓開發者在構建應用的過程中無需關注計算資源的獲取和運維，由平臺來按需分配計算資源并保證應用執行的SLA（服務等級協議），按照調用次數進行計費，有效的節省應用成本。這有點像PaaS（平臺便是服務）用戶不需要關心基礎設施，只需要關心業務，全自動云上資源創建和分配。

這種架構的優點如下：
低運營成本：在業務突發性極高的場景下，系統為了應對業務高峰，必須構建出能夠應對峰值需求的系統，這種系統大部分時間是空閑的，這就導致了嚴重的資源浪費和成本上升。在微服務架構中，服務需要一直運行，在高負載情況下的每個服務都不止一個實例，這樣才能完成高可用性。Serverless架構下，服務將根據用戶的調用次數進行付費，如果沒有東西運行，就不必付費。同時用戶可以通過共享網絡、硬盤、CPU等計算資源，在業務高峰通過彈性擴容方式有效應對業務峰值，在業務波谷期間將資源分享給其他用戶，節約成本
簡化設備運維原有的IT體系中，開發團隊需要維護程序，也需要維護硬件基礎設施。在此架構中，開發人員面對的是第三方的API和URL，底層硬件對于開發人員透明化。
提高可維護性：應用程序將調用多種第三方功能服務，組成最終的應用邏輯。目前的登錄鑒權服務、云數據庫服務等第三方服務在安全性、可用性、性能上都進行了大量優化，開發團隊直接集成第三方服務，能夠有效的降低開發成本

總結

目前微服務架構在四種架構中處于主流地位，很多應用第一、第二種架構的企業也開始慢慢轉向微服務架構。第四種則是未來發展趨勢

Reference

單體→分布式→微服務，這些年的軟件架構是怎么發育的？

總結

以上是生活随笔為你收集整理的单体、分布式、微服务、Serverless软件架构一览的全部內容，希望文章能夠幫你解決所遇到的問題。

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