內(nèi)網(wǎng)車禍一直是互聯(lián)網(wǎng)公司盡量避免的事情，也是服務(wù)端程序員最關(guān)心的問題之一。 但是，如果我們統(tǒng)計(jì)一下各種內(nèi)網(wǎng)事故的原因，我們會(huì)發(fā)現(xiàn)一個(gè)推論：內(nèi)網(wǎng)事故70%的原因是在運(yùn)維領(lǐng)域，而只有30%左右的事故原因是由于BUG造成的。程序本身造成的。 這里所說的“運(yùn)維領(lǐng)域激勵(lì)”包括配置錯(cuò)誤、現(xiàn)網(wǎng)運(yùn)行錯(cuò)誤、網(wǎng)絡(luò)或其他硬件環(huán)境發(fā)生變化、硬件故障等。 在盛行“運(yùn)維”與“開發(fā)”分離的時(shí)代，雖然這是運(yùn)維的錯(cuò)，但這個(gè)錯(cuò)已經(jīng)扛了好六年了，一直沒有本質(zhì)的進(jìn)步。 說明這一技術(shù)問題不能僅僅通過單純的“區(qū)分責(zé)任”的管理方式來解決。 例如，當(dāng)您需要重新部署一個(gè)包含數(shù)百個(gè)進(jìn)程并分為數(shù)十種不同類型的服務(wù)的系統(tǒng)時(shí)，您可能需要小心處理數(shù)十個(gè)或數(shù)百個(gè)配置和操作命令。 這種配置和命令有很多相似之處，有些地方需要仔細(xì)辨別優(yōu)缺點(diǎn)。 另外這個(gè)配置里面有很多相互關(guān)系，大家一定要理解的很清楚，并且對(duì)這個(gè)配置和命令的執(zhí)行順序有嚴(yán)格的要求。 部署所有這些就像操作帶有數(shù)百個(gè)按鈕的機(jī)器面板。 最可怕的是，其中任何一個(gè)出錯(cuò)，系統(tǒng)都可能立即引發(fā)“外網(wǎng)車禍”，或者在未來不可預(yù)知的時(shí)間引發(fā)“外網(wǎng)車禍”。 這導(dǎo)致老板半夜三點(diǎn)把你從床上拖到筆記本電腦前來處理這個(gè)爛攤子。 其實(shí)我說的這種情況并不是每個(gè)項(xiàng)目都會(huì)發(fā)生，我們確實(shí)在很多項(xiàng)目中都不同程度地陷入了類似的陷阱。 不知道我們是不是已經(jīng)被復(fù)雜的httpd征服了。 conf，所以很多程序員都非常喜歡配置文件。 “一切都應(yīng)該是可配置的！” 不僅成為了我們的口號(hào)，也成為了無(wú)數(shù)復(fù)雜的配置項(xiàng)和花哨的工具命令。 ——但這種事情，在實(shí)際的商業(yè)運(yùn)作中，卻成了無(wú)數(shù)的定時(shí)炸彈。

【程序員愛配置文件】

手動(dòng)測(cè)試已成為當(dāng)今開發(fā)的標(biāo)準(zhǔn)程序之一。 尤其是在敏捷開發(fā)方法盛行之后，最重要的實(shí)踐之一就是手工測(cè)試。 我們知道，通常我們用于測(cè)試的環(huán)境往往與真實(shí)環(huán)境不同。 例如，我們?cè)谧龉δ軠y(cè)試時(shí)，運(yùn)行被測(cè)程序的顯存和硬盤可能比實(shí)際運(yùn)行環(huán)境要小很多。 如果我們的程序因?yàn)橛布蛘逫P地址等其他軟件的不同而需要配置運(yùn)行，那么我們的每一個(gè)測(cè)試都可能需要手動(dòng)操作。 不能說是“自動(dòng)化”。 再加上人為失誤，更容易導(dǎo)致測(cè)試結(jié)果出現(xiàn)嚴(yán)重錯(cuò)誤。 測(cè)試工作不僅環(huán)境不同會(huì)造成運(yùn)維操作，自測(cè)也需要多個(gè)環(huán)境。 比如很多系統(tǒng)有多個(gè)分支同時(shí)開發(fā)，或者有內(nèi)部功能測(cè)試、外部邀請(qǐng)用戶測(cè)試、公開測(cè)試等多個(gè)測(cè)試環(huán)境。 假設(shè)我們的軟件每次部署都需要大量的人工操作，面對(duì)多種環(huán)境，頻繁發(fā)布新版本進(jìn)行測(cè)試，那么部署工作一定是非常繁重的，而這種繁瑣的工作本來是可以盡可能避免的。

