隨著運維的復(fù)雜和繁瑣化，運維工作也在進(jìn)行職責(zé)的細(xì)分，比如：基礎(chǔ)運維、系統(tǒng)運維、應(yīng)用運維，見名識意大概能猜出其職責(zé)，基礎(chǔ)運維偏重基礎(chǔ)資源，系統(tǒng)運維偏重系統(tǒng)也就是自動化運維，其中應(yīng)用運維是近年新出來的名詞，其既要對系統(tǒng)負(fù)責(zé)又要對產(chǎn)品的用戶體驗和成本負(fù)責(zé)，這就要求運維人員在做好日常系統(tǒng)運維的基礎(chǔ)上，深入研究業(yè)務(wù)，研究產(chǎn)品架構(gòu)和數(shù)據(jù)流。隨著微服務(wù)設(shè)計理念的普及，一個大型應(yīng)用被拆分成多個微服務(wù)，雖然帶來了諸多益處，但各微服務(wù)間的調(diào)用錯綜復(fù)雜，增加了運維、排障、調(diào)優(yōu)的難度，而應(yīng)用運維就是為了解決這個問題而產(chǎn)生的，工作中要與開發(fā)、基礎(chǔ)運維、DBA、CDN等各部門打交道，主導(dǎo)問題解決。

  一個應(yīng)用運維腦袋里至少要有產(chǎn)品業(yè)務(wù)邏輯架構(gòu)圖、數(shù)據(jù)請求流程圖、服務(wù)器部署架構(gòu)圖這3張圖，結(jié)合各種運維工具，當(dāng)出現(xiàn)故障能第一時間定位是哪個微服務(wù)、哪個機(jī)房、哪個負(fù)載均衡、哪臺服務(wù)器、哪幾行代碼導(dǎo)致，并找到相應(yīng)的負(fù)責(zé)人，第一時間進(jìn)行問題解決，如果短時間解決不了進(jìn)行相應(yīng)的故障升級、業(yè)務(wù)降級、流量調(diào)度。而且應(yīng)用運維在心中應(yīng)該有一本賬，知道系統(tǒng)架構(gòu)的短板在哪，為了提升整個系統(tǒng)的性能和吞吐量，如何進(jìn)行優(yōu)化；在有新的功能和應(yīng)用場景時，跟隨開發(fā)共同研究解決方案，評估技術(shù)可行性和業(yè)務(wù)邏輯的合理性，為公司節(jié)約基礎(chǔ)成本，因為微服務(wù)的一個改動可能就會惡性影響到上下游資源，特別是在業(yè)務(wù)量大的場景，多調(diào)用一次每天可能就會多1000萬次請求，少調(diào)用一次可能就會優(yōu)化500萬次請求，上下游依賴的微服務(wù)容量以及跨南北調(diào)用的問題等都要考慮。

  從繁瑣的工作中尋找規(guī)律，應(yīng)用運維拆分收斂后基本上就是三塊：圍繞數(shù)據(jù)、圍繞運維管理、圍繞產(chǎn)品本身三大部分，其中圍繞數(shù)據(jù)的包含告警、監(jiān)控、數(shù)據(jù)分析、異常檢測、性能分析，圍繞運維管理的包含資產(chǎn)管理、配置管理、代碼上線、服務(wù)調(diào)度，圍繞產(chǎn)品本身的包含調(diào)優(yōu)、消峰、降級、容災(zāi)，其余的事情基本都是基礎(chǔ)運維處理，下面拿我負(fù)責(zé)的內(nèi)容服務(wù)平臺的前端業(yè)務(wù)做一個拋磚引玉應(yīng)用運維的介紹。

內(nèi)容服務(wù)平臺的總體概述：

  公司的內(nèi)容服務(wù)平臺是一個微服務(wù)架構(gòu)設(shè)計的大型內(nèi)容管理系統(tǒng)，上行寫入面向公司編輯和抓站，下行是在線的頁面、接口、文件（圖片）和裁圖服務(wù)，為了靈活應(yīng)對消峰和系統(tǒng)迭代開發(fā)等場景，系統(tǒng)做了徹底的服務(wù)化和組件化拆分，模塊間通過HTTP型API進(jìn)行調(diào)用，一些模塊通過消息中間件進(jìn)行異步解耦。內(nèi)容服務(wù)平臺在公司的一個生態(tài)位置圖如下：

  從上圖看，內(nèi)容服務(wù)平臺是一個核心的數(shù)據(jù)源，同時提供了4大塊在線服務(wù)，在此之上生長了各種應(yīng)用。各產(chǎn)品可以直接在頁面服務(wù)模塊開發(fā)應(yīng)用，如果是APP類也可以通過接口服務(wù)獲取平臺的內(nèi)容和功能再自行處理，下面以此產(chǎn)品為例展開介紹運維工作圍繞數(shù)據(jù)、圍繞運維管理、圍繞產(chǎn)品本身的三塊內(nèi)容。

