軟件架構(gòu)階段變化的特點以及前后架構(gòu)更替的原因和關(guān)系

今天小編就為大家?guī)硪黄榻B軟件架構(gòu)階段變化的特點以及前后架構(gòu)更替的原因和關(guān)系的文章。小編覺得挺實用的，為此分享給大家做個參考。一起跟隨小編過來看看吧。

專注于為中小企業(yè)提供網(wǎng)站建設(shè)、網(wǎng)站設(shè)計服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)鼓樓免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

架構(gòu)設(shè)計的演進過程

業(yè)務(wù)驅(qū)動技術(shù)的發(fā)展是亙古不變的道理。最開始的時候，業(yè)務(wù)量少，業(yè)務(wù)復(fù)雜度低，采取的技術(shù)也相對簡單，基本滿足用戶對功能的需求。隨著IT信息化的普及，更多的交易放到了網(wǎng)絡(luò)上，信息量增加和訪問次數(shù)頻繁就是要解決的問題了。因此，逐漸加入了緩存、集群等技術(shù)手段。同時對業(yè)務(wù)的擴展性和伸縮性的要求也越來越高。高并發(fā)、高可用、可伸縮、可擴展、夠安全的軟件架構(gòu)一直是架構(gòu)設(shè)計追求的目標。今天我們來看一下架構(gòu)設(shè)計經(jīng)歷了哪些階段，每個階段都解決了哪些問題，又引出了哪些新問題。主要是引起大家的思考，在不同的業(yè)務(wù)發(fā)展階段采取合適技術(shù)手段，用變化擁抱變化是IT人追求的目標。

應(yīng)用與數(shù)據(jù)一體模式

最早的業(yè)務(wù)應(yīng)用以網(wǎng)站、OA等為主，訪問的人數(shù)有限，單臺服務(wù)器就能夠應(yīng)付。通常，將應(yīng)用程序和數(shù)據(jù)庫部署到一臺服務(wù)器上面，如圖1-1所示。在這一階段，我們利用LAMP（Linux Apache MySQL PHP）技術(shù)就可以迅速搞定，并且這些工具都是開源的。很長一段時間內(nèi)，有各種針對這種應(yīng)用模式的開源代碼可以使用。這種模式基本上沒有高并發(fā)的要求，可用性也很差。有的服務(wù)器采用托管模式，上面就安裝了不同的業(yè)務(wù)應(yīng)用，一旦服務(wù)器出現(xiàn)問題，所有的應(yīng)用就罷工了。不過其開發(fā)和部署成本相對較低，適合剛剛起步的應(yīng)用服務(wù)。圖1 就描述了單個應(yīng)用和數(shù)據(jù)庫運行在單臺服務(wù)器的模式，我們稱這種模式為應(yīng)用與數(shù)據(jù)一體模式。

圖 1 應(yīng)用與數(shù)據(jù)一體模式

應(yīng)用與數(shù)據(jù)分離模式

隨著業(yè)務(wù)的發(fā)展，用戶數(shù)和請求數(shù)逐漸上升，服務(wù)器的性能出現(xiàn)了問題。其中比較簡單的解決方案就是增加資源，將業(yè)務(wù)應(yīng)用和數(shù)據(jù)存儲分開，其架構(gòu)圖如圖2所示。其中，應(yīng)用服務(wù)器需要處理大量的業(yè)務(wù)請求，對CPU和內(nèi)存有一定要求；而數(shù)據(jù)庫服務(wù)器需要對數(shù)據(jù)進行存儲和索引等IO操作，對磁盤的轉(zhuǎn)速和內(nèi)存會考慮更多。這樣的分離解決了性能的問題，我們需要擴展更多的硬件資源讓其各司其職，使系統(tǒng)可以處理更多的用戶請求。雖然業(yè)務(wù)上依舊存在耦和，但硬件層面的分離在可用性上比一體式設(shè)計要好很多。

圖2 應(yīng)用與數(shù)據(jù)分離模式

緩存的加入