【一個(gè)漂亮的CI閉環(huán)，往往毀于復(fù)雜的部署流程】

快速發(fā)展仍然是現(xiàn)代軟件公司追求的目標(biāo)。 由于不斷變化的需求和市場(chǎng)，軟件產(chǎn)品和應(yīng)用系統(tǒng)也被迫每晚更新其功能。 說到服務(wù)器端軟件，我們?cè)陂_發(fā)過程中往往需要和很多其他程序一起開發(fā)調(diào)試。 最典型的就是與客戶端軟件進(jìn)行交互。 假設(shè)每一個(gè)參與項(xiàng)目的程序員都集中連接到一個(gè)開發(fā)服務(wù)器進(jìn)行調(diào)試，必然會(huì)產(chǎn)生各種相互影響。 而這些跨機(jī)開發(fā)環(huán)境往往只有一些命令行界面，效率不如圖形界面的IDE軟件。 假設(shè)我們開發(fā)的程序，尤其是服務(wù)端軟件，可以直接在開發(fā)的工作機(jī)上運(yùn)行和調(diào)試，這樣不僅響應(yīng)速度更快，而且在多個(gè)程序同時(shí)運(yùn)行時(shí)也可以方便調(diào)試時(shí)間，這對(duì)于經(jīng)常因“聯(lián)調(diào)”而頭疼的工程師來說，是一種非常有效的提高工作效率的措施。 但是上面提到的這些方法都需要我們的服務(wù)端程序，可以很方便的部署到各種環(huán)境中。 另一方面，有些服務(wù)器系統(tǒng)結(jié)構(gòu)比較復(fù)雜，需要啟動(dòng)很多進(jìn)程，很多配置文件可以配對(duì)啟動(dòng)，所以你肯定懶得部署很多套，而是擠在一個(gè)環(huán)境里為了發(fā)展。

分布式系統(tǒng)運(yùn)維友好性難點(diǎn)

避免資源泄漏。 我們知道服務(wù)器端程序需要常年運(yùn)行，我們非常擔(dān)心資源系列，比如顯存漏洞、文件句柄漏洞、網(wǎng)絡(luò)連接相關(guān)漏洞等等。 所以很多時(shí)候，我們?cè)敢庠诜?wù)器一啟動(dòng)的時(shí)候就“占用”或者“分配”所有需要的資源，然后不管后續(xù)請(qǐng)求進(jìn)來多少，做什么事情，都完全沒有必要了。 “分布”，從而避免一切“泄漏”。 但是這種方式也大大增加了程序運(yùn)維的復(fù)雜度。 首先，我們無(wú)法明確硬編碼一個(gè)程序運(yùn)行的硬件資源。 相反，我們?cè)O(shè)計(jì)諸如配置文件和命令行參數(shù)之類的東西來根據(jù)運(yùn)行環(huán)境來確定可能使用的硬件資源。 比如我們會(huì)在配置文件中設(shè)計(jì)一個(gè)“網(wǎng)絡(luò)契約緩沖區(qū)大小”配置項(xiàng)，根據(jù)服務(wù)器的顯存大小進(jìn)行配置。 此外，程序中的功能可能非常復(fù)雜。 如果要將使用的顯存、文件等所有資源都變成配置項(xiàng)，那么配置文件也必須極其復(fù)雜。 如果我們期望運(yùn)維人員理解這個(gè)配置文件，最好還是讓開發(fā)人員自己運(yùn)維，因?yàn)殚_發(fā)人員有時(shí)并沒有想清楚這些資源的合理分配——原因是過于依賴這些“預(yù)申請(qǐng)”表格被用來拖延解決疑難問題。 避免資源漏洞是一個(gè)重要的問題，但簡(jiǎn)單地將資源申請(qǐng)變成配置文件也會(huì)帶來另一場(chǎng)災(zāi)難。 可怕的是，這些配置文件災(zāi)難將支撐多進(jìn)程協(xié)作系統(tǒng)的幾何倍數(shù)增長(zhǎng)。 這些運(yùn)維復(fù)雜度在一個(gè)系統(tǒng)剛剛上線的時(shí)候其實(shí)是可以接受的。 然而，隨著系統(tǒng)逐漸變得龐大和復(fù)雜，運(yùn)維工作的難度猶如冷水煮烏龜。 無(wú)法清理。 經(jīng)過3-5年的運(yùn)行，一些系統(tǒng)已經(jīng)發(fā)展到?jīng)]有人可以從頭部署一個(gè)新環(huán)境的地步。

