web服務(wù)器分布式系統(tǒng)有什么特點

本篇內(nèi)容介紹了“web服務(wù)器分布式系統(tǒng)有什么特點”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

分布式系統(tǒng)基礎(chǔ)知識

一個tomcat打天下的時代，不能說完全淘汰了，在一個管理系統(tǒng)，小型項目中還經(jīng)常使用，這并不過分，出于成本的考慮，這反而值得提倡。但如果要延伸到高并發(fā)場景下就必然要了解分布式系統(tǒng)：

分布式系統(tǒng)特點

分布式系統(tǒng)：一個硬件或軟件組件分布在不同的網(wǎng)絡(luò)計算機上，彼此之間僅僅通過消息傳遞進行通信和協(xié)調(diào)的系統(tǒng)
這是分布式系統(tǒng)，在不同的硬件，不同的軟件，不同的網(wǎng)絡(luò)，不同的計算機上，僅僅通過消息來進行通訊與協(xié)調(diào)
這是他的特點，更細致的看這些特點又可以有：分布性、對等性、并發(fā)性、缺乏全局時鐘、故障隨時會發(fā)生。

1. 分布性

既然是分布式系統(tǒng)，最顯著的特點肯定就是分布性，從簡單來看，如果我們做的是個電商項目，整個項目會分成不同的功能，專業(yè)點就不同的微服務(wù)，比如用戶微服務(wù)，產(chǎn)品微服務(wù)，訂單微服務(wù)，這些服務(wù)部署在不同的tomcat中，不同的服務(wù)器中，甚至不同的集群中，整個架構(gòu)都是分布在不同的地方的，在空間上是隨意的，而且隨時會增加，刪除服務(wù)器節(jié)點，這是第一個特性。

2. 對等性

對等性是分布式設(shè)計的一個目標，還是以電商網(wǎng)站為例，來說明下什么是對等性，要完成一個分布式的系統(tǒng)架構(gòu)，肯定不是簡單的把一個大的單一系統(tǒng)拆分成一個個微服務(wù)，然后部署在不同的服務(wù)器集群就夠了，其中拆分完成的每一個微服務(wù)都有可能發(fā)現(xiàn)問題，而導(dǎo)致整個電商網(wǎng)站出現(xiàn)功能的丟失。
比如訂單服務(wù)，為了防止訂單服務(wù)出現(xiàn)問題，一般情況需要有一個備份，在訂單服務(wù)出現(xiàn)問題的時候能頂替原來的訂單服務(wù)。這就要求這兩個（或者2個以上）訂單服務(wù)完全是對等的，功能完全是一致的，其實這就是一種服務(wù)副本的冗余。
還一種是數(shù)據(jù)副本的冗余，比如數(shù)據(jù)庫，緩存等，再比如大數(shù)據(jù)HDFS中的三個副本，都和上面說的訂單服務(wù)一樣，為了安全考慮需要有完全一樣的備份存在，這就是對等性的意思。

3. 并發(fā)性

并發(fā)性其實對我們來說并不模式，在學(xué)習(xí)多線程的時候已經(jīng)或多或少學(xué)習(xí)過，多線程是并發(fā)的基礎(chǔ)。但是以前都是在一個JVM上實現(xiàn)的并發(fā)，但現(xiàn)在我們要接觸的不是多線程的角度，而是更高一層，從多進程，多JVM的角度，例如在一個分布式系統(tǒng)中的多個節(jié)點，可能會并發(fā)地操作一些共享資源，如何準確并高效的協(xié)調(diào)分布式并發(fā)操作。分布式鎖就是干這個事的。

4. 缺乏全局時鐘

在分布式系統(tǒng)中，節(jié)點是可能反正任意位置的，而每個位置，每個節(jié)點都有自己的時間系統(tǒng)，因此在分布式系統(tǒng)中，很難定義兩個事務(wù)糾結(jié)誰先誰后，原因就是因為缺乏一個全局的時鐘序列進行控制，當然，現(xiàn)在這已經(jīng)不是什么大問題了，已經(jīng)有大把的時間服務(wù)器給系統(tǒng)調(diào)用

