作者介紹：韓偉，1999年大學實習期加入初創期的網易，成為第30号員工，8年間從程式員開始，曆任項目經理、産品總監。2007年後創業4年，開發過視訊直播社群，及多款頁遊産品。2011年後就職于騰訊遊戲研發部公共技術中心架構規劃組，專注于通用遊戲技術底層的研發。
我們常常會聽說，某個網際網路應用的伺服器端系統多麼牛逼，比如QQ拉、微信拉、淘寶拉。那麼，一個網際網路應用的伺服器端系統，到底牛逼在什麼地方？為什麼海量的使用者通路，會讓一個伺服器端系統變得更複雜？本文就是想從最基本的地方開始，探尋伺服器端系統技術的基礎概念。
當一個網際網路業務獲得大衆歡迎的時候，最顯著碰到的技術問題，就是伺服器非常繁忙。當每天有1000萬個使用者通路你的網站時，無論你使用什麼樣的伺服器硬體，都不可能隻用一台機器就承載的了。是以，在網際網路程式員解決伺服器端問題的時候，必須要考慮如何使用多台伺服器，為同一種網際網路應用提供服務，這就是所謂“分布式系統”的來源。
然而，大量使用者通路同一個網際網路業務，所造成的問題并不簡單。從表面上看，要能滿足很多使用者來自網際網路的請求，最基本的需求就是所謂性能需求：使用者反應網頁打開很慢，或者網遊中的動作很卡等等。而這些對于“服務速度”的要求，實際上包含的部分卻是以下幾個：高吞吐、高并發、低延遲和負載均衡。
高吞吐，意味着你的系統，可以同時承載大量的使用者使用。這裡關注的整個系統能同時服務的使用者數。這個吞吐量肯定是不可能用單台伺服器解決的，是以需要多台伺服器協作，才能達到所需要的吞吐量。而在多台伺服器的協作中，如何才能有效的利用這些伺服器，不緻于其中某一部分伺服器成為瓶頸，進而影響整個系統的處理能力，這就是一個分布式系統，在架構上需要仔細權衡的問題。
高并發是高吞吐的一個延伸需求。當我們在承載海量使用者的時候，我們當然希望每個伺服器都能盡其所能的工作，而不要出現無謂的消耗和等待的情況。然而，軟體系統并不是簡單的設計，就能對同時處理多個任務，做到“盡量多”的處理。很多時候，我們的程式會因為要選擇處理哪個任務，而導緻額外的消耗。這也是分布式系統解決的問題。
低延遲對于人數稀少的服務來說不算什麼問題。然而，如果我們需要在大量使用者通路的時候，也能很快的傳回計算結果，這就要困難的多。因為除了大量使用者通路可能造成請求在排隊外，還有可能因為排隊的長度太長，導緻記憶體耗盡、帶寬占滿等空間性的問題。如果因為排隊失敗而采取重試的政策，則整個延遲會變的更高。是以分布式系統會采用很多請求分揀和分發的做法，盡快的讓更多的伺服器來出來使用者的請求。但是，由于一個數量龐大的分布式系統，必然需要把使用者的請求經過多次的分發，整個延遲可能會因為這些分發和轉交的操作，變得更高，是以分布式系統除了分發請求外，還要盡量想辦法減少分發的層次數，以便讓請求能盡快的得到處理
由于網際網路業務的使用者來自全世界，是以在實體空間上可能來自各種不同延遲的網絡和線路，在時間上也可能來自不同的時區，是以要有效的應對這種使用者來源的複雜性，就需要把多個伺服器部署在不同的空間來提供服務。同時，我們也需要讓同時發生的請求，有效的讓多個不同伺服器承載。所謂的負載均衡，就是分布式系統與生俱來需要完成的功課。
由于分布式系統，幾乎是解決網際網路業務承載量問題，的最基本方法，是以作為一個伺服器端程式員，掌握分布式系統技術就變得異常重要了。然而，分布式系統的問題，并非是學會用幾個架構和使用幾個庫，就能輕易解決的，因為當一個程式在一個電腦上運作，變成了又無數個電腦上同時協同運作，在開發、運維上都會帶來很大的差别。
使用多态伺服器來協同完成計算任務，最簡單的思路就是，讓每個伺服器都能完成全部的請求，然後把請求随機的發給任何一個伺服器處理。最早期的網際網路應用中，DNS輪詢就是這樣的做法：當使用者輸入一個域名試圖通路某個網站，這個域名會被解釋成多個IP位址中的一個，随後這個網站的通路請求，就被發往對應IP的伺服器了，這樣多個伺服器（多個IP位址）就能一起解決處理大量的使用者請求。
然而，單純的請求随機轉發，并不能解決一切問題。比如我們很多網際網路業務，都是需要使用者登入的。在登入某一個伺服器後，使用者會發起多個請求，如果我們把這些請求随機的轉發到不同的伺服器上，那麼使用者登入的狀态就會丢失，造成一些請求處理失敗。簡單的依靠一層服務轉發是不夠的，是以我們會增加一批伺服器，這些伺服器會根據使用者的Cookie，或者使用者的登入憑據，來再次轉發給後面具體處理業務的伺服器。
除了登入的需求外，我們還發現，很多資料是需要資料庫來處理的，而我們的這些資料往往都隻能集中到一個資料庫中，否則在查詢的時候就會丢失其他伺服器上存放的資料結果。是以往往我們還會把資料庫單獨出來成為一批專用的伺服器。
至此，我們就會發現，一個典型的三層結構出現了：接入、邏輯、存儲。然而，這種三層結果，并不就能包醫百病。例如，當我們需要讓使用者線上互動（網遊就是典型） ，那麼分割在不同邏輯伺服器上的線上狀态資料，是無法知道對方的，這樣我們就需要專門做一個類似互動伺服器的專門系統，讓使用者登入的時候，也同時記錄一份資料到它那裡，表明某個使用者登入在某個伺服器上，而所有的互動操作，要先經過這個互動伺服器，才能正确的把消息轉發到目标使用者的伺服器上。
又例如，當我們在使用網上論壇（BBS）系統的時候，我們發的文章，不可能隻寫入一個資料庫裡，因為太多人的閱讀請求會拖死這個資料庫。我們常常會按論壇闆塊來寫入不同的資料庫，又或者是同時寫入多個資料庫。這樣把文章資料分别存放到不同的伺服器上，才能應對大量的操作請求。然而，使用者在讀取文章的時候，就需要有一個專門的程式，去查找具體文章在哪一個伺服器上，這時候我們就要架設一個專門的代理層，把所有的文章請求先轉交給它，由它按照我們預設的存儲計劃，去找對應的資料庫擷取資料。
根據上面的例子來看，分布式系統雖然具有三層典型的結構，但是實際上往往不止有三層，而是根據業務需求，會設計成多個層次的。為了把請求轉交給正确的程序處理，我們而設計很多專門用于轉發請求的程序和伺服器。這些程序我們常常以Proxy或者Router來命名，一個多層結構常常會具備各種各樣的Proxy程序。這些代理程序，很多時候都是通過TCP來連接配接前後兩端。然而，TCP雖然簡單，但是卻會有故障後不容易恢複的問題。而且TCP的網絡程式設計，也是有點複雜的。——是以，人們設計出更好程序間通訊機制：消息隊列。
盡管通過各種Proxy或者Router程序能組建出強大的分布式系統，但是其管理的複雜性也是非常高的。是以人們在分層模式的基礎上，想出了更多的方法，來讓這種分層模式的程式變得更簡單高效的方法。
當我們在編寫伺服器端程式是，我們會明确的知道，大部分的程式，都是會處理同時到達的多個請求的。是以我們不能好像HelloWorld那麼簡單的，從一個簡單的輸入計算出輸出來。因為我們會同時獲得很多個輸入，需要傳回很多個輸出。在這些處理的過程中，往往我們還會碰到需要“等待”或“阻塞”的情況，比如我們的程式要等待資料庫處理結果，等待向另外一個程序請求結果等等……如果我們把請求一個挨着一個的處理，那麼這些空閑的等待時間将白白浪費，造成使用者的響應延時增加，以及整體系統的吞吐量極度下降。
是以在如何同時處理多個請求的問題上，業界有2個典型的方案。一種是多線程，一種是異步。在早期的系統中，多線程或多程序是最常用的技術。這種技術的代碼編寫起來比較簡單，因為每個線程中的代碼都肯定是按先後順序執行的。但是由于同時運作着多個線程，是以你無法保障多個線程之間的代碼的先後順序。這對于需要處理同一個資料的邏輯來說，是一個非常嚴重的問題，最簡單的例子就是顯示某個新聞的閱讀量。兩個++操作同時運作，有可能結果隻加了1，而不是2。是以多線程下，我們常常要加很多資料的鎖，而這些鎖又反過來可能導緻線程的死鎖。
是以異步回調模型在随後比多線程更加流行，除了多線程的死鎖問題外，異步還能解決多線程下，線程反複切換導緻不必要的開銷的問題：每個線程都需要一個獨立的棧空間，在多線程并行運作的時候，這些棧的資料可能需要來回的拷貝，這額外消耗了CPU。同時由于每個線程都需要占用棧空間，是以在大量線程存在的時候，記憶體的消耗也是巨大的。而異步回調模型則能很好的解決這些問題，不過異步回調更像是“手工版”的并行處理，需要開發者自己去實作如何“并行”的問題。
異步回調基于非阻塞的I/O操作（網絡和檔案），這樣我們就不用在調用讀寫函數的時候“卡”在那一句函數調用，而是立刻傳回“有無資料”的結果。而Linux的epoll技術，則利用底層核心的機制，讓我們可以快速的“查找”到有資料可以讀寫的連接配接\檔案。由于每個操作都是非阻塞的，是以我們的程式可以隻用一個程序，就處理大量并發的請求。因為隻有一個程序，是以所有的資料處理，其順序都是固定的，不可能出現多線程中，兩個函數的語句交錯執行的情況，是以也不需要各種“鎖”。從這個角度看，異步非阻塞的技術，是大大簡化了開發的過程。由于隻有一個線程，也不需要有線程切換之類的開銷，是以異步非阻塞成為很多對吞吐量、并發有較高要求的系統首選。
在網際網路服務中，大部分的使用者互動，都是需要立刻傳回結果的，是以對于延遲有一定的要求。而類似網絡遊戲之類服務，延遲更是要求縮短到幾十毫秒以内。是以為了降低延遲，緩沖是網際網路服務中最常見的技術之一。
早期的WEB系統中，如果每個HTTP請求的處理，都去資料庫（MySQL）讀寫一次，那麼資料庫很快就會因為連接配接數占滿而停止響應。因為一般的資料庫，支援的連接配接數都隻有幾百，而WEB的應用的并發請求，輕松能到幾千。這也是很多設計不良的網站人一多就卡死的最直接原因。為了盡量減少對資料庫的連接配接和通路，人們設計了很多緩沖系統——把從資料庫中查詢的結果存放到更快的設施上，如果沒有相關聯的修改，就直接從這裡讀。
最典型的WEB應用緩沖系統是Memcache。由于PHP本身的線程結構，是不帶狀态的。早期PHP本身甚至連操作“堆”記憶體的方法都沒有，是以那些持久的狀态，就一定要存放到另外一個程序裡。而Memcache就是一個簡單可靠的存放臨時狀态的開源軟體。很多PHP應用現在的處理邏輯，都是先從資料庫讀取資料，然後寫入Memcache；當下次請求來的時候，先嘗試從Memcache裡面讀取資料，這樣就有可能大大減少對資料庫的通路。
然而Memcache本身是一個獨立的伺服器程序，這個程序自身并不帶特别的叢集功能。也就是說這些Memcache程序，并不能直接組建成一個統一的叢集。如果一個Memcache不夠用，我們就要手工用代碼去配置設定，哪些資料應該去哪個Memcache程序。——這對于真正的大型分布式網站來說，管理一個這樣的緩沖系統，是一個很繁瑣的工作。
是以人們開始考慮設計一些更高效的緩沖系統：從性能上來說，Memcache的每筆請求，都要經過網絡傳輸，才能去拉取記憶體中的資料。這無疑是有一點浪費的，因為請求者本身的記憶體，也是可以存放資料的。——這就是促成了很多利用請求方記憶體的緩沖算法和技術，其中最簡單的就是使用LRU算法，把資料放在一個哈希表結構的堆記憶體中。
而Memcache的不具備叢集功能，也是一個使用者的痛點。于是很多人開始設計，如何讓資料緩存分不到不同的機器上。最簡單的思路是所謂讀寫分離，也就是緩存每次寫，都寫到多個緩沖程序上記錄，而讀則可以随機讀任何一個程序。在業務資料有明顯的讀寫不平衡差距上，效果是非常好的。
然而，并不是所有的業務都能簡單的用讀寫分離來解決問題，比如一些線上互動的網際網路業務，比如社群、遊戲。這些業務的資料讀寫頻率并沒很大的差異，而且也要求很高的延遲。是以人們又再想辦法，把本地記憶體和遠端程序的記憶體緩存結合起來使用，讓資料具備兩級緩存。同時，一個資料不在同時的複制存在所有的緩存程序上，而是按一定規律分布在多個程序上。——這種分布規律使用的算法，最流行的就是所謂“一緻性哈希”。這種算法的好處是，當某一個程序失效挂掉，不需要把整個叢集中所有的緩存資料，都重新修改一次位置。你可以想象一下，如果我們的資料緩存分布，是用簡單的以資料的ID對程序數取模，那麼一旦程序數變化，每個資料存放的程序位置都可能變化，這對于伺服器的故障容忍是不利的。
Orcale公司旗下有一款叫Coherence的産品，是在緩存系統上設計比較好的。這個産品是一個商業産品，支援利用本地記憶體緩存和遠端程序緩存協作。叢集程序是完全自管理的，還支援在資料緩存所在程序，進行使用者定義的計算（處理器功能），這就不僅僅是緩存了，還是一個分布式的計算系統。
相信CAP理論大家已經耳熟能詳，然而在互聯發展的早期，大家都還在使用MySQL的時候，如何讓資料庫存放更多的資料，承載更多的連接配接，很多團隊都是絞盡腦汁。甚至于有很多業務，主要的資料存儲方式是檔案，資料庫反而變成是輔助的設施了。
然而，當NoSQL興起，大家突然發現，其實很多網際網路業務，其資料格式是如此的簡單，很多時候根部不需要關系型資料庫那種複雜的表格。對于索引的要求往往也隻是根據主索引搜尋。而更複雜的全文搜尋，本身資料庫也做不到。是以現在相當多的高并發的網際網路業務，首選NoSQL來做存儲設施。最早的NoSQL資料庫有MangoDB等，現在最流行的似乎就是Redis了。甚至有些團隊，把Redis也當成緩沖系統的一部分，實際上也是認可Redis的性能優勢。
NoSQL除了更快、承載量更大以外，更重要的特點是，這種資料存儲方式，隻能按照一條索引來檢索和寫入。這樣的需求限制，帶來了分布上的好處，我們可以按這條主索引，來定義資料存放的程序（伺服器）。這樣一個資料庫的資料，就能很友善的存放在不同的伺服器上。在分布式系統的必然趨勢下，資料存儲層終于也找到了分布的方法。
分布式系統并不是簡單的把一堆伺服器一起運作起來就能滿足需求的。對比單機或少量伺服器的叢集，有一些特别需要解決的問題等待着我們。
所謂分布式系統，肯定就不是隻有一台伺服器。假設一台伺服器的平均故障時間是1%，那麼當你有100台伺服器的時候，那就幾乎總有一台是在故障的。雖然這個比方不一定很準确，但是，當你的系統所涉及的硬體越來越多，硬體的故障也會從偶然事件變成一個必然事件。一般我們在寫功能代碼的時候，是不會考慮到硬體故障的時候應該怎麼辦的。而如果在編寫分布式系統的時候，就一定需要面對這個問題了。否則，很可能隻有一台伺服器出故障，整個數百台伺服器的叢集都工作不正常了。
除了伺服器自己的記憶體、硬碟等故障，伺服器之間的網絡線路故障更加常見。而且這種故障還有可能是偶發的，或者是會自動恢複的。面對這種問題，如果隻是簡單的把“出現故障”的機器剔除出去，那還是不夠的。因為網絡可能過一會兒就又恢複了，而你的叢集可能因為這一下的臨時故障，丢失了過半的處理能力。
如何讓分布式系統，在各種可能随時出現故障的情況下，盡量的自動維護和維持對外服務，成為了編寫程式就要考慮的問題。由于要考慮到這種故障的情況，是以我們在設計架構的時候，也要有意識的預設一些備援、自我維護的功能。這些都不是産品上的業務需求，完全就是技術上的功能需求。能否在這方面提出對的需求，然後正确的實作，是伺服器端程式員最重要的職責之一。
在分布式系統的叢集，包含了很多個伺服器，當這樣一個叢集的硬體承載能力到達極限的時候，最自然的想法就是增加更多的硬體。然而，一個軟體系統不是那麼容易就可以通過“增加”硬體來提高承載性能的。因為軟體在多個伺服器上的工作，是需要有複雜細緻的協調工作。在對一個叢集擴容的時候，我們往往會要停掉整個叢集的服務，然後修改各種配置，最後才能重新啟動一個加入了新的伺服器的叢集。
由于在每個伺服器的記憶體裡，都可能會有一些使用者使用的資料，是以如果冒然在運作的時候，就試圖修改叢集中提供服務的配置，很可能會造成記憶體資料的丢失和錯誤。是以，運作時擴容在對無狀态的服務上，是比較容易的，比如增加一些Web伺服器。但如果是在有狀态的服務上，比如網絡遊戲，幾乎是不可能進行簡單的運作時擴容的。
分布式叢集除了擴容，還有縮容的需求。當使用者人數下降，伺服器硬體資源出現空閑的時候，我們往往需要這些空閑的資源能利用起來，放到另外一些新的服務叢集裡去。縮容和叢集中有故障需要容災有一定類似之處，差別是縮容的時間點和目标是可預期的。
由于分布式叢集中的擴容、縮容，以及希望盡量能線上操作，這導緻了非常複雜的技術問題需要處理，比如叢集中互相關聯的配置如何正确高效的修改、如何對有狀态的程序進行操作、如何在擴容縮容的過程中保證叢集中節點之間通信的正常。作為伺服器端程式員，會需要花費大量的經曆，來對多個程序的叢集狀态變化，造成的一系列問題進行專門的開發。
現在都流行用靈活開發模式中的“疊代”，來表示一個服務不斷的更新程式，滿足新的需求，修正BUG。如果我們僅僅管理一台伺服器，那麼更新這一台伺服器上的程式，是非常簡單的：隻要把軟體包拷貝過去，然後修改下配置就好。但是如果你要對成百上千的伺服器去做同樣的操作，就不可能每台伺服器登入上去處理。
伺服器端的程式批量安裝部署工具，是每個分布式系統開發者都需要的。然而，我們的安裝工作除了拷貝二進制檔案和配置檔案外，還會有很多其他的操作。比如打開防火牆、建立共享記憶體檔案、修改資料庫表結構、改寫一些資料檔案等等……甚至有一些還要在伺服器上安裝新的軟體。
如果我們在開發伺服器端程式的時候，就考慮到軟體更新、版本更新的問題，那麼我們對于配置檔案、指令行參數、系統變量的使用，就會預先做一定的規劃，這能讓安裝部署的工具運作更快，可靠性更高。
除了安裝部署的過程，還有一個重要的問題，就是不同版本間資料的問題。我們在更新版本的時候，舊版本程式生成的一些持久化資料，一般都是舊的資料格式的；而我們更新版本中如果涉及修改了資料格式，比如資料表結果，那麼這些舊格式的資料，都要轉換改寫成新版本的資料格式才行。這導緻了我們在設計資料結構的時候，就要考慮清楚這些表格的結構，是用最簡單直接的表達方式，來讓将來的修改更簡單；還是一早就預計到修改的範圍，專門預設一些字段，或者使用其他形式存放資料。
除了持久化資料以外，如果存在用戶端程式（如受擊APP），這些用戶端程式的更新往往不能和伺服器同步，如果更新的内容包含了通信協定的修改，這就造成了我們必須為不同的版本部署不同的伺服器端系統的問題。為了避免同時維護多套伺服器，我們在軟體開發的時候，往往傾向于所謂“版本相容”的協定定義方式。而怎樣設計的協定才能有很好的相容性，又是伺服器端程式需要仔細考慮的問題。
一般來說，分布式系統的日志資料，都是被集中到一起，然後統一進行統計的。然而，當叢集的規模到一定程度的時候，這些日志的資料量會變得非常恐怖。很多時候，統計一天的日志量，要消耗計算機運作一天以上的時間。是以，日志統計這項工作，也變成一門非常專業的活動。
經典的分布式統計模型，有Google的Map Reduce模型。這種模型既有靈活性，也能利用大量伺服器進行統計工作。但是缺點是易用性往往不夠好，因為這些資料的統計和我們常見的SQL資料表統計有非常大的差異，是以我們最後還是常常把資料丢到MySQL裡面去做更細層面的統計。
由于分布式系統日志數量的龐大，以及日志複雜程度的提高。我們變得必須要掌握類似Map Reduce技術，才能真正的對分布式系統進行資料統計。而且我們還需要想辦法提高統計工作的工作效率。