快速排除故障。 今天的商業(yè)應(yīng)用系統(tǒng)往往不是一個(gè)非常簡(jiǎn)單的功能體，而是包含大量相關(guān)或不相關(guān)的功能。 我們最擔(dān)心的是，這種聯(lián)動(dòng)功能，在同時(shí)處理上千個(gè)網(wǎng)絡(luò)請(qǐng)求時(shí)，如果某部分功能代碼出現(xiàn)bug，導(dǎo)致整個(gè)系統(tǒng)不可用。 所以我們往往更喜歡構(gòu)建某種隔離系統(tǒng)，比如在不同的進(jìn)程中運(yùn)行不同功能的代碼。 這樣，借助操作系統(tǒng)工具，就可以很快發(fā)現(xiàn)這些有問題的代碼。 但是如果真的要將一個(gè)系統(tǒng)的多個(gè)功能分離到不同的進(jìn)程中運(yùn)行，首先會(huì)遇到的就是進(jìn)程間通信的問題。 這個(gè)問題是現(xiàn)代分布式系統(tǒng)的核心問題之一，無(wú)數(shù)的開源軟件項(xiàng)目都在試圖解決這個(gè)問題。 但是不管是使用開源軟件還是自己寫代碼解決，這樣都會(huì)增加系統(tǒng)的進(jìn)程數(shù)。 特別是，我們喜歡按功能來定義代碼和流程，也就是說，在運(yùn)維一個(gè)系統(tǒng)的時(shí)候，我們需要面對(duì)大量“不同類型”的流程。 而且我們定義的功能越詳細(xì)，流程的種類就越多，需要運(yùn)維的流程也就越復(fù)雜。 在管理這種進(jìn)程時(shí)，不僅需要配置后面提到的一些性能參數(shù)，還需要配置海量的進(jìn)程間關(guān)系。 而這種進(jìn)程間的關(guān)系會(huì)隨著業(yè)務(wù)的變化而變化。 對(duì)于這些沒有具體接觸開發(fā)需求的運(yùn)維人員來說，簡(jiǎn)直就是噩夢(mèng)。 事實(shí)上，一些程序員開始在通信公司工作服務(wù)器運(yùn)維，因此他們非常習(xí)慣按流程定義功能，按通信級(jí)別組織系統(tǒng)，而隨著業(yè)務(wù)系統(tǒng)越來越復(fù)雜，這些工作習(xí)慣帶來了很多麻煩——每周，可能需要向系統(tǒng)添加新進(jìn)程，或者調(diào)整各個(gè)進(jìn)程的通信關(guān)系。 不同的行業(yè)需要不同的技術(shù)方案，這是理性工程師的看法。

負(fù)載均衡。 現(xiàn)代服務(wù)器端系統(tǒng)基本上是分布式系統(tǒng)。 即由多個(gè)服務(wù)器、多個(gè)進(jìn)程組合??起來提供服務(wù)的系統(tǒng)。 為了使該系統(tǒng)穩(wěn)定工作，最常見的措施是避免過載。 為避免多個(gè)進(jìn)程出現(xiàn)一定的過載，需要進(jìn)行負(fù)載均衡。 為避免同類所有進(jìn)程過載，需要過載保護(hù)。 分布式系統(tǒng)中最常見的配置任務(wù)之一是配置每種類型的進(jìn)程啟動(dòng)的數(shù)量以及每個(gè)進(jìn)程的過載保護(hù)閾值。 但是在一個(gè)有幾千個(gè)進(jìn)程，幾百臺(tái)服務(wù)器的系統(tǒng)中，要準(zhǔn)確填寫這個(gè)配置其實(shí)是非常困難的。 特別是，此類服務(wù)器的性能并不像提供商所說的那樣一致。 如果需要在集群中增加一些服務(wù)器，或者改變（搬遷）個(gè)別服務(wù)器上的服務(wù)，這就更加危險(xiǎn)了，因?yàn)樯杂胁簧骶涂赡軐?dǎo)致原有的工作系統(tǒng)出現(xiàn)故障。 但是，就像業(yè)務(wù)需求在不斷變化一樣，運(yùn)維環(huán)境也在不斷變化。 比如搬遷IDC，就是最常見的“折??騰”。 我們可以編寫很多運(yùn)維管理的工具，試圖將這些工作“自動(dòng)化”。 然而，業(yè)務(wù)需求不斷“折騰”，在一些“開發(fā)運(yùn)維分離”的團(tuán)隊(duì)中，開發(fā)人員并不是很關(guān)心運(yùn)維工具的開發(fā)，因?yàn)樗麄円呀?jīng)被市場(chǎng)和業(yè)務(wù)人員逼迫不斷加班，只求功能盡快上線。 由于負(fù)載均衡的需要，由此產(chǎn)生的大量服務(wù)器端軟件和內(nèi)部工作量與集群中龐大的服務(wù)器數(shù)量有關(guān)，因此是服務(wù)器運(yùn)維和開發(fā)困難的最直接體現(xiàn)端系統(tǒng)。