5. 故障隨時會發(fā)生

任何一個節(jié)點都可能出現(xiàn)停電，死機等現(xiàn)象，服務(wù)器集群越多，出現(xiàn)故障的可能性就越大，隨著集群數(shù)目的增加，出現(xiàn)故障甚至都會成為一種常態(tài)，怎么樣保證在系統(tǒng)出現(xiàn)故障，而系統(tǒng)還是正常的訪問者是作為系統(tǒng)搭建者應(yīng)該考慮的。

大型網(wǎng)站架構(gòu)圖

知道什么是分布式系統(tǒng)，接下來具體來看下大型網(wǎng)站架構(gòu)圖，首先整個架構(gòu)分成很多個層，應(yīng)用層，服務(wù)層，基礎(chǔ)設(shè)施層與數(shù)據(jù)服務(wù)層，每一層都由若干節(jié)點組成，這是典型的分布式架構(gòu)，后面一大把的時間就是系統(tǒng)的學(xué)習(xí)里面的每一個部分。

那么zookeeper在其中又是扮演什么角色呢，如果可以把zk扮演成交警的角色，而各個節(jié)點就是馬路上的各種汽車（汽車，公交車），為了保證整個交通（系統(tǒng)）的可用性，zookeeper必須知道每一節(jié)點的健康狀態(tài)（公交車是否出了問題，要派新的公交【服務(wù)注冊與發(fā)現(xiàn)】），公路在上下班高峰是否擁堵，在某一條很窄的路上只允許單獨一個方向的汽車通過【分布式鎖】。
如果交通警察是交通系統(tǒng)的指揮官，而zookeeper就是各個節(jié)點組成分布式系統(tǒng)的指揮官。

分布式系統(tǒng)問題

如果把分布式系統(tǒng)和平時的交通系統(tǒng)進行對比，哪怕再穩(wěn)健的交通系統(tǒng)也會有交通事故，分布式系統(tǒng)也有很多需要攻克的問題，比如：通訊異常、網(wǎng)絡(luò)分區(qū)、三態(tài)、節(jié)點故障等。

1. 通信異常

通訊異常其實就是網(wǎng)絡(luò)異常，網(wǎng)絡(luò)系統(tǒng)本身是不可靠的，由于分布式系統(tǒng)需要通過網(wǎng)絡(luò)進行數(shù)據(jù)傳輸，網(wǎng)絡(luò)光纖，路由器等硬件難免出現(xiàn)問題。只要網(wǎng)絡(luò)出現(xiàn)問題，也就會影響消息的發(fā)送與接受過程，因此數(shù)據(jù)消息的丟失或者延長就會變得非常普遍。

2. 網(wǎng)絡(luò)分區(qū)

網(wǎng)絡(luò)分區(qū)，其實就是腦裂現(xiàn)象(參考Hadoop NameNode)，舉例來說：本來有一個交通警察，來管理整個片區(qū)的交通情況，一切井然有序，突然出現(xiàn)了停電，或者出現(xiàn)地震等自然災(zāi)難，某些道路接受不到交通警察的指令，可能在這種情況下，會出現(xiàn)一個零時工，片警來指揮交通。但注意，原來的交通警察其實還在，只是通訊系統(tǒng)中斷了，這時候就會出現(xiàn)問題了，在同一個片區(qū)的道路上有不同人在指揮，這樣必然引擎交通的阻塞混亂。這種由于種種問題導(dǎo)致同一個區(qū)域（分布式集群）有兩個相互沖突的負責人的時候就會出現(xiàn)這種精神分裂的情況，在這里稱為腦裂，也叫網(wǎng)絡(luò)分區(qū)。

3. 三態(tài)

