這個問題,其實也是很多人的疑問!
我想說:四種軟件架構演進史,程序員會一種就很牛了!
如果一個軟件開發人員,不了解軟件架構的演進,會制約技術的選型和開發人員的生存、晉升空間。這里我列舉了目前主要的四種軟件架構以及他們的優缺點,希望能夠幫助軟件開發人員拓展知識面。
一、單體架構單體架構比較初級,典型的三級架構,前端(Web/手機端)+中間業務邏輯層+數據庫層。這是一種典型的Java Spring mvc或者Python Django框架的應用。其架構圖如下所示:
單體架構
單體架構的應用比較容易部署、測試, 在項目的初期,單體應用可以很好地運行。然而,隨著需求的不斷增加, 越來越多的人加入開發團隊,代碼庫也在飛速地膨脹。慢慢地,單體應用變得越來越臃腫,可維護性、靈活性逐漸降低,維護成本越來越高。下面是單體架構應用的一些缺點:
復雜性高:以一個百萬行級別的單體應用為例,整個項目包含的模塊非常多、模塊的邊界模糊、 依賴關系不清晰、 代碼質量參差不齊、 混亂地堆砌在一起。可想而知整個項目非常復雜。每次修改代碼都心驚膽戰, 甚至添加一個簡單的功能, 或者修改一個Bug都會帶來隱含的缺陷。技術債務:隨著時間推移、需求變更和人員更迭,會逐漸形成應用程序的技術債務, 并且越積 越多。“ 不壞不修”, 這在軟件開發中非常常見, 在單體應用中這種思想更甚。已使用的系統設計或代碼難以被修改,因為應用程序中的其他模塊可能會以意料之外的方式使用它。部署頻率低:隨著代碼的增多,構建和部署的時間也會增加。而在單體應用中, 每次功能的變更或缺陷的修復都會導致需要重新部署整個應用。全量部署的方式耗時長、 影響范圍大、 風險高, 這使得單體應用項目上線部署的頻率較低。而部署頻率低又導致兩次發布之間會有大量的功能變更和缺陷修復,出錯率比較高。可靠性差:某個應用Bug,例如死循環、內存溢出等, 可能會導致整個應用的崩潰。擴展能力受限:單體應用只能作為一個整體進行擴展,無法根據業務模塊的需要進行伸縮。例如,應用中有的模塊是計算密集型的,它需要強勁的CPU;有的模塊則是IO密集型的,需要更大的內存。由于這些模塊部署在一起,不得不在硬件的選擇上做出妥協。阻礙技術創新:單體應用往往使用統一的技術平臺或方案解決所有的問題, 團隊中的每個成員 都必須使用相同的開發語言和框架,要想引入新框架或新技術平臺會非常困難。二、分布式應用大型互聯網架構演進過程架構師應具備的分布式知識主流分布式架構設計詳解中級架構,分布式應用,中間層分布式+數據庫分布式,是單體架構的并發擴展,將一個大的系統劃分為多個業務模塊,業務模塊分別部署在不同的服務器上,各個業務模塊之間通過接口進行數據交互。數據庫也大量采用分布式數據庫,如redis、ES、solor等。通過LVS/Nginx代理應用,將用戶請求均衡的負載到不同的服務器上。其架構圖如下所示:
分布式架構
該架構相對于單體架構來說,這種架構提供了負載均衡的能力,大大提高了系統負載能力,解決了網站高并發的需求。另外還有以下特點:
降低了耦合度:把模塊拆分,使用接口通信,降低模塊之間的耦合度。責任清晰:把項目拆分成若干個子項目,不同的團隊負責不同的子項目。擴展方便:增加功能時只需要再增加一個子項目,調用其他系統的接口就可以。部署方便:可以靈活的進行分布式部署。提高代碼的復用性:比如service層,如果不采用分布式rest服務方式架構就會在手機wap商城,微信商城,pc,android,ios每個端都要寫一個service層邏輯,開發量大,難以維護一起升級,這時候就可以采用分布式rest服務方式,公用一個service層。缺點 : 系統之間的交互要使用遠程通信,接口開發增大工作量,但是利大于弊。
三、微服務架構服務的前世今生基于分布式思想下的RPC解決方案Dubbo應用及源碼解讀SpringBootSpringCloud應用及源碼解讀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架構,沒有全部展示出來,那如果有感興趣了解的老友們呢...可以去我的主頁,私信我【架構】獲取,喜歡我的分布式、微服務系統圖的也能分享給大家~我對架構體系做了一系列的系統圖,很開心能分享給大家!我的很多文章都有分享各種架構資料,相信對于已經工作和遇到技術瓶頸或者寫博客碼友,在我的主頁一定都有你需要的內容。