一、圍繞數(shù)據(jù)

  圍繞數(shù)據(jù)都有哪些事兒呢？順著數(shù)據(jù)去考慮，比如監(jiān)控告警、異常檢測、日志分析、性能分析、機(jī)器學(xué)習(xí)等等，其中圍繞數(shù)據(jù)的應(yīng)用核心三點是數(shù)據(jù)采集、分析和使用。

  一個系統(tǒng)在運行中會產(chǎn)生各種數(shù)據(jù)，而產(chǎn)品的健康狀況就藏在這些數(shù)據(jù)里，應(yīng)用運維需要通過各種手段和工具將這些數(shù)據(jù)收集起來，并對其收斂做成監(jiān)控，進(jìn)而對監(jiān)控收斂做成告警。我們通過告警發(fā)現(xiàn)故障、監(jiān)控定位故障點、產(chǎn)品運維處理分發(fā)故障，短時間解決不了的，進(jìn)行故障升級、業(yè)務(wù)降級、切換流量。為了能夠?qū)⑦€沒有形成故障的薄弱接口提前暴露出來優(yōu)化解決，預(yù)防故障，我們依托歷史數(shù)據(jù)做了異常檢測，每天將前一天的薄弱接口計算出來，發(fā)給此接口的最近修改人，推動其優(yōu)化。

  隨著用戶量的增加和系統(tǒng)的更加復(fù)雜化，慢慢就有了監(jiān)控每個環(huán)節(jié)性能的需求，如果從用戶的訪問流考慮，把每個環(huán)節(jié)都做埋點日志打出來，就可以做到產(chǎn)品的APM性能分析，從而掌握每個環(huán)節(jié)的健康情況，總之圍繞數(shù)據(jù)的應(yīng)用有足夠多的想象空間，最終可以通過機(jī)器學(xué)習(xí)來尋找更多的數(shù)據(jù)規(guī)律，為各層面的人員提供服務(wù)。

  目前內(nèi)容服務(wù)平臺每天產(chǎn)生的數(shù)據(jù)在2T以上，畫了一個圍繞數(shù)據(jù)的整體架構(gòu)圖如下：

  我們將監(jiān)控告警從整體上分為了系統(tǒng)層和應(yīng)用層，系統(tǒng)層的基礎(chǔ)監(jiān)控（cpu、內(nèi)存、網(wǎng)絡(luò)、硬盤io）通過zabbix來實現(xiàn)，應(yīng)用層面的監(jiān)控告警走數(shù)據(jù)分析的渠道。

  我們每天的異常檢測的幾張圖表如下（在此多謝雄飛同學(xué)的一起研究貢獻(xiàn)）：

二、圍繞運維管理

  運維管理是比較老生常談的東西，從運維這個工種出現(xiàn)開始大家就一直在做，做到現(xiàn)在收斂總結(jié)一下基本就是資產(chǎn)管理、配置管理、代碼上線、服務(wù)調(diào)度降級管理四塊，當(dāng)然根據(jù)產(chǎn)品屬性的不同有一些個性化的管理工具，那個就另說了。

  我們現(xiàn)在資產(chǎn)管理自己開發(fā)的，配管用的puppet和salt，底層套了版本管理，用戶層加了ui界面，代碼上線和服務(wù)調(diào)度降級也是個性化開發(fā)的，作為一個有歷史的互聯(lián)網(wǎng)公司，其實運維對運維管理這塊更多是理解和應(yīng)用而不是搭建開發(fā)的層面，因為很多這些工具都有前輩做好了，運維管理這一塊就不展開說了。