三態(tài)是什么？三態(tài)其實就是成功，與失敗以外的第三種狀態(tài)，當然，肯定不叫變態(tài)，而叫超時態(tài)。
在一個jvm中，應(yīng)用程序調(diào)用一個方法函數(shù)后會得到一個明確的相應(yīng)，要么成功，要么失敗，而在分布式系統(tǒng)中，雖然絕大多數(shù)情況下能夠接受到成功或者失敗的相應(yīng)，但一旦網(wǎng)絡(luò)出現(xiàn)異常，就非常有可能出現(xiàn)超時，當出現(xiàn)這樣的超時現(xiàn)象，網(wǎng)絡(luò)通訊的發(fā)起方，是無法確定請求是否成功處理的。

4. 節(jié)點故障

這個其實前面已經(jīng)說過了，節(jié)點故障在分布式系統(tǒng)下是比較常見的問題，指的是組成服務(wù)器集群的節(jié)點會出現(xiàn)的宕機或僵死的現(xiàn)象，這種現(xiàn)象經(jīng)常會發(fā)生。

CAP 理論

前面說了分布式的特點以及會碰到很多會讓人頭疼的問題，這些問題肯定會有一定的理論思想來解決問題的。接下來花點時間來談?wù)勥@些理論，其中CAP和BASE理論是基礎(chǔ)，也是面試的時候經(jīng)常會問到的
首先看下CAP，CAP其實就是一致性，可用性，分區(qū)容錯性這三個詞的縮寫

一致性

一致性是事務(wù)ACID的一個特性【原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）】。

這里講的一致性其實大同小異，只是現(xiàn)在考慮的是分布式環(huán)境中，還是不單一的數(shù)據(jù)庫。

在分布式系統(tǒng)中，一致性是數(shù)據(jù)在多個副本之間是否能夠保證一致的特性，這里說的一致性和前面說的對等性其實差不多。如果能夠在分布式系統(tǒng)中針對某一個數(shù)據(jù)項的變更成功執(zhí)行后，所有用戶都可以馬上讀取到最新的值，那么這樣的系統(tǒng)就被認為具有強一致性。

可用性

可用性指系統(tǒng)提供服務(wù)必須一直處于可用狀態(tài)，對于用戶的操作請求總是能夠在有限的時間內(nèi)訪問結(jié)果。這里的重點是有限的時間和返回結(jié)果。為了做到有限的時間需要用到緩存，需要用到負載，這個時候服務(wù)器增加的節(jié)點是為性能考慮；

為了返回結(jié)果，需要考慮服務(wù)器主備，當主節(jié)點出現(xiàn)問題的時候需要備份的節(jié)點能最快的頂替上來，千萬不能出現(xiàn)OutOfMemory或者其他500，404錯誤，否則這樣的系統(tǒng)我們會認為是不可用的。

分區(qū)容錯性

分布式系統(tǒng)在遇到任何網(wǎng)絡(luò)分區(qū)故障的時候，仍然需要能夠?qū)ν馓峁M足一致性和可用性的服務(wù)，除非是整個網(wǎng)絡(luò)環(huán)境都發(fā)生了故障。不能出現(xiàn)腦裂的情況。

PS:

一個分布式系統(tǒng)不可能同時滿足一致性、可用性和分區(qū)容錯性這三個基本需求，最多只能同時滿足其中的兩項。設(shè)計者的精力往往就花在怎么樣根據(jù)業(yè)務(wù)場景在A和C直接尋求平衡；

BASE理論

根據(jù)前面的CAP理論，設(shè)計者應(yīng)該從一致性·和可用性之間找平衡，系統(tǒng)短時間完全不可用肯定是不允許的，那么根據(jù)CAP理論，在分布式環(huán)境下必然也無法做到強一致性。

BASE理論：

即使無法做到強一致性，但分布式系統(tǒng)可以根據(jù)自己的業(yè)務(wù)特點，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終的一致性；

Basically Avaliable 基本可用

當分布式系統(tǒng)出現(xiàn)不可預(yù)見的故障時，允許損失部分可用性，保障系統(tǒng)的基本可用；體現(xiàn)在時間上的損失和功能上的損失；

e.g：部分用戶雙十一高峰期淘寶頁面卡頓或降級處理；

