四種軟件架構演進史,程序員會一種就很牛了!

如果一個軟件開發人員,不瞭解軟件架構的演進,會制約技術的選型和開發人員的生存、晉升空間。這裏我列舉了目前主要的四種軟件架構以及他們的優缺點,希望能夠幫助軟件開發人員拓展知識面。

一、單體架構

單體架構比較初級,典型的三級架構,前端(Web/手機端)+中間業務邏輯層+數據庫層。這是一種典型的Java Spring mvc或者Python Django框架的應用。其架構圖如下所示:

 

單體架構

單體架構的應用比較容易部署、測試, 在項目的初期,單體應用可以很好地運行。然而,隨着需求的不斷增加, 越來越多的人加入開發團隊,代碼庫也在飛速地膨脹。慢慢地,單體應用變得越來越臃腫,可維護性、靈活性逐漸降低,維護成本越來越高。

下面是單體架構應用的一些缺點:

  • 複雜性高:以一個百萬行級別的單體應用爲例,整個項目包含的模塊非常多、模塊的邊界模糊、 依賴關係不清晰、 代碼質量參差不齊、 混亂地堆砌在一起。可想而知整個項目非常複雜。每次修改代碼都心驚膽戰, 甚至添加一個簡單的功能, 或者修改一個Bug都會帶來隱含的缺陷。

  • 技術債務:隨着時間推移、需求變更和人員更迭,會逐漸形成應用程序的技術債務, 並且越積 越多。“ 不壞不修”, 這在軟件開發中非常常見, 在單體應用中這種思想更甚。已使用的系統設計或代碼難以被修改,因爲應用程序中的其他模塊可能會以意料之外的方式使用它。

  • 部署頻率低:隨着代碼的增多,構建和部署的時間也會增加。而在單體應用中, 每次功能的變更或缺陷的修復都會導致需要重新部署整個應用。全量部署的方式耗時長、 影響範圍大、 風險高, 這使得單體應用項目上線部署的頻率較低。而部署頻率低又導致兩次發佈之間會有大量的功能變更和缺陷修復,出錯率比較高。

  • 可靠性差:某個應用Bug,例如死循環、內存溢出等, 可能會導致整個應用的崩潰。

  • 擴展能力受限:單體應用只能作爲一個整體進行擴展,無法根據業務模塊的需要進行伸縮。例如,應用中有的模塊是計算密集型的,它需要強勁的CPU;有的模塊則是IO密集型的,需要更大的內存。由於這些模塊部署在一起,不得不在硬件的選擇上做出妥協。

  • 阻礙技術創新:單體應用往往使用統一的技術平臺或方案解決所有的問題, 團隊中的每個成員 都必須使用相同的開發語言和框架,要想引入新框架或新技術平臺會非常困難。

二、分佈式應用

  1. 大型互聯網架構演進過程

  2. 架構師應具備的分佈式知識

  3. 主流分佈式架構設計詳解

文末有架構圖集領取

中級架構,分佈式應用,中間層分佈式+數據庫分佈式,是單體架構的併發擴展,將一個大的系統劃分爲多個業務模塊,業務模塊分別部署在不同的服務器上,各個業務模塊之間通過接口進行數據交互。數據庫也大量採用分佈式數據庫,如redis、ES、solor等。通過LVS/Nginx代理應用,將用戶請求均衡的負載到不同的服務器上。其架構圖如下所示:

 

分佈式架構

該架構相對於單體架構來說,這種架構提供了負載均衡的能力,大大提高了系統負載能力,解決了網站高併發的需求。另外還有以下特點:

  1. 降低了耦合度:把模塊拆分,使用接口通信,降低模塊之間的耦合度。

  2. 責任清晰:把項目拆分成若干個子項目,不同的團隊負責不同的子項目。

  3. 擴展方便:增加功能時只需要再增加一個子項目,調用其他系統的接口就可以。

  4. 部署方便:可以靈活的進行分佈式部署。

  5. 提高代碼的複用性:比如service層,如果不採用分佈式rest服務方式架構就會在手機wap商城,微信商城,pc,android,ios每個端都要寫一個service層邏輯,開發量大,難以維護一起升級,這時候就可以採用分佈式rest服務方式,公用一個service層。

缺點 : 系統之間的交互要使用遠程通信,接口開發增大工作量,但是利大於弊。