隨著信息化系統(tǒng)的發(fā)展和使用互聯(lián)網(wǎng)人數(shù)的增多，業(yè)務(wù)量、用戶量、數(shù)據(jù)量都在增長。我們同時發(fā)現(xiàn)，用戶會對某些數(shù)據(jù)的請求量特別大，例如新聞、商品信息和熱門消息。之前這些信息的獲取方式是依靠數(shù)據(jù)庫，因此受到數(shù)據(jù)庫IO性能的影響。此時數(shù)據(jù)庫成為了整個系統(tǒng)的瓶頸。如果再增加服務(wù)器的數(shù)量，恐怕也很難解決，于是緩存技術(shù)就登場了，其架構(gòu)圖如圖3所示。這里提到的緩存技術(shù)分為客戶端瀏覽器緩存、應(yīng)用服務(wù)器本地緩存和緩存服務(wù)器緩存。

• 客戶端瀏覽器緩存：當用戶通過瀏覽器請求服務(wù)器的時候，會發(fā)起HTTP請求。如果對每次HTTP請求進行緩存，那么可以減少應(yīng)用服務(wù)器的壓力。
• 應(yīng)用服務(wù)器本地緩存：它使用的是進程內(nèi)緩存，又叫托管堆緩存。以Java為例，這部分緩存放在JVM的托管堆上面，同時會受到托管堆回收算法的影響。由于它運行在內(nèi)存中，對數(shù)據(jù)的響應(yīng)速度很快，通常我們會把熱點數(shù)據(jù)放在這里。在進程內(nèi)緩存沒有命中的時候，會到緩存服務(wù)器中獲取信息，如果還是沒有命中，才會去數(shù)據(jù)庫中獲取。
• 緩存服務(wù)器緩存：它相對于應(yīng)用服務(wù)器本地緩存來說，就是進程外緩存，既可以和應(yīng)用服務(wù)部署在同一服務(wù)器，也可以部署到不同的服務(wù)器。一般來說，為了方便管理和合理利用資源，會將其部署到專門的緩存服務(wù)器上面。由于緩存會占用內(nèi)存空間，因此這類服務(wù)器會配置比較大的內(nèi)存。
  圖3 描述了緩存請求的次序，先訪問客戶端緩存，之后是進程內(nèi)的本地緩存，接下來是緩存服務(wù)器，最后才是數(shù)據(jù)。如果在任意一層獲取了緩存信息，就不再往下訪問了，否則會一直按照這個次序獲取緩存信息，直到數(shù)據(jù)庫。
  
  圖3 緩存的加入
  用戶請求訪問數(shù)據(jù)的順序為客戶端瀏覽器緩存→應(yīng)用服務(wù)器本地緩存→緩存服務(wù)器緩存。如果按照以上次序還沒有命中數(shù)據(jù)，才會訪問數(shù)據(jù)庫獲取數(shù)據(jù)。
  加入緩存的設(shè)計，提高了系統(tǒng)的性能。由于緩存放在內(nèi)存中，而內(nèi)存的讀取速度比磁盤要快得多，能夠很快響應(yīng)用戶請求。特別針對一些熱點數(shù)據(jù)，優(yōu)勢尤為明顯。同時，在可用性方面也有明顯的改善。即使數(shù)據(jù)庫服務(wù)器出現(xiàn)短時間的故障，緩存服務(wù)器中保存的熱點或者核心數(shù)據(jù)依舊可以滿足用戶暫時的訪問。當然，后面還會對可用性進行優(yōu)化。

  服務(wù)器集群的加入

  經(jīng)過前面三個階段的演進，系統(tǒng)對用戶的請求量有了很好的支持。實際上，這都是在解決高性能和可用性的問題，這一核心問題會一直貫穿整個系統(tǒng)架構(gòu)的演進過程中。隨著用戶請求量的增加，另外一個問題又出現(xiàn)了，那就是并發(fā)。把這兩個字拆開了來看：并，理解為“一起并行“，有同時的意思；發(fā)，理解為“發(fā)出調(diào)用”，也就是請求的意思。合起來就是多個用戶同時請求應(yīng)用服務(wù)器。如果說原來的系統(tǒng)面對的僅僅只是大數(shù)據(jù)量的話，那么現(xiàn)在就需要面對多用戶同時請求。如果還是按照上一個階段的架構(gòu)圖推導(dǎo)，單個應(yīng)用服務(wù)器已經(jīng)無法滿足高并發(fā)的要求了。此時，服務(wù)器集群就加入戰(zhàn)場了，其架構(gòu)圖如圖4所示。服務(wù)器集群也就是多臺服務(wù)器扎堆的意思，用更多的服務(wù)器來分擔單臺服務(wù)器的負載壓力，提高性能和可用性。再說白一點，就是提高單位時間內(nèi)服務(wù)處理請求的數(shù)量。原來是一個服務(wù)器處理，現(xiàn)在是一堆服務(wù)器來處理。就好像銀行柜臺一樣，增加柜員的人數(shù)來服務(wù)更多的人。
  
  圖4服務(wù)器集群的加入
  這次架構(gòu)演進與上次相比，增加了應(yīng)用服務(wù)器的個數(shù)，用多臺應(yīng)用服務(wù)器形成集群。應(yīng)用服務(wù)器中所部署的應(yīng)用服務(wù)沒有改變，在用戶請求與服務(wù)器之間加入了負載均衡器，幫助用戶請求路由到對應(yīng)的服務(wù)器中。增加服務(wù)器的舉動表明，系統(tǒng)的瓶頸是在處理用戶并發(fā)請求上。針對數(shù)據(jù)庫和緩存都沒有做更改，這樣僅僅通過增加服務(wù)器數(shù)量就能夠緩解請求的壓力。服務(wù)器集群會通過多臺服務(wù)器來分擔原來一臺服務(wù)器需要處理的請求，在多臺服務(wù)器上同時運行一套系統(tǒng)，因此可以同時處理大量并發(fā)的用戶請求。有點三個臭皮匠頂個諸葛亮的意思，因此對集群中單個服務(wù)器的硬件要求也會降低。此時需要注意負載均衡均衡的算法，例如輪詢和加權(quán)輪詢。我們要保證用戶請求能夠均勻分布到服務(wù)器上面，同一個會話的請求保證在同一個服務(wù)器上面處理，針對不同服務(wù)器資源的優(yōu)劣動態(tài)調(diào)整流量。負載均衡器加入之后，由于其位于互聯(lián)網(wǎng)與應(yīng)用服務(wù)器之間，負責(zé)用戶流量的接入，因此可以對用戶流量進行監(jiān)控，同時對訪問用戶的身份和權(quán)限進行驗證。

  數(shù)據(jù)庫讀寫分離

  加入緩存可以解決部分熱點數(shù)據(jù)的讀取，但緩存數(shù)據(jù)的容量有限，那些非熱點的數(shù)據(jù)依舊會從數(shù)據(jù)庫中讀取。數(shù)據(jù)庫對于寫入和讀取的性能是不一樣的。在寫入數(shù)據(jù)的時候，會造成鎖行或者鎖表，此時如果有其他寫入操作并發(fā)執(zhí)行，會存在排隊現(xiàn)象。而讀取操作比寫入操作更加快捷，并且可以通過索引、數(shù)據(jù)庫緩存等方式實現(xiàn)。因此，推出了數(shù)據(jù)庫讀寫分離的方案，其架構(gòu)圖如圖5所示。此時設(shè)置了主從數(shù)據(jù)庫，主庫（master）主要用來寫入數(shù)據(jù)，然后通過同步binlog的方式，將更新的數(shù)據(jù)同步到從庫（slave）中。對于應(yīng)用服務(wù)器而言，在寫數(shù)據(jù)的時候只需要訪問主庫，在讀數(shù)據(jù)的時候只用訪問從庫就好了。
  
  圖5 數(shù)據(jù)庫讀寫分離
  利用數(shù)據(jù)庫讀寫分離的方式，將數(shù)據(jù)庫的讀/寫職責(zé)分離。利用讀數(shù)據(jù)效率較高的優(yōu)勢，擴展更多的從庫，從而服務(wù)于讀取操作的用戶請求。畢竟在現(xiàn)實場景中，大多數(shù)操作都是讀取操作。此外，從數(shù)據(jù)同步技術(shù)的角度來說，又可以分為同步復(fù)制技術(shù)、異步復(fù)制技術(shù)和半同步復(fù)制技術(shù)。在數(shù)據(jù)庫讀寫分離帶來益處的同時，架構(gòu)也需要考慮可靠性的問題。例如，主庫如果掛掉，從庫如何接替主庫進行工作。主庫在恢復(fù)以后，是成為從庫還是繼續(xù)擔當主庫，以及如何同步數(shù)據(jù)的問題。

  反向代理與cdn

  隨著互聯(lián)網(wǎng)的逐漸普及，人們對網(wǎng)絡(luò)安全和用戶體驗的要求也越來越高。之前用戶都是通過客戶端直接訪問應(yīng)用服務(wù)器獲取服務(wù)，應(yīng)用服務(wù)器會暴露在互聯(lián)網(wǎng)中，容易遭到***。如果在應(yīng)用服務(wù)器與互聯(lián)網(wǎng)之間加上一個反向代理服務(wù)器，它接收用戶的請求，然后再轉(zhuǎn)發(fā)到內(nèi)網(wǎng)的應(yīng)用服務(wù)器，充當外網(wǎng)與內(nèi)網(wǎng)之間的緩沖。反向代理服務(wù)器只是做請求的轉(zhuǎn)發(fā)，在它上面沒有運行任何應(yīng)用，因此當有人***它的時候，是不會影響到內(nèi)網(wǎng)的應(yīng)用服務(wù)器的。這無形中保護了應(yīng)用服務(wù)器，提高了安全性。同時，它也在互聯(lián)網(wǎng)與內(nèi)網(wǎng)之間起到適配和網(wǎng)速轉(zhuǎn)換的作用。例如，應(yīng)用服務(wù)器需要服務(wù)公網(wǎng)和教育網(wǎng)，但是兩個網(wǎng)絡(luò)的網(wǎng)速不同，可以在應(yīng)用服務(wù)器與互聯(lián)網(wǎng)之間放上兩臺反向代理服務(wù)器，一臺連接公網(wǎng)，另一臺連接教育網(wǎng)，屏蔽網(wǎng)絡(luò)差異，服務(wù)于更多的用戶群體。如圖6 公網(wǎng)客戶端和校園網(wǎng)客戶端分別來自公網(wǎng)與校園網(wǎng)兩個不同的網(wǎng)絡(luò)，由于兩個網(wǎng)絡(luò)訪問速度不同，因此會針對兩個網(wǎng)絡(luò)分別設(shè)置共網(wǎng)代理服務(wù)器和校園網(wǎng)代理服務(wù)器，通過這種方式將位于不通網(wǎng)絡(luò)的用戶請求接入到系統(tǒng)中。
  
  圖6加入反向代理服務(wù)器
  聊完反向代理，再來說說CDN，它的全稱是Content Delivery Network，也就是內(nèi)容分發(fā)網(wǎng)絡(luò)。如果把互聯(lián)網(wǎng)想象成一張大網(wǎng)的話，每個服務(wù)器或者客戶端就是分布式在網(wǎng)中的一個節(jié)點。節(jié)點之間的距離有遠有近，用戶請求會從一個節(jié)點跳轉(zhuǎn)到另外一個節(jié)點，最終跳轉(zhuǎn)到應(yīng)用服務(wù)器獲取信息。如果跳轉(zhuǎn)的次數(shù)越少，就能夠更快地獲取信息，因此可以在離客戶端近的節(jié)點存放信息。這樣用戶通過客戶端，只需要較少的跳轉(zhuǎn)次數(shù)就能夠觸達信息。由于這部分信息更新頻率不高，推薦存放一些靜態(tài)數(shù)據(jù)，例如JavaScript文件、靜態(tài)的HTML、圖片文件等。這樣客戶端就可以從離自己最近的網(wǎng)絡(luò)節(jié)點獲取資源，大大提高了用戶體驗和傳輸效率。加入CDN后的架構(gòu)圖如圖7所示。
  
  圖7 加入CDN
  CDN的加入明顯加快了用戶訪問應(yīng)用服務(wù)器的速度，同時也減輕了應(yīng)用服務(wù)器的壓力，原來必須直接訪問應(yīng)用服務(wù)器的請求，不用經(jīng)過層層網(wǎng)絡(luò)，而只用找到最近的網(wǎng)絡(luò)節(jié)點就可以獲取資源。但從請求資源的角度上來看，這種方式也有局限性，它只能對靜態(tài)資源起作用，需要定時對CDN服務(wù)器進行資源更新。反向代理和CDN的加入解決了安全性、可用性和高性能的問題。

  分布式數(shù)據(jù)庫與分表分庫

  經(jīng)歷前面幾個階段以后，軟件的系統(tǒng)架構(gòu)相對趨于穩(wěn)定。隨著系統(tǒng)運行時間的增加，數(shù)據(jù)庫中累積的數(shù)據(jù)越來越多，同時系統(tǒng)還會記錄一些過程數(shù)據(jù)，例如操作數(shù)據(jù)和日志數(shù)據(jù)，這些數(shù)據(jù)也會加重數(shù)據(jù)庫的負擔。即便數(shù)據(jù)庫設(shè)置了索引和緩存，但在海量數(shù)據(jù)查詢的時候還會捉襟見肘。如果說讀寫分離，是將數(shù)據(jù)庫從讀寫層面進行資源分配，那么分布式數(shù)據(jù)庫就需要從業(yè)務(wù)和數(shù)據(jù)層面對資源進行分配。

