今天小編就為大家?guī)?lái)一篇介紹軟件架構(gòu)階段變化的特點(diǎn)以及前后架構(gòu)更替的原因和關(guān)系的文章。小編覺(jué)得挺實(shí)用的，為此分享給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧。

成都創(chuàng)新互聯(lián)服務(wù)緊隨時(shí)代發(fā)展步伐，進(jìn)行技術(shù)革新和技術(shù)進(jìn)步，經(jīng)過(guò)10多年的發(fā)展和積累，已經(jīng)匯集了一批資深網(wǎng)站策劃師、設(shè)計(jì)師、專(zhuān)業(yè)的網(wǎng)站實(shí)施團(tuán)隊(duì)以及高素質(zhì)售后服務(wù)人員，并且完全形成了一套成熟的業(yè)務(wù)流程，能夠完全依照客戶要求對(duì)網(wǎng)站進(jìn)行成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、建設(shè)、維護(hù)、更新和改版，實(shí)現(xiàn)客戶網(wǎng)站對(duì)外宣傳展示的首要目的，并為客戶企業(yè)品牌互聯(lián)網(wǎng)化提供全面的解決方案。架構(gòu)設(shè)計(jì)的演進(jìn)過(guò)程

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

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

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

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

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

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

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

緩存的加入

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

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

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

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

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

  反向代理與CDN

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

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

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

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

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

  分布式與微服務(wù)

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

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

分享標(biāo)題：軟件架構(gòu)階段變化的特點(diǎn)以及前后架構(gòu)更替的原因和關(guān)系-創(chuàng)新互聯(lián)
文章起源：http://aaarwkj.com/article22/iphcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、靜態(tài)網(wǎng)站、云服務(wù)器、移動(dòng)網(wǎng)站建設(shè)、微信公眾號(hào)、域名注冊(cè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)