展開(kāi)
湖北國聯(lián)計算機科技有限公司
  • 首頁(yè)HOME
  • 公司簡(jiǎn)介INTRODUCTION
  • 安全防御DEFENSE
  • 軟件開(kāi)發(fā)SOFTWARE
  • 物聯(lián)網(wǎng)IOT
  • 運行維護SRE
  • 成功案例CASE
  • 聯(lián)系我們CONTACT
  • Software Technology Sharing |技術(shù)分享

    四種軟件架構演進(jìn)史
    來(lái)源:湖北國菱計算機科技有限公司-湖北國聯(lián)計算機科技有限公司-荊州網(wǎng)站建設-荊州軟件開(kāi)發(fā)-政府網(wǎng)站建設公司 時(shí)間:2021-04-14

    如果一個(gè)軟件開(kāi)發(fā)人員,不了解軟件架構的演進(jìn),會(huì )制約技術(shù)的選型和開(kāi)發(fā)人員的生存、晉升空間。這里我列舉了目前主要的四種軟件架構以及他們的優(yōu)缺點(diǎn),希望能夠幫助軟件開(kāi)發(fā)人員拓展知識面。

    一、單體架構

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


    單體架構的應用比較容易部署、測試, 在項目的初期,單體應用可以很好地運行。然而,隨著(zhù)需求的不斷增加, 越來(lái)越多的人加入開(kāi)發(fā)團隊,代碼庫也在飛速地膨脹。慢慢地,單體應用變得越來(lái)越臃腫,可維護性、靈活性逐漸降低,維護成本越來(lái)越高。下面是單體架構應用的一些缺點(diǎn):

    復雜性高:以一個(gè)百萬(wàn)行級別的單體應用為例,整個(gè)項目包含的模塊非常多、模塊的邊界模糊、 依賴(lài)關(guān)系不清晰、 代碼質(zhì)量參差不齊、 混亂地堆砌在一起??上攵麄€(gè)項目非常復雜。每次修改代碼都心驚膽戰, 甚至添加一個(gè)簡(jiǎn)單的功能, 或者修改一個(gè)Bug都會(huì )帶來(lái)隱含的缺陷。

    技術(shù)債務(wù):隨著(zhù)時(shí)間推移、需求變更和人員更迭,會(huì )逐漸形成應用程序的技術(shù)債務(wù), 并且越積 越多?!?不壞不修”, 這在軟件開(kāi)發(fā)中非常常見(jiàn), 在單體應用中這種思想更甚。已使用的系統設計或代碼難以被修改,因為應用程序中的其他模塊可能會(huì )以意料之外的方式使用它。

    部署頻率低:隨著(zhù)代碼的增多,構建和部署的時(shí)間也會(huì )增加。而在單體應用中, 每次功能的變更或缺陷的修復都會(huì )導致需要重新部署整個(gè)應用。全量部署的方式耗時(shí)長(cháng)、 影響范圍大、 風(fēng)險高, 這使得單體應用項目上線(xiàn)部署的頻率較低。而部署頻率低又導致兩次發(fā)布之間會(huì )有大量的功能變更和缺陷修復,出錯率比較高。

    可靠性差:某個(gè)應用Bug,例如死循環(huán)、內存溢出等, 可能會(huì )導致整個(gè)應用的崩潰。

    擴展能力受限:?jiǎn)误w應用只能作為一個(gè)整體進(jìn)行擴展,無(wú)法根據業(yè)務(wù)模塊的需要進(jìn)行伸縮。例如,應用中有的模塊是計算密集型的,它需要強勁的CPU;有的模塊則是IO密集型的,需要更大的內存。由于這些模塊部署在一起,不得不在硬件的選擇上做出妥協(xié)。

    阻礙技術(shù)創(chuàng )新:單體應用往往使用統一的技術(shù)平臺或方案解決所有的問(wèn)題, 團隊中的每個(gè)成員 都必須使用相同的開(kāi)發(fā)語(yǔ)言和框架,要想引入新框架或新技術(shù)平臺會(huì )非常困難。

    二、分布式應用

    中級架構,分布式應用,中間層分布式+數據庫分布式,是單體架構的并發(fā)擴展,將一個(gè)大的系統劃分為多個(gè)業(yè)務(wù)模塊,業(yè)務(wù)模塊分別部署在不同的服務(wù)器上,各個(gè)業(yè)務(wù)模塊之間通過(guò)接口進(jìn)行數據交互。數據庫也大量采用分布式數據庫,如redis、ES、solor等。通過(guò)LVS/Nginx代理應用,將用戶(hù)請求均衡的負載到不同的服務(wù)器上。其架構圖如下所示:


    該架構相對于單體架構來(lái)說(shuō),這種架構提供了負載均衡的能力,大大提高了系統負載能力,解決了網(wǎng)站高并發(fā)的需求。另外還有以下特點(diǎn):

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

    責任清晰:把項目拆分成若干個(gè)子項目,不同的團隊負責不同的子項目。

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

    部署方便:可以靈活的進(jìn)行分布式部署。

    提高代碼的復用性:比如service層,如果不采用分布式rest服務(wù)方式架構就會(huì )在手機wap商城,微信商城,pc,android,ios每個(gè)端都要寫(xiě)一個(gè)service層邏輯,開(kāi)發(fā)量大,難以維護一起升級,這時(shí)候就可以采用分布式rest服務(wù)方式,公用一個(gè)service層。

    缺點(diǎn) : 系統之間的交互要使用遠程通信,接口開(kāi)發(fā)增大工作量,但是利大于弊。

    三、微服務(wù)架構

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


    易于開(kāi)發(fā)和維護:一個(gè)微服務(wù)只會(huì )關(guān)注一個(gè)特定的業(yè)務(wù)功能,所以它業(yè)務(wù)清晰、代碼量較少。開(kāi)發(fā)和維護單個(gè)微服務(wù)相對簡(jiǎn)單。而整個(gè)應用是由若干個(gè)微服務(wù)構建而成的,所以整個(gè)應用也會(huì )被維持在一個(gè)可控狀態(tài)。

    單個(gè)微服務(wù)啟動(dòng)較快:單個(gè)微服務(wù)代碼量較少, 所以啟動(dòng)會(huì )比較快。

    局部修改容易部署:單體應用只要有修改,就得重新部署整個(gè)應用,微服務(wù)解決了這樣的問(wèn)題。一般來(lái)說(shuō),對某個(gè)微服務(wù)進(jìn)行修改,只需要重新部署這個(gè)服務(wù)即可。

    技術(shù)棧不受限:在微服務(wù)架構中,可以結合項目業(yè)務(wù)及團隊的特點(diǎn),合理地選擇技術(shù)棧。例如某些服務(wù)可使用關(guān)系型數據庫MySQL;某些微服務(wù)有圖形計算的需求,可以使用Neo4j;甚至可根據需要,部分微服務(wù)使用Java開(kāi)發(fā),部分微服務(wù)使用Node.js開(kāi)發(fā)。

    微服務(wù)雖然有很多吸引人的地方,但它并不是免費的午餐,使用它是有代價(jià)的。使用微服務(wù)架構面臨的挑戰。

    運維要求較高:更多的服務(wù)意味著(zhù)更多的運維投入。在單體架構中,只需要保證一個(gè)應用的正常運行。而在微服務(wù)中,需要保證幾十甚至幾百個(gè)服務(wù)服務(wù)的正常運行與協(xié)作,這給運維帶來(lái)了很大的挑戰。

    分布式固有的復雜性:使用微服務(wù)構建的是分布式系統。對于一個(gè)分布式系統,系統容錯、網(wǎng)絡(luò )延遲、分布式事務(wù)等都會(huì )帶來(lái)巨大的挑戰。

    接口調整成本高:微服務(wù)之間通過(guò)接口進(jìn)行通信。如果修改某一個(gè)微服務(wù)的API,可能所有使用了該接口的微服務(wù)都需要做調整。

    重復勞動(dòng):很多服務(wù)可能都會(huì )使用到相同的功能,而這個(gè)功能并沒(méi)有達到分解為一個(gè)微服務(wù)的程度,這個(gè)時(shí)候,可能各個(gè)服務(wù)都會(huì )開(kāi)發(fā)這一功能,從而導致代碼重復。盡管可以使用共享庫來(lái)解決這個(gè)問(wèn)題(例如可以將這個(gè)功能封裝成公共組件,需要該功能的微服務(wù)引用該組件),但共享庫在多語(yǔ)言環(huán)境下就不一定行得通了。

    四、Serverless架構

    當我們還在容器的浪潮中前行時(shí),已經(jīng)有一些革命先驅悄然布局另外一個(gè)云計算戰場(chǎng):Serverless架構。


    2014年11月14日,亞馬遜AWS發(fā)布了新產(chǎn)品Lambda。當時(shí)Lambda被描述為:一種計算服務(wù),根據時(shí)間運行用戶(hù)的代碼,無(wú)需關(guān)心底層的計算資源。從某種意義上來(lái)說(shuō),Lambda姍姍來(lái)遲,它像云計算的PaaS理念:客戶(hù)只管業(yè)務(wù),無(wú)需擔心存儲和計算資源。在此前不久,2014年10月22日,谷歌收購了實(shí)時(shí)后端數據庫創(chuàng )業(yè)公司Firebase。Firebase聲稱(chēng)開(kāi)發(fā)者只需引用一個(gè)API庫文件就可以使用標準REST API的各種接口對數據進(jìn)行讀寫(xiě)操作,只需編寫(xiě)HTML+CSS+JavaScrip前端代碼,不需要服務(wù)器端代碼(如需整合,也極其簡(jiǎn)單)。

    相對于上兩者,Facebook 在2014年二月收購的 Parse,則側重于提供一個(gè)通用的后臺服務(wù)。這些服務(wù)被稱(chēng)為Serverless或no sever。想到PaaS(平臺即服務(wù))了是嗎?很像,用戶(hù)不需要關(guān)心基礎設施,只需要關(guān)心業(yè)務(wù),這是遲到的PaaS,也是更實(shí)用的PaaS。這很有可能將會(huì )變革整個(gè)開(kāi)發(fā)過(guò)程和傳統的應用生命周期,一旦開(kāi)發(fā)者們習慣了這種全自動(dòng)的云上資源的創(chuàng )建和分配,或許就再也回不到那些需要微應用配置資源的時(shí)代里去了。

    Serverless架構能夠讓開(kāi)發(fā)者在構建應用的過(guò)程中無(wú)需關(guān)注計算資源的獲取和運維,由平臺來(lái)按需分配計算資源并保證應用執行的SLA(服務(wù)等級協(xié)議),按照調用次數進(jìn)行計費,有效的節省應用成本。ServerLess的架構如上圖所示。其優(yōu)點(diǎn)如下所示:

    低運營(yíng)成本:在業(yè)務(wù)突發(fā)性極高的場(chǎng)景下,系統為了應對業(yè)務(wù)高峰,必須構建能夠應對峰值需求的系統,這個(gè)系統在大部分時(shí)間是空閑的,這就導致了嚴重的資源浪費和成本上升。在微服務(wù)架構中,服務(wù)需要一直運行,實(shí)際上在高負載情況下每個(gè)服務(wù)都不止一個(gè)實(shí)例,這樣才能完成高可用性;在Serverless架構下,服務(wù)將根據用戶(hù)的調用次數進(jìn)行計費,按照云計算pay-as-you-go原則,如果沒(méi)有東西運行,你就不必付款,節省了使用成本。同時(shí),用戶(hù)能夠通過(guò)共享網(wǎng)絡(luò )、硬盤(pán)、CPU等計算資源,在業(yè)務(wù)高峰期通過(guò)彈性擴容方式有效的應對業(yè)務(wù)峰值,在業(yè)務(wù)波谷期將資源分享給其他用戶(hù),有效的節約了成本。

    簡(jiǎn)化設備運維:在原有的IT體系中,開(kāi)發(fā)團隊即需要維護應用程序,同時(shí)還要維護硬件基礎設施;Serverless架構中,開(kāi)發(fā)人員面對的將是第三方開(kāi)發(fā)或自定義的API 和URL,底層硬件對于開(kāi)發(fā)人員透明化了,技術(shù)團隊無(wú)需再關(guān)注運維工作,能夠更加專(zhuān)注于應用系統開(kāi)發(fā)。

    提升可維護性:Serverless架構中,應用程序將調用多種第三方功能服務(wù),組成最終的應用邏輯。目前,例如登陸鑒權服務(wù),云數據庫服務(wù)等第三方服務(wù)在安全性、可用性、性能方面都進(jìn)行了大量?jì)?yōu)化,開(kāi)發(fā)團隊直接集成第三方的服務(wù),能夠有效的降低開(kāi)發(fā)成本,同時(shí)使得應用的運維過(guò)程變得更加清晰,有效的提升了應用的可維護性。

    更快的開(kāi)發(fā)速度:這一點(diǎn)在現在互聯(lián)網(wǎng)創(chuàng )業(yè)公司得到很好的體現,創(chuàng )業(yè)公司往往開(kāi)始由于人員和資金等問(wèn)題,不可能每個(gè)產(chǎn)品線(xiàn)都同時(shí)進(jìn)行,這時(shí)候就可以考慮第三方的Baas平臺,比如使用微信的用戶(hù)認證、阿里云提供的RDS,極光的消息推送,第三方支付及地理位置等等,能夠很快進(jìn)行產(chǎn)品開(kāi)發(fā)的速度,把工作重點(diǎn)放在業(yè)務(wù)實(shí)現上,把產(chǎn)品更快的推向市場(chǎng)。

    但ServerLess架構也有其缺點(diǎn):

    廠(chǎng)商平臺綁定:平臺會(huì )提供Serverless架構給大玩家,比如AWS Lambda,運行它需要使用AWS指定的服務(wù),比如API網(wǎng)關(guān),DynamoDB,S3等等,一旦你在這些服務(wù)上開(kāi)發(fā)一個(gè)復雜系統,你會(huì )粘牢AWS,以后只好任由他們漲價(jià)定價(jià)或者下架等操作,個(gè)性化需求很難滿(mǎn)足,不能進(jìn)行隨意的遷移或者遷移的成本比較大,同時(shí)不可避免帶來(lái)一些損失。Baas行業(yè)內一個(gè)比較典型的事件,2016年1月19日Facebook關(guān)閉曾經(jīng)花巨額資金收購的Parse,造成用戶(hù)不得不遷移在這個(gè)平臺中產(chǎn)生一年多的數據,無(wú)疑需要花費比較大的人力和時(shí)間成本。

    成功案例比較少,沒(méi)有行業(yè)標準:目前的情況也只適合簡(jiǎn)單的應用開(kāi)發(fā),缺乏大型成功案例的推動(dòng)。對于Serverless缺乏統一的認知以及相應的標準,無(wú)法適應所有的云平臺。

    目前微服務(wù)架構在四種架構中處于主流地位,很多應用第一、第二種架構的企業(yè)也開(kāi)始慢慢轉向微服務(wù)架構。到目前為止微服務(wù)的技術(shù)相對于二三年前已經(jīng)比較成熟,第四種架構將是未來(lái)發(fā)展的一種趨勢。







    荊州地區政府網(wǎng)站建設 解決方案 專(zhuān)業(yè)團隊 騰訊第三方平臺 地址:湖北省荊州市沙市區荊沙大道楚天都市佳園一期C區29棟112       地址:湖北省松滋市新江口街道才知文化廣場(chǎng)1幢1146-1151室     郵編:434200 聯(lián)系電話(huà):0716-6666211     網(wǎng)站編輯部郵箱:business@gl-ns.com 鄂公網(wǎng)安備 42100202000212號 備案號:鄂ICP備2021015094號-1     企業(yè)名稱(chēng):湖北國菱計算機科技有限公司