三、圍繞產(chǎn)品本身

  能做到每天上班喝著茶看著報紙的產(chǎn)品運維其實不存在，隨著業(yè)務(wù)系統(tǒng)的迭代和應(yīng)用場景的變化等，產(chǎn)品和集群架構(gòu)的各種工作其實沒有停歇，好在多機(jī)房多服務(wù)器部署對于容災(zāi)做的很成熟，即使有單臺服務(wù)器或單個機(jī)房有問題也可以自動負(fù)載調(diào)度，繁瑣的工作中總結(jié)了這些方法論。

  拿內(nèi)容服務(wù)平臺里的動態(tài)前端模塊做例子，微服務(wù)化拆分后，它作為下行用戶體驗的一個核心體現(xiàn)，系統(tǒng)是nginx+php-fpm的結(jié)構(gòu)，作為接口層（HTTP API）和用戶接入層對外服務(wù)，目前服務(wù)的業(yè)務(wù)域名有200個，功能接口上萬個，日訪問量在7到10個億，平均響應(yīng)時間從我接手時139ms優(yōu)化到現(xiàn)在已經(jīng)到了30ms，只有網(wǎng)民的讀沒有寫場景（評論調(diào)第三方接口，平臺本身不提供功能），但后端php會根據(jù)不同ua、args、reffer、cookie判斷吐不同的html頁面，會通過HTTP API調(diào)用為其他業(yè)務(wù)系統(tǒng)提供數(shù)據(jù)，典型的前端型業(yè)務(wù)，由于為N多個業(yè)務(wù)部門提供服務(wù)，并且開放權(quán)限申請和域名接入，其后在平臺上各自編寫代碼，所以我稱作其為平臺型前端業(yè)務(wù)。在操作上，開通域名站點和權(quán)限后，業(yè)務(wù)開發(fā)登錄后臺，按照規(guī)則在微服務(wù)主應(yīng)用平臺上編寫代碼，然后審核上線到動態(tài)前端的服務(wù)器上對外服務(wù)，動態(tài)前端完成了頁面渲染、php路由、功能調(diào)用和緩存功能（使用MC和reids），同時也依賴了大量外部接口，這些接口通過curl和js（ajax）進(jìn)行調(diào)用。在劃分上，接口層是作為功能應(yīng)用（HTTP API）吐的是json串，無狀態(tài)的為其它業(yè)務(wù)模塊服務(wù)，用戶接入層就是直接面向網(wǎng)民的訪問服務(wù)。

