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

【程序員愛配置文件】

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

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

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

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

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

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

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

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

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

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

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

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