如何開發(fā)一個(gè)運(yùn)維友好的服務(wù)端系統(tǒng)

為了讓服務(wù)器端系統(tǒng)運(yùn)行良好，我們或許應(yīng)該采取一些開發(fā)措施服務(wù)器運(yùn)維，而不是簡(jiǎn)單地依靠所謂的“運(yùn)維”甚至更不可靠的“管理”方式來減少錯(cuò)誤和故障。

第一個(gè)可以作為參考的想法是“構(gòu)建具有性能靈活性的系統(tǒng)”。 所以，性能彈性，最簡(jiǎn)單的說就是我們的服務(wù)器進(jìn)程不需要復(fù)雜的配置文件，不需要運(yùn)維操作，就可以運(yùn)行在各種性能環(huán)境中。 除了監(jiān)控機(jī)器的IP地址、內(nèi)存大小等最簡(jiǎn)單的自配置功能外，更重要的是我們對(duì)資源管理思想的提升。 因?yàn)橐粋€(gè)系統(tǒng)要解決的問題可能比較復(fù)雜，需要用到的資源也會(huì)很復(fù)雜。 比如我們需要用顯存來緩沖沒收的網(wǎng)絡(luò)包，還需要用顯存來存儲(chǔ)用戶會(huì)話數(shù)據(jù)等等。 如果我們只是提出配置這么一塊顯存，各種顯存容量的配置就會(huì)有很多。 但是，我們可以通過構(gòu)建業(yè)務(wù)表示來簡(jiǎn)化這些資源模型。 例如，對(duì)于一個(gè)在線交互系統(tǒng)，我們可以將資源管理的單位定義為“會(huì)話”——每個(gè)會(huì)話代表一個(gè)“并發(fā)”服務(wù)，每個(gè)會(huì)話使用多少資源是我們可以設(shè)計(jì)的，然后我們?nèi)リP(guān)注管理“會(huì)話”總數(shù)以避免資源泄漏。 實(shí)際上，這些“會(huì)話”在不同的業(yè)務(wù)系統(tǒng)中可能有不同的概念和作用。 幸運(yùn)的是，我們還可以利用面向?qū)ο蟮乃枷?，將此類?huì)話及其相關(guān)數(shù)據(jù)用類和對(duì)象進(jìn)行封裝。 這樣，我們?cè)谝?guī)劃性能的時(shí)候，就不用在程序中四處尋找用到“資源”的機(jī)器配置，而只需要抓取一個(gè)關(guān)鍵變量即可。 更重要的是，我們可以對(duì)“”等關(guān)鍵指標(biāo)采用“池化”的管理策略，將這些對(duì)象的使用變成需要“申請(qǐng)/返回”的機(jī)制，從而摒棄“分配”一個(gè)的做法大量資源是根據(jù)實(shí)際需要分配資源。 由于“池”的限制，當(dāng)資源達(dá)到上限時(shí)，拒絕進(jìn)一步的服務(wù)請(qǐng)求，解決一些過載問題，同時(shí)避免資源漏洞。 保護(hù)的問題。 而且，在某些環(huán)境下，我們還可以讓這個(gè)“資源池”更加智能化和彈性化。 例如，當(dāng)請(qǐng)求壓力接近上限閾值時(shí)，我們可以開始一些擴(kuò)容或者上報(bào)工作，而不是簡(jiǎn)單的拒絕服務(wù)。 或者我們可以定期查詢“已申請(qǐng)”資源的處理情況。 如果發(fā)現(xiàn)資源占用時(shí)間過長(zhǎng)，我們可以清除那些服務(wù)請(qǐng)求，這樣對(duì)于自恢復(fù)服務(wù)有一定的靈活性。 如果構(gòu)建具有“資源彈性”的系統(tǒng)能力，這樣的進(jìn)程可以以最小的配置實(shí)現(xiàn)自我管理和運(yùn)行。 從根本上降低了運(yùn)維工作的復(fù)雜度，同時(shí)也增加了環(huán)境變化對(duì)系統(tǒng)的影響。 同時(shí)，良好表征的功能代碼對(duì)于代碼的維護(hù)和開發(fā)也非常有利，可以說是一舉多得。