1、調(diào)優(yōu) 

  1）系統(tǒng)軟件的調(diào)優(yōu)

  系統(tǒng)軟件的調(diào)優(yōu)指的是centos、nginx、php-fpm、ats等這種軟件的軟調(diào)優(yōu)，這種調(diào)優(yōu)雖然比不上加機(jī)器，但是也是非常非常重要的。比如在我接手這個業(yè)務(wù)時，動態(tài)前端使用的是nginx1.4.7版本，由于也沒出什么問題就一直沒動，后來在升級了tengine2.1.2之后，調(diào)整了一些參數(shù)，平均響應(yīng)時間提升了將近一半，所以系統(tǒng)軟件的調(diào)優(yōu)也是不容小看的。系統(tǒng)軟件的調(diào)優(yōu)包含系統(tǒng)軟件的版本升級和系統(tǒng)軟件的參數(shù)的調(diào)整優(yōu)化。

  2）業(yè)務(wù)分池故障隔離調(diào)優(yōu)

  任何做法都有其原因，比如說N多業(yè)務(wù)使用一套CMS，前端訪問使用一個大池子，而不是每個業(yè)務(wù)單獨來一套，其實是共享的概念，這種共享做法的好處自不必多說，大大減少了資源浪費和節(jié)約了人力成本。但隨著加入業(yè)務(wù)的越來越多，關(guān)聯(lián)調(diào)用越來越復(fù)雜，訪問量越來越大，系統(tǒng)的高可用性越來越重要，因為出故障的影響越來越嚴(yán)重，隨之帶來了各種大系統(tǒng)病。

  比如說動態(tài)前端，用戶訪問雖然會通過dns智能解析把不同請求分發(fā)到不同機(jī)房，但從業(yè)務(wù)邏輯看終究是一個大池子，如果某個業(yè)務(wù)接口或頁面模板有問題，會瞬間把php進(jìn)程池堵死，到時不分誰的業(yè)務(wù)，全部報錯，結(jié)果就是個別業(yè)務(wù)代碼影響到了全部業(yè)務(wù)。分析后，分池隔離是勢在必行的一個事兒，一來減少業(yè)務(wù)間的相互影響，二來讓優(yōu)質(zhì)的業(yè)務(wù)跑的更健壯。然后分析服務(wù)屬性，發(fā)現(xiàn)有兩類業(yè)務(wù)，一類是直接面向網(wǎng)民的用戶接入層，這類訪問受最后一公里上網(wǎng)環(huán)境的影響，更容易出各種問題，另一個是作為微服務(wù)提供HTTP API功能調(diào)用吐的是json串，這個一般是外部系統(tǒng)過來的功能調(diào)用，環(huán)境相對簡單。將這兩個業(yè)務(wù)拆開成頁面池和接口池后，理論上故障減少一半，整個業(yè)務(wù)更加健壯。

  分池是一種隔離方法，可以完全通過調(diào)度分發(fā)實現(xiàn)，不需要開發(fā)重構(gòu)代碼，隨著業(yè)務(wù)的變化，可靈活實施拆分，比如結(jié)合業(yè)務(wù)方需求，將需要重保的業(yè)務(wù)分出來、將訪問量大的業(yè)務(wù)分出來、將危險的接口分出來。。。。所謂道法自然，術(shù)變?nèi)f千。

  3）程序執(zhí)行時間限制調(diào)優(yōu)

  作為一個平臺，為了保障整體業(yè)務(wù)的健壯，必須通過時間限制割肉放棄慢或錯誤的請求，俗話說不能因為“幾顆老鼠屎壞了一鍋湯”，程序執(zhí)行時間限制分為兩個層次，一個是外部php woker進(jìn)程允許的php腳本的最大執(zhí)行時間，另一個是腳本代碼里通過curl依賴的外部接口的時間限制。

  對于php worker進(jìn)程的時間限制，分池后，同一個池子還是混跑著各種接口，如果某個業(yè)務(wù)的代碼有問題，將php資源池堵死，同池內(nèi)的其它業(yè)務(wù)同樣會受到牽連，為防止這個問題，必須要做php的執(zhí)行時間限制，將執(zhí)行慢的業(yè)務(wù)割肉拋棄，不至于影響總體業(yè)務(wù)，慢請求達(dá)到指定時間后馬上殺掉，返回502代碼。配置后，反向倒逼業(yè)務(wù)方對自個兒的代碼和邏輯進(jìn)行調(diào)優(yōu)，定期將502/504的top排名發(fā)給業(yè)務(wù)方，給他們以壓力，對應(yīng)的配置如下：

  對于程序中curl的時間限制，升級lib庫后已支持到ms級控制，可以根據(jù)接口的情況進(jìn)行限制，系統(tǒng)有一個整體閥值。比如說我們當(dāng)前的限制，所有接口默認(rèn)超時時間是1s，最長容忍設(shè)置為2秒，ms級的控制業(yè)務(wù)方可以自行配置，因為當(dāng)訪問量上來后，各業(yè)務(wù)方必須對自個兒的用戶體驗負(fù)責(zé)。最長容忍設(shè)置為2s，同時也倒逼業(yè)務(wù)方對其使用的接口進(jìn)行不斷調(diào)優(yōu)。

  4）依賴資源local化調(diào)優(yōu)

  這個是最常識，但是又最容易被忽略的地方，比如說動態(tài)前端依賴了mc、redis這些緩存資源，能做到本機(jī)房、同網(wǎng)段、同交換機(jī)效率是最高的，最次也是同內(nèi)網(wǎng)跨機(jī)房，少一個節(jié)點，就少一個故障點，少一個資源消耗。對于通過curl或者js依賴的接口，要做到不跨南北、不跨運營商調(diào)用，否則單看網(wǎng)絡(luò)時延就夠大的，而且可能丟包，實際操作中其實很難做到，所以對于實時性不是非常強(qiáng)的接口，要對接口的緩存結(jié)果做下curl的cache。

  5）HTTP API提供內(nèi)網(wǎng)接口調(diào)優(yōu)

  一個HTTP API功能接口，通過域名解析到公網(wǎng)IP進(jìn)行調(diào)用，如果大部分調(diào)用是由公司內(nèi)部系統(tǒng)發(fā)起的，那么就沒必要走公網(wǎng)透傳一遍，這個時候就需要做一個解析到內(nèi)網(wǎng)IP供內(nèi)網(wǎng)調(diào)用的域名，也就是做一個內(nèi)網(wǎng)接口，減少網(wǎng)絡(luò)時延消耗和故障率。

  動態(tài)前端有一塊功能是為其他業(yè)務(wù)系統(tǒng)提供HTTP API的接口調(diào)用，吐的是json串，有很大一部分請求是公司內(nèi)部系統(tǒng)發(fā)起，在結(jié)構(gòu)上，我們接口域名解析到公司的外網(wǎng)vip（lvs），vip下屬掛著7層的Ha，下面才是我們的服務(wù)器，走外網(wǎng)調(diào)用相當(dāng)于這些全部環(huán)節(jié)透傳一遍，還要走外網(wǎng)網(wǎng)關(guān)、外網(wǎng)鏈路、外網(wǎng)帶寬，而做好內(nèi)網(wǎng)接口后，故障少了的同時也提高了系統(tǒng)性能。

  6）本地內(nèi)存和網(wǎng)絡(luò)緩存的二級緩存模式

  這個很重要，像cms當(dāng)前的業(yè)務(wù)，我們?yōu)殚_發(fā)在本地服務(wù)器上安裝了php的yac擴(kuò)展，配置了key64M和value1024M的緩存供其使用。開發(fā)在使用一些熱資源時，進(jìn)行本地和遠(yuǎn)程mc或redis的雙寫，讀取時先在本地內(nèi)存找，本地找不到再到mc或redis上回源，遠(yuǎn)程也沒有再進(jìn)行穿透，這大大提高了系統(tǒng)的吞吐量和性能，同時呢也起到了一定的削峰作用，相當(dāng)于每臺服務(wù)器都有一個高速緩存，mc或者redis成為了他們的回源緩存，速度可想而知。

