溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“web服務器分布式系統有什么特點”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
一個tomcat打天下的時代，不能說完全淘汰了，在一個管理系統，小型項目中還經常使用，這并不過分，出于成本的考慮，這反而值得提倡。但如果要延伸到高并發場景下就必然要了解分布式系統：
分布式系統：一個硬件或軟件組件分布在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統
這是分布式系統，在不同的硬件，不同的軟件，不同的網絡，不同的計算機上，僅僅通過消息來進行通訊與協調
這是他的特點，更細致的看這些特點又可以有：分布性、對等性、并發性、缺乏全局時鐘、故障隨時會發生。
既然是分布式系統，最顯著的特點肯定就是分布性，從簡單來看，如果我們做的是個電商項目，整個項目會分成不同的功能，專業點就不同的微服務，比如用戶微服務，產品微服務，訂單微服務，這些服務部署在不同的tomcat中，不同的服務器中，甚至不同的集群中，整個架構都是分布在不同的地方的，在空間上是隨意的，而且隨時會增加，刪除服務器節點，這是第一個特性。
對等性是分布式設計的一個目標，還是以電商網站為例，來說明下什么是對等性，要完成一個分布式的系統架構，肯定不是簡單的把一個大的單一系統拆分成一個個微服務，然后部署在不同的服務器集群就夠了，其中拆分完成的每一個微服務都有可能發現問題，而導致整個電商網站出現功能的丟失。
比如訂單服務，為了防止訂單服務出現問題，一般情況需要有一個備份，在訂單服務出現問題的時候能頂替原來的訂單服務。這就要求這兩個（或者2個以上）訂單服務完全是對等的，功能完全是一致的，其實這就是一種服務副本的冗余。
還一種是數據副本的冗余，比如數據庫，緩存等，再比如大數據HDFS中的三個副本，都和上面說的訂單服務一樣，為了安全考慮需要有完全一樣的備份存在，這就是對等性的意思。
并發性其實對我們來說并不模式，在學習多線程的時候已經或多或少學習過，多線程是并發的基礎。但是以前都是在一個JVM上實現的并發，但現在我們要接觸的不是多線程的角度，而是更高一層，從多進程，多JVM的角度，例如在一個分布式系統中的多個節點，可能會并發地操作一些共享資源，如何準確并高效的協調分布式并發操作。分布式鎖就是干這個事的。
在分布式系統中，節點是可能反正任意位置的，而每個位置，每個節點都有自己的時間系統，因此在分布式系統中，很難定義兩個事務糾結誰先誰后，原因就是因為缺乏一個全局的時鐘序列進行控制，當然，現在這已經不是什么大問題了，已經有大把的時間服務器給系統調用
任何一個節點都可能出現停電，死機等現象，服務器集群越多，出現故障的可能性就越大，隨著集群數目的增加，出現故障甚至都會成為一種常態，怎么樣保證在系統出現故障，而系統還是正常的訪問者是作為系統搭建者應該考慮的。
知道什么是分布式系統，接下來具體來看下大型網站架構圖，首先整個架構分成很多個層，應用層，服務層，基礎設施層與數據服務層，每一層都由若干節點組成，這是典型的分布式架構，后面一大把的時間就是系統的學習里面的每一個部分。
那么zookeeper在其中又是扮演什么角色呢，如果可以把zk扮演成交警的角色，而各個節點就是馬路上的各種汽車（汽車，公交車），為了保證整個交通（系統）的可用性，zookeeper必須知道每一節點的健康狀態（公交車是否出了問題，要派新的公交【服務注冊與發現】），公路在上下班高峰是否擁堵，在某一條很窄的路上只允許單獨一個方向的汽車通過【分布式鎖】。
如果交通警察是交通系統的指揮官，而zookeeper就是各個節點組成分布式系統的指揮官。
如果把分布式系統和平時的交通系統進行對比，哪怕再穩健的交通系統也會有交通事故，分布式系統也有很多需要攻克的問題，比如：通訊異常、網絡分區、三態、節點故障等。
通訊異常其實就是網絡異常，網絡系統本身是不可靠的，由于分布式系統需要通過網絡進行數據傳輸，網絡光纖，路由器等硬件難免出現問題。只要網絡出現問題，也就會影響消息的發送與接受過程，因此數據消息的丟失或者延長就會變得非常普遍。
網絡分區，其實就是腦裂現象(參考Hadoop NameNode)，舉例來說：本來有一個交通警察，來管理整個片區的交通情況，一切井然有序，突然出現了停電，或者出現地震等自然災難，某些道路接受不到交通警察的指令，可能在這種情況下，會出現一個零時工，片警來指揮交通。但注意，原來的交通警察其實還在，只是通訊系統中斷了，這時候就會出現問題了，在同一個片區的道路上有不同人在指揮，這樣必然引擎交通的阻塞混亂。這種由于種種問題導致同一個區域（分布式集群）有兩個相互沖突的負責人的時候就會出現這種精神分裂的情況，在這里稱為腦裂，也叫網絡分區。
三態是什么？三態其實就是成功，與失敗以外的第三種狀態，當然，肯定不叫變態，而叫超時態。
在一個jvm中，應用程序調用一個方法函數后會得到一個明確的相應，要么成功，要么失敗，而在分布式系統中，雖然絕大多數情況下能夠接受到成功或者失敗的相應，但一旦網絡出現異常，就非常有可能出現超時，當出現這樣的超時現象，網絡通訊的發起方，是無法確定請求是否成功處理的。
這個其實前面已經說過了，節點故障在分布式系統下是比較常見的問題，指的是組成服務器集群的節點會出現的宕機或僵死的現象，這種現象經常會發生。
前面說了分布式的特點以及會碰到很多會讓人頭疼的問題，這些問題肯定會有一定的理論思想來解決問題的。接下來花點時間來談談這些理論，其中CAP和BASE理論是基礎，也是面試的時候經常會問到的
首先看下CAP，CAP其實就是一致性，可用性，分區容錯性這三個詞的縮寫
一致性是事務ACID的一個特性【原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）】。
這里講的一致性其實大同小異，只是現在考慮的是分布式環境中，還是不單一的數據庫。
在分布式系統中，一致性是數據在多個副本之間是否能夠保證一致的特性，這里說的一致性和前面說的對等性其實差不多。如果能夠在分布式系統中針對某一個數據項的變更成功執行后，所有用戶都可以馬上讀取到最新的值，那么這樣的系統就被認為具有強一致性。
可用性指系統提供服務必須一直處于可用狀態，對于用戶的操作請求總是能夠在有限的時間內訪問結果。這里的重點是有限的時間和返回結果。為了做到有限的時間需要用到緩存，需要用到負載，這個時候服務器增加的節點是為性能考慮；
為了返回結果，需要考慮服務器主備，當主節點出現問題的時候需要備份的節點能最快的頂替上來，千萬不能出現OutOfMemory或者其他500，404錯誤，否則這樣的系統我們會認為是不可用的。
分布式系統在遇到任何網絡分區故障的時候，仍然需要能夠對外提供滿足一致性和可用性的服務，除非是整個網絡環境都發生了故障。不能出現腦裂的情況。
PS:
一個分布式系統不可能同時滿足一致性、可用性和分區容錯性這三個基本需求，最多只能同時滿足其中的兩項。設計者的精力往往就花在怎么樣根據業務場景在A和C直接尋求平衡；
根據前面的CAP理論，設計者應該從一致性·和可用性之間找平衡，系統短時間完全不可用肯定是不允許的，那么根據CAP理論，在分布式環境下必然也無法做到強一致性。
BASE理論：
即使無法做到強一致性，但分布式系統可以根據自己的業務特點，采用適當的方式來使系統達到最終的一致性；
當分布式系統出現不可預見的故障時，允許損失部分可用性，保障系統的基本可用；體現在時間上的損失和功能上的損失；
e.g：部分用戶雙十一高峰期淘寶頁面卡頓或降級處理；
其實就是前面講到的三態,既允許系統中的數據存在中間狀態，既系統的不同節點的數據副本之間的數據同步過程存在延時，并認為這種延時不會影響系統可用性；
e.g：12306網站賣火車票，請求會進入排隊隊列；
所有的數據在經過一段時間的數據同步后，最終能夠達到一個一致的狀態；
e.g：理財產品首頁充值總金額短時不一致；
假設存在如下調用鏈
而此時，Service A的流量波動很大，流量經常會突然性增加！那么在這種情況下，就算Service A能扛得住請求，Service B和Service C未必能扛得住這突發的請求。
此時，如果Service C因為抗不住請求，變得不可用。那么Service B的請求也會阻塞，慢慢耗盡Service B的線程資源，Service B就會變得不可用。緊接著，Service A也會不可用，這一過程如下圖所示
如上圖所示，一個服務失敗，導致整條鏈路的服務都失敗的情形，我們稱之為服務雪崩。
那么，服務熔斷和服務降級就可以視為解決服務雪崩的手段之一。
服務熔斷：當下游的服務因為某種原因突然變得不可用或響應過慢，上游服務為了保證自己整體服務的可用性，不再繼續調用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復調用。
需要說明的是熔斷其實是一個框架級的處理，那么這套熔斷機制的設計，基本上業內用的是斷路器模式，如Martin Fowler提供的狀態轉換圖如下所示
最開始處于closed狀態，一旦檢測到錯誤到達一定閾值，便轉為open狀態。
這時候會有個 reset timeout，到了這個時間了，會轉移到half open狀態。
嘗試放行一部分請求到后端，一旦檢測成功便回歸到closed狀態，即恢復服務。
業內目前流行的熔斷器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix，在Hystrix中，對應配置如下
//滑動窗口的大小，默認為20 circuitBreaker.requestVolumeThreshold //過多長時間，熔斷器再次檢測是否開啟，默認為5000，即5s鐘 circuitBreaker.sleepWindowInMilliseconds //錯誤率，默認50% circuitBreaker.errorThresholdPercentage
每當20個請求中，有50%失敗時，熔斷器就會打開，此時再調用此服務，將會直接返回失敗，不再調遠程服務。直到5s之后，重新檢測該觸發條件，判斷是否把熔斷器關閉，或者繼續打開。
這些屬于框架層級的實現，我們只要實現對應接口就好！
什么是服務降級呢？這里有兩種場景:
當下游的服務因為某種原因響應過慢，下游服務主動停掉一些不太重要的業務，釋放出服務器資源，增加響應速度！
當下游的服務因為某種原因不可用，上游主動調用本地的一些降級邏輯，避免卡頓，迅速返回給用戶！
其實乍看之下，很多人還是不懂熔斷和降級的區別，其實應該要這么理解:
服務降級有很多種降級方式！如開關降級、限流降級、熔斷降級!
服務熔斷屬于降級方式的一種！
可能有的人不服，覺得熔斷是熔斷、降級是降級，分明是兩回事啊！其實不然，因為從實現上來說，熔斷和降級必定是一起出現。因為當發生下游服務不可用的情況，這個時候為了對最終用戶負責，就需要進入上游的降級邏輯了。因此，將熔斷降級視為降級方式的一種，也是可以說的通的！
撇開框架，以最簡單的代碼來說明！上游代碼如下
try{
//調用下游的helloWorld服務xxRpc.helloWorld();}catch(Exception e){
//因為熔斷，所以調不通doSomething();}注意看，下游的helloWorld服務因為熔斷而調不通。此時上游服務就會進入catch里頭的代碼塊，那么catch里頭執行的邏輯，你就可以理解為降級邏輯！
什么，你跟我說你不捕捉異常，直接丟頁面？OK，那我甘拜下風，當我理解錯誤!
服務降級大多是屬于一種業務級別的處理。當然，我這里要講的是另一種降級方式，也就是開關降級 這也是我們生產上常用的另一種降級方式！
做法很簡單，做個開關，然后將開關放配置中心！在配置中心更改開關，決定哪些服務進行降級。至于配置變動后，應用怎么監控到配置發生了變動，這就不是本文該討論的范圍。
那么，在應用程序中部下開關的這個過程，業內也有一個名詞，稱為埋點！
那接下來最關鍵的一個問題，哪些業務需要埋點？
一般有以下方法
簡化執行流程
自己梳理出核心業務流程和非核心業務流程。然后在非核心業務流程上加上開關，一旦發現系統扛不住，關掉開關，結束這些次要流程。
關閉次要功能
一個微服務下肯定有很多功能，那自己區分出主要功能和次要功能。然后次要功能加上開關，需要降級的時候，把次要功能關了吧！
降低一致性
假設，你在業務上發現執行流程沒法簡化了，愁啊！也沒啥次要功能可以關了，桑心啊！那只能降低一致性了，即將核心業務流程的同步改異步，將強一致性改最終一致性！
可是這些都是手動降級，有辦法自動降級么？
在生產上沒弄自動降級！因為一般需要降級的場景，都是可以預見的，例如某某活動。假設，平時真的有突發事件，流量異常，也有監控系統發郵件通知，提醒我們去降級！
當然，這并不代表自動降級不能做，只是頭腦大概想了下，如果讓我來做自動降級我會怎么實現：
自己設一個閾值，例如幾秒內失敗多少次，就啟動降級
自己做接口監控(有興趣的可以了解一下
Rxjava)，達到閾值就走推送邏輯。怎么推呢？比如你配置是放在git上，就用jgit去改配置中心的配置。如果配置放數據庫，就用jdbc去改。改完配置中心的配置后，應用就可以自動檢測到配置的變化，進行降級！(這句不了解的，了解一下配置中心的熱刷新功能)
“web服務器分布式系統有什么特點”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