第二個(gè)想法是“在功能容器下運(yùn)行”。 在某個(gè)項(xiàng)目實(shí)踐中，我看到了某個(gè)系統(tǒng)，它的每一個(gè)流程都包含了整個(gè)系統(tǒng)的所有功能代碼。 通過啟動(dòng)時(shí)的命令行參數(shù)，可以指定這個(gè)進(jìn)程需要提供哪些功能。 就運(yùn)維的便利性而言，這個(gè)系統(tǒng)遠(yuǎn)比需要配置部署各種功能來送包的系統(tǒng)簡(jiǎn)單。 而且該服務(wù)器系統(tǒng)還可以以單進(jìn)程全功能的形式進(jìn)行開發(fā)和人工測(cè)試，在開發(fā)效率上具有顯著優(yōu)勢(shì)。 在JSP/技術(shù)的使用中，我們經(jīng)常會(huì)把不同的部署部署到不同的容器（如/Resin等）中運(yùn)行，而沒有完全配置各種容器。 現(xiàn)在仍然有一些系統(tǒng)使用/JS/Lua等腳本語(yǔ)言來編寫主要的業(yè)務(wù)功能。 系統(tǒng)中的流程部署，只要腳本容器（引擎）完成，基本上就是復(fù)制腳本文件。 . 在容器技術(shù)的支持下，我們不僅可以簡(jiǎn)化部署的工作，還可以獲得一些“熱更新”的用處。 對(duì)于基于硬件和流量的運(yùn)維工作，運(yùn)維人員可以集中精力管理“容器”。 例如，它是一個(gè)高度手動(dòng)的 容器。 用戶甚至根本不需要安裝和部署任何軟件。 他們可以直接上傳PHP腳本或類文件來開始提供服務(wù)。 服務(wù)器系統(tǒng)運(yùn)行在容器下，也可以借助容器指定的一些通信規(guī)范進(jìn)行一些手動(dòng)運(yùn)維，比如手動(dòng)擴(kuò)容、縮容、容災(zāi)——容器可以自我發(fā)現(xiàn)運(yùn)行狀態(tài)集群并添加新的運(yùn)行資源，移除故障（如訪問超時(shí)）的運(yùn)行資源。 這也是所謂的 SOA 概念的最常見實(shí)現(xiàn)。 從另一個(gè)角度來說，如果我們有容器的支持，我們?cè)谂渲眠M(jìn)程的時(shí)候就可以簡(jiǎn)化整個(gè)集群中各種關(guān)系的配置，因?yàn)槲覀冎恍枰嬖V容器如何加入一個(gè)目標(biāo)集群，其他的事情都允許容器與其他集群成員協(xié)商配置。 容器不僅提出了統(tǒng)一的功能代碼開發(fā)環(huán)境約束，還規(guī)范了運(yùn)維工作。 這對(duì)于需要經(jīng)常改變服務(wù)內(nèi)容，不斷改變運(yùn)行環(huán)境的項(xiàng)目來說是非常有價(jià)值的。 在WEB開發(fā)領(lǐng)域，容器的概念早已深入人心，因此這類系統(tǒng)應(yīng)用廣泛，運(yùn)維工作可以專業(yè)順利的進(jìn)行，并且在領(lǐng)域沒有網(wǎng)絡(luò)游戲這樣的“行業(yè)標(biāo)準(zhǔn)”，功能容器的概念仍然沒有被很多人接受。 很多人還在埋怨自己為什么要給自己戴上這個(gè)“枷鎖”，殊不知自由總是在束縛下行走。

最后說一下各種運(yùn)維工具，不管是Chef還是各種非通用的運(yùn)維部署系統(tǒng)。 如果你只使用操作系統(tǒng)提供的能力，你希望統(tǒng)一管理所有的系統(tǒng)。 難的。 而如果我們?cè)陂_發(fā)的時(shí)候充分考慮到系統(tǒng)的運(yùn)維需求，那么我們可能只實(shí)現(xiàn)一些簡(jiǎn)單的約束，就可以大大提高運(yùn)維工作。 我想這也是所謂受歡迎的原因。 （來源：漢大）