2、削峰

  隨著業(yè)務(wù)和技術(shù)發(fā)展，push類的業(yè)務(wù)成為一種需要常態(tài)應(yīng)對的場景，熱點事件、熱點活動。。。。可以看下我們的QPS圖，這種場景的處理已經(jīng)很迫切，需要找出峰值的瓶頸點，找出解決方案，不影響服務(wù)，除了模塊提前擴(kuò)容，簡單總結(jié)一下幾個做法。
                                                                  
       

  1）動靜分離后的cdn方案（訪問削峰）；

  對于下行訪問，分析出有峰值的域名業(yè)務(wù)，針對性處理，cdn結(jié)合輕量級緩存nginx cache是一個非常強(qiáng)悍的削峰方案（cdn本質(zhì)其實就是類nginx cache加上調(diào)度）。適合的場景是靜態(tài)業(yè)務(wù)，要對一個域名做cdn得盡量動靜分離的徹底，而且域名下屬服務(wù)業(yè)務(wù)邏輯簡單。

  2）服務(wù)器輕量級nginx cache方案（訪問削峰）

  并不是所有的業(yè)務(wù)都適合cdn或做nginx cache。比如說目前的動態(tài)前端，很多服務(wù)會根據(jù)ua、args、reffer、cookie綜合判斷后吐一個內(nèi)容，如果按照這四個合集再加上url做一個key，基本上沒有命中率的，反而是增加了業(yè)務(wù)復(fù)雜性。這就需要改造，在業(yè)務(wù)和cdn間取一個都能接受的方案，太復(fù)雜的判斷在cdn上是不好做的，cdn本身也是一個無狀態(tài)的服務(wù)。比如動態(tài)前端有個push屬性的域名業(yè)務(wù)，必須做削峰處理，分析后會根據(jù)ua、參數(shù)判斷吐兩份不同html，在業(yè)務(wù)方做了js的ua判斷改造，cdn做了個性化參數(shù)判斷后才上了cdn，削峰問題能夠解決，對各方來說都能松一口氣。

  3）消息隊列消費削峰（寫削峰、數(shù)據(jù)庫相關(guān)重邏輯削峰）；

  采用消息隊列是上行寫入、數(shù)據(jù)庫相關(guān)重邏輯、質(zhì)量重點保障業(yè)務(wù)的削峰利器，以時間成本換取業(yè)務(wù)的正常服務(wù)，因為總有一些邏輯比較重的業(yè)務(wù)又是絕對性不能出錯的服務(wù)，像cms里寫入、發(fā)布環(huán)節(jié)的一些模塊，都是通過消息中間件進(jìn)行解耦削峰的。

