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

【程序員愛配置文件】

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

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

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

分布式系統(tǒng)運維友好性難點

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

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

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

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

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

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

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

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