• 對于數(shù)據(jù)表來說，當表中包含的記錄過多時，會將其分成多張表來存儲。例如：有1000萬個會員記錄，就可以將其分成兩個500萬，分別放到兩個表中存儲。也可以按照業(yè)務(wù)將表中的列進行分割，把表中的某些列放到其他表中存儲，然后通過外鍵關(guān)聯(lián)到主表，被分割出去的列通常是不經(jīng)常訪問的數(shù)據(jù)。
• 對于數(shù)據(jù)庫來說，每個數(shù)據(jù)庫能夠承受的最大連接數(shù)和連接池是有上限的。為了提高數(shù)據(jù)訪問效率，會根據(jù)業(yè)務(wù)需求對數(shù)據(jù)庫進行分割，讓不同的業(yè)務(wù)訪問不同的數(shù)據(jù)庫。當然，也可以將相同業(yè)務(wù)的不同數(shù)據(jù)放到不同的庫中存儲。
  如果將這些數(shù)據(jù)庫資源分別放到不同的數(shù)據(jù)庫服務(wù)器中，就是分布式數(shù)據(jù)庫設(shè)計了。由于數(shù)據(jù)存儲在不同的表/庫中，甚至在不同的服務(wù)器上面，在進行數(shù)據(jù)庫操作的時候會增加代碼的復(fù)雜度。此時可以加入數(shù)據(jù)庫中間件來消除這些差異。架構(gòu)如圖8所示，將數(shù)據(jù)拆分以后分別放在表1和表2 中，兩張表所在的數(shù)據(jù)庫服務(wù)器也各不相同，庫與庫之間還需要考慮數(shù)據(jù)同步的問題。由于數(shù)據(jù)的分散部署，要從業(yè)務(wù)應(yīng)用獲取數(shù)據(jù)就需要依靠數(shù)據(jù)庫中間件幫忙。
  
  圖8 分布式數(shù)據(jù)庫與分表分庫
  數(shù)據(jù)庫的分表分庫以及分布式設(shè)計，會帶來性能的提升，同時也增大了數(shù)據(jù)庫管理和訪問的難度。原來只用訪問一張表和一個庫，現(xiàn)在需要跨越多張表和多個庫。
  從軟件編程的角度來看，有一些數(shù)據(jù)庫中間件提供了最佳實踐，例如MyCat和Sharding JDBC。此外，從數(shù)據(jù)庫服務(wù)器管理的角度來看，需要監(jiān)控服務(wù)器的可用性。從數(shù)據(jù)治理的角度來看，需要考慮數(shù)據(jù)擴容和數(shù)據(jù)治理的問題。

  業(yè)務(wù)拆分

  當解決大數(shù)據(jù)量存儲問題以后，系統(tǒng)就能夠存儲更多的數(shù)據(jù)，這意味著能夠處理更多的業(yè)務(wù)。業(yè)務(wù)量的增加，訪問數(shù)的上升，是任何一個軟件系統(tǒng)在任何時期都要面臨的嚴峻考驗。通過前面幾個階段的學(xué)習(xí)，我們知道系統(tǒng)提升基本依靠空間換取時間，使用更多的資源和空間處理更多的用戶請求。隨著業(yè)務(wù)的復(fù)雜度越來越高，以及高并發(fā)的來臨，一些大廠開始將業(yè)務(wù)系統(tǒng)進行切分，分開部署，此時的架構(gòu)圖如圖10所示。如果說前面的服務(wù)器集群模式是將同一個應(yīng)用復(fù)制到不同的服務(wù)器上，那么業(yè)務(wù)拆分就是將一個應(yīng)用拆成多個部署到不同的服務(wù)器中。此外，還可以對核心應(yīng)用進行水平擴展，將其部署到多臺服務(wù)器上。應(yīng)用雖然做了拆分，但應(yīng)用之間仍舊有關(guān)聯(lián)，存在應(yīng)用之間的調(diào)用、通信和協(xié)調(diào)問題。由此也會引入隊列、服務(wù)注冊發(fā)現(xiàn)、消息中心等中間件，它們可以協(xié)助系統(tǒng)管理分布到不同服務(wù)器、網(wǎng)絡(luò)節(jié)點上的應(yīng)用。
  
  圖9業(yè)務(wù)拆分
  業(yè)務(wù)拆分以后會形成一個個應(yīng)用服務(wù)，既有基于業(yè)務(wù)的服務(wù)，例如商品服務(wù)、訂單服務(wù)，也有基礎(chǔ)服務(wù)，例如消息推送和權(quán)限驗證。這些應(yīng)用服務(wù)連同數(shù)據(jù)庫服務(wù)器分布在不同的容器、服務(wù)器、網(wǎng)絡(luò)節(jié)點中，對它們的通信、協(xié)調(diào)、管理和監(jiān)控都是我們需要解決的問題。

  分布式與微服務(wù)

  近幾年，微服務(wù)是比較火的架構(gòu)方式，它將業(yè)務(wù)應(yīng)用進行更加精細化的切割，使之成為更加小的業(yè)務(wù)模塊。做到模塊的高內(nèi)聚低耦合，每個模塊可以獨立存在，由獨立的團隊維護。每個模塊內(nèi)部可以采取特有的技術(shù)，而不用關(guān)心其他模塊的技術(shù)實現(xiàn)。模塊通過容器的部署運行，模塊之間通過接口和協(xié)議進行調(diào)用。任何一個模塊都可以將自己公開給其他的模塊調(diào)用。同時可以將熱點模塊進行水平擴展，增強系統(tǒng)的性能。當其中某一個模塊出現(xiàn)問題時，又可以由其他相同的模塊代替其工作，增強了可用性。
  大致總結(jié)下來，微服務(wù)擁有以下特點，業(yè)務(wù)精細化拆分、自治性、技術(shù)異構(gòu)性、高性能、高可用。它像極了分布式架構(gòu)，下面來看看它們的區(qū)別，如圖10所示。
  從概念上理解，它們都做了“拆”的動作，但在下面這幾個方面存在區(qū)別。