3、降級

  先說下什么是降級，所謂降級就是業(yè)務(wù)出問題時，還能夠降低要求為網(wǎng)民服務(wù)，不致于直接服務(wù)掛掉，最常用的做法有靜態(tài)化、返回默認(rèn)值和摘掉接口。舉個簡單例子，動態(tài)前端的評論是依賴其他部門的系統(tǒng)，通過curl去獲取的評論、評論數(shù)等，一旦評論系統(tǒng)掛掉，假設(shè)我們緩存了最近一次拿的評論數(shù)據(jù)，就可以通過歷史緩存為網(wǎng)民展示出問題前的最近一次評論，雖然做不到實時展示，但至少系統(tǒng)沒有報錯，網(wǎng)民還是可以看到內(nèi)容。或者使用將評論系統(tǒng)摘掉的策略，雖然用戶無法看到和使用評論，但至少能看到其它信息，不至于評論影響到全部業(yè)務(wù)，當(dāng)然這個方式就比較重了，影響用戶體驗。

  與程序執(zhí)行時間限制調(diào)優(yōu)類似，降級也分兩個層次，一個是程序直接對外結(jié)果的降級，比如說html文件或者json串，另一個是程序內(nèi)部寫的curl依賴接口的降級。第一個可以結(jié)合類nginx cahce來做，使用stale文件進(jìn)行服務(wù)降級，也可通過程序靜態(tài)化實現(xiàn)，第二個就要程序?qū)用鎸崿F(xiàn)了，下面會說一下我們實現(xiàn)的方式。

  1）php內(nèi)curl獲取外部接口緩存降級，配合懲罰機(jī)制（程序自動）

  簡單說下實現(xiàn)，每次curl獲取數(shù)據(jù)后，同時將內(nèi)容存入MC，形成一個最近1小時的歷史數(shù)據(jù)，當(dāng)檢測到連續(xù)幾次curl超時或數(shù)據(jù)錯誤就默認(rèn)接口出了問題，自動啟用降級，取MC最近一次可用的歷史數(shù)據(jù)為用戶服務(wù)，設(shè)置懲罰策略，比如說降級5分鐘后自動恢復(fù)業(yè)務(wù)，如果繼續(xù)出問題，就會循環(huán)往復(fù)這種操作。   

  2）html文件在判斷請求隊列達(dá)到閥值后自動降級（程序自動）

  類nginx cache方式不多說，簡單講講程序的做法。tcp連接數(shù)側(cè)面反應(yīng)了任務(wù)隊列的處理情況，我們恰是通過判斷tcp連接隊列（80、9000端口的連接數(shù)）來控制降級的，程序會隔一段時間存一次正確的靜態(tài)化結(jié)果至服務(wù)器硬盤，當(dāng)tcp連接隊列一旦超過閥值，表示業(yè)務(wù)可能有問題，立馬不再穿透到后端取數(shù)據(jù)，轉(zhuǎn)而取本機(jī)靜態(tài)化數(shù)據(jù)，當(dāng)連接隊列恢復(fù)正常后，自動取消靜態(tài)化。

  3）手動降級（按外部接口、按服務(wù)url）

  這是作為產(chǎn)品運維要求開發(fā)部門做的一個功能，程序畢竟是死的，人是活的，有自動降級必定要有手動降級作為補(bǔ)充操作，一旦遇到必須手動降級的操作，如果有操作頁面，就不需要每次都去找開發(fā)改代碼。例如我想降級平臺某個url或一個curl依賴的接口，只需要按照要求輸入相關(guān)配置——url、降級時間、回源周期等，就可以立即降級了。

4、容災(zāi)

  對于容災(zāi)，也是一定要考慮的，包含機(jī)房間容災(zāi)和機(jī)器間容災(zāi)。我們現(xiàn)在的思路，絕大部分業(yè)務(wù)通過熱備加健康心跳來實現(xiàn)，在評估過的服務(wù)器基礎(chǔ)上，多加兩臺服務(wù)器，如果有服務(wù)器死掉，流量會自動調(diào)度到其余服務(wù)器上。

  比如說當(dāng)前的cms，lvs下掛了ha集群，ha集群下面掛了我們的webserver，每一層都有健康心跳，當(dāng)某臺服務(wù)器死掉后，流量會自動負(fù)載到其余活著的服務(wù)器上，當(dāng)服務(wù)器起來后，流量再自動調(diào)度回來，為了提高用戶服務(wù)質(zhì)量，同時做好容災(zāi)，我們會把服務(wù)器分到不同的機(jī)房中去。