三、微服務架構

  1. 服務的前世今生

  2. 基於分佈式思想下的RPC解決方案

  3. Dubbo應用及源碼解讀

  4. SpringBoot

  5. SpringCloud應用及源碼解讀

  6. Docker虛擬化技術

文末領取清晰圖片

微服務架構,主要是中間層分解,將系統拆分成很多小應用(微服務),微服務可以部署在不同的服務器上,也可以部署在相同的服務器不同的容器上。當應用的故障不會影響到其他應用,單應用的負載也不會影響到其他應用,其代表框架有Spring cloud、Dubbo等。其架構圖如下所示:

  • 易於開發和維護:一個微服務只會關注一個特定的業務功能,所以它業務清晰、代碼量較少。開發和維護單個微服務相對簡單。而整個應用是由若干個微服務構建而成的,所以整個應用也會被維持在一個可控狀態。

  • 單個微服務啓動較快:單個微服務代碼量較少, 所以啓動會比較快。

  • 局部修改容易部署:單體應用只要有修改,就得重新部署整個應用,微服務解決了這樣的問題。一般來說,對某個微服務進行修改,只需要重新部署這個服務即可。

  • 技術棧不受限:在微服務架構中,可以結合項目業務及團隊的特點,合理地選擇技術棧。例如某些服務可使用關係型數據庫MySQL;某些微服務有圖形計算的需求,可以使用Neo4j;甚至可根據需要,部分微服務使用Java開發,部分微服務使用Node.js開發。

  • 微服務雖然有很多吸引人的地方,但它並不是免費的午餐,使用它是有代價的。使用微服務架構面臨的挑戰。

  • 運維要求較高:更多的服務意味着更多的運維投入。在單體架構中,只需要保證一個應用的正常運行。而在微服務中,需要保證幾十甚至幾百個服務服務的正常運行與協作,這給運維帶來了很大的挑戰。

  • 分佈式固有的複雜性:使用微服務構建的是分佈式系統。對於一個分佈式系統,系統容錯、網絡延遲、分佈式事務等都會帶來巨大的挑戰。

  • 接口調整成本高:微服務之間通過接口進行通信。如果修改某一個微服務的API,可能所有使用了該接口的微服務都需要做調整。

  • 重複勞動:很多服務可能都會使用到相同的功能,而這個功能並沒有達到分解爲一個微服務的程度,這個時候,可能各個服務都會開發這一功能,從而導致代碼重複。儘管可以使用共享庫來解決這個問題(例如可以將這個功能封裝成公共組件,需要該功能的微服務引用該組件),但共享庫在多語言環境下就不一定行得通了。

四、Serverless架構

當我們還在容器的浪潮中前行時,已經有一些革命先驅悄然佈局另外一個雲計算戰場:Serverless架構。

 Serverless架構

2014年11月14日,亞馬遜AWS發佈了新產品Lambda。當時Lambda被描述爲:一種計算服務,根據時間運行用戶的代碼,無需關心底層的計算資源。從某種意義上來說,Lambda姍姍來遲,它像雲計算的PaaS理念:客戶只管業務,無需擔心存儲和計算資源。

 在此前不久,2014年10月22日,谷歌收購了實時後端數據庫創業公司Firebase。Firebase聲稱開發者只需引用一個API庫文件就可以使用標準REST API的各種接口對數據進行讀寫操作,只需編寫HTML+CSS+JavaScrip前端代碼,不需要服務器端代碼(如需整合,也極其簡單)。

相對於上兩者,Facebook 在2014年二月收購的 Parse,則側重於提供一個通用的後臺服務。這些服務被稱爲Serverless或no sever。想到PaaS(平臺即服務)了是嗎?很像,用戶不需要關心基礎設施,只需要關心業務,這是遲到的PaaS,也是更實用的PaaS。這很有可能將會變革整個開發過程和傳統的應用生命週期,一旦開發者們習慣了這種全自動的雲上資源的創建和分配,或許就再也回不到那些需要微應用配置資源的時代裏去了。

對於Serverless架構,我沒有全部展示出來,那如果有感興趣瞭解的老友們呢...可以加入我私人羣一起討論學習!

點擊鏈接加入羣聊【架構華山論劍:836442475】:https://jq.qq.com/?_wv=1027&k=5MIzBWe

喜歡我的分佈式、微服務系統圖的也能分享給大家哦~我對架構體系做了一系列的系統圖,很開心能分享給大家,可以啦!


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章