• 拆分目的不同：分布式設(shè)計是為了解決單體應(yīng)用資源有限的問題，在一個服務(wù)器上無法支撐更高的用戶訪問，因此將一個應(yīng)用拆解成不同的部分，然后將其部署到不同服務(wù)器上，從而分擔高并發(fā)的壓力。微服務(wù)是對服務(wù)組件進行精細化，目的是更好地解耦，讓服務(wù)之間通過組合完成高性能、高可用、可伸縮、可擴展。
• 拆分方式不同：分布式服務(wù)架構(gòu)將系統(tǒng)按照業(yè)務(wù)和技術(shù)分類進行拆分，目的是讓拆分的服務(wù)負載原來單一服務(wù)的業(yè)務(wù)。微服務(wù)則是在分布式的基礎(chǔ)上進行更細的拆分，它將服務(wù)拆成更小的模塊，更加專業(yè)化，分工更加精細，并且每個小模塊都可以獨立運行。
• 部署方式不同：分布式將服務(wù)拆分以后，通常會部署到不同的服務(wù)器上。而微服務(wù)也可以將不同的服務(wù)模塊放到不同的服務(wù)器上，同時它也可以在一個服務(wù)器上部署多個微服務(wù)，或者同一個微服務(wù)的多個備份，并且多使用容器的方式部署。
  
  圖10 分布式與微服務(wù)的區(qū)別
  雖然分布式與微服務(wù)有以上區(qū)別，但從實踐的角度來看，它們都是基于分布式架構(gòu)的思想構(gòu)建的。微服務(wù)是分布式的進化版本，也是分布式的子集。它同樣會遇到服務(wù)拆分、服務(wù)通信、協(xié)同、管理調(diào)度等問題。
• 關(guān)于軟件架構(gòu)的演變過程就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果喜歡這篇文章，不如把它分享出去讓更多的人看到。

本文題目：軟件架構(gòu)階段變化的特點以及前后架構(gòu)更替的原因和關(guān)系
標題網(wǎng)址：http://m.jiaotiyi.com/article/ijhsee.html