Soft state 軟狀態(tài)

其實就是前面講到的三態(tài),既允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，既系統(tǒng)的不同節(jié)點的數(shù)據(jù)副本之間的數(shù)據(jù)同步過程存在延時，并認為這種延時不會影響系統(tǒng)可用性；

e.g：12306網(wǎng)站賣火車票，請求會進入排隊隊列；

Eventually consistent 最終一致性

所有的數(shù)據(jù)在經(jīng)過一段時間的數(shù)據(jù)同步后，最終能夠達到一個一致的狀態(tài)；

e.g：理財產(chǎn)品首頁充值總金額短時不一致；

常見名詞

服務(wù)雪崩

假設(shè)存在如下調(diào)用鏈

而此時，Service A的流量波動很大，流量經(jīng)常會突然性增加！那么在這種情況下，就算Service A能扛得住請求，Service B和Service C未必能扛得住這突發(fā)的請求。
此時，如果Service C因為抗不住請求，變得不可用。那么Service B的請求也會阻塞，慢慢耗盡Service B的線程資源，Service B就會變得不可用。緊接著，Service A也會不可用，這一過程如下圖所示

如上圖所示，一個服務(wù)失敗，導(dǎo)致整條鏈路的服務(wù)都失敗的情形，我們稱之為服務(wù)雪崩。

那么，服務(wù)熔斷和服務(wù)降級就可以視為解決服務(wù)雪崩的手段之一。

服務(wù)熔斷

服務(wù)熔斷：當下游的服務(wù)因為某種原因突然變得不可用或響應(yīng)過慢，上游服務(wù)為了保證自己整體服務(wù)的可用性，不再繼續(xù)調(diào)用目標服務(wù)，直接返回，快速釋放資源。如果目標服務(wù)情況好轉(zhuǎn)則恢復(fù)調(diào)用。
需要說明的是熔斷其實是一個框架級的處理，那么這套熔斷機制的設(shè)計，基本上業(yè)內(nèi)用的是斷路器模式，如Martin Fowler提供的狀態(tài)轉(zhuǎn)換圖如下所示

1. 最開始處于closed狀態(tài)，一旦檢測到錯誤到達一定閾值，便轉(zhuǎn)為open狀態(tài)。

2. 這時候會有個 reset timeout，到了這個時間了，會轉(zhuǎn)移到half open狀態(tài)。

3. 嘗試放行一部分請求到后端，一旦檢測成功便回歸到closed狀態(tài)，即恢復(fù)服務(wù)。

業(yè)內(nèi)目前流行的熔斷器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix，在Hystrix中，對應(yīng)配置如下

//滑動窗口的大小，默認為20
circuitBreaker.requestVolumeThreshold 
//過多長時間，熔斷器再次檢測是否開啟，默認為5000，即5s鐘
circuitBreaker.sleepWindowInMilliseconds 
//錯誤率，默認50%
circuitBreaker.errorThresholdPercentage

每當20個請求中，有50%失敗時，熔斷器就會打開，此時再調(diào)用此服務(wù)，將會直接返回失敗，不再調(diào)遠程服務(wù)。直到5s之后，重新檢測該觸發(fā)條件，判斷是否把熔斷器關(guān)閉，或者繼續(xù)打開。

這些屬于框架層級的實現(xiàn)，我們只要實現(xiàn)對應(yīng)接口就好！

服務(wù)降級

什么是服務(wù)降級呢？這里有兩種場景:

1. 當下游的服務(wù)因為某種原因響應(yīng)過慢，下游服務(wù)主動停掉一些不太重要的業(yè)務(wù)，釋放出服務(wù)器資源，增加響應(yīng)速度！

2. 當下游的服務(wù)因為某種原因不可用，上游主動調(diào)用本地的一些降級邏輯，避免卡頓，迅速返回給用戶！

其實乍看之下，很多人還是不懂熔斷和降級的區(qū)別，其實應(yīng)該要這么理解:

1. 服務(wù)降級有很多種降級方式！如開關(guān)降級、限流降級、熔斷降級!

2. 服務(wù)熔斷屬于降級方式的一種！

可能有的人不服，覺得熔斷是熔斷、降級是降級，分明是兩回事??！其實不然，因為從實現(xiàn)上來說，熔斷和降級必定是一起出現(xiàn)。因為當發(fā)生下游服務(wù)不可用的情況，這個時候為了對最終用戶負責，就需要進入上游的降級邏輯了。因此，將熔斷降級視為降級方式的一種，也是可以說的通的！

撇開框架，以最簡單的代碼來說明！上游代碼如下

try{
   
   
   //調(diào)用下游的helloWorld服務(wù)xxRpc.helloWorld();}catch(Exception e){
   
   
   //因為熔斷，所以調(diào)不通doSomething();}

注意看，下游的helloWorld服務(wù)因為熔斷而調(diào)不通。此時上游服務(wù)就會進入catch里頭的代碼塊，那么catch里頭執(zhí)行的邏輯，你就可以理解為降級邏輯！
什么，你跟我說你不捕捉異常，直接丟頁面？OK，那我甘拜下風(fēng)，當我理解錯誤!

服務(wù)降級大多是屬于一種業(yè)務(wù)級別的處理。當然，我這里要講的是另一種降級方式，也就是開關(guān)降級 這也是我們生產(chǎn)上常用的另一種降級方式！

做法很簡單，做個開關(guān)，然后將開關(guān)放配置中心！在配置中心更改開關(guān)，決定哪些服務(wù)進行降級。至于配置變動后，應(yīng)用怎么監(jiān)控到配置發(fā)生了變動，這就不是本文該討論的范圍。
那么，在應(yīng)用程序中部下開關(guān)的這個過程，業(yè)內(nèi)也有一個名詞，稱為埋點！

那接下來最關(guān)鍵的一個問題，哪些業(yè)務(wù)需要埋點？
一般有以下方法

1. 簡化執(zhí)行流程
   自己梳理出核心業(yè)務(wù)流程和非核心業(yè)務(wù)流程。然后在非核心業(yè)務(wù)流程上加上開關(guān)，一旦發(fā)現(xiàn)系統(tǒng)扛不住，關(guān)掉開關(guān)，結(jié)束這些次要流程。

2. 關(guān)閉次要功能
   一個微服務(wù)下肯定有很多功能，那自己區(qū)分出主要功能和次要功能。然后次要功能加上開關(guān)，需要降級的時候，把次要功能關(guān)了吧！

3. 降低一致性
   假設(shè)，你在業(yè)務(wù)上發(fā)現(xiàn)執(zhí)行流程沒法簡化了，愁啊！也沒啥次要功能可以關(guān)了，桑心啊！那只能降低一致性了，即將核心業(yè)務(wù)流程的同步改異步，將強一致性改最終一致性！

可是這些都是手動降級，有辦法自動降級么？
在生產(chǎn)上沒弄自動降級！因為一般需要降級的場景，都是可以預(yù)見的，例如某某活動。假設(shè)，平時真的有突發(fā)事件，流量異常，也有監(jiān)控系統(tǒng)發(fā)郵件通知，提醒我們?nèi)ソ导墸?br/> 當然，這并不代表自動降級不能做，只是頭腦大概想了下，如果讓我來做自動降級我會怎么實現(xiàn)：

1. 自己設(shè)一個閾值，例如幾秒內(nèi)失敗多少次，就啟動降級

2. 自己做接口監(jiān)控(有興趣的可以了解一下Rxjava)，達到閾值就走推送邏輯。怎么推呢？比如你配置是放在git上，就用jgit去改配置中心的配置。如果配置放數(shù)據(jù)庫，就用jdbc去改。

3. 改完配置中心的配置后，應(yīng)用就可以自動檢測到配置的變化，進行降級！(這句不了解的，了解一下配置中心的熱刷新功能)

“web服務(wù)器分布式系統(tǒng)有什么特點”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！