面向海量服務的設計原則和策略總結
互聯網服務的特點就是面向海量級的用戶，面向海量級的用戶如何提供穩定的服務呢？這里，對這幾年的一些經驗積累和平時接觸的一些理念做一個總結。
一、原則
1.Web服務的CAP原理
CAP指的是三個要素：一致性(Consistency)、可用性(Availability)、分區容忍性(Partition tolerance)。CAP原理指的是這三個要素最多只能同時實現兩點，不可能三者兼顧，對于海量級服務，一般這是一條常記心中的基準準則。
如下是《Web服務的CAP 》關于CAP的定義：
一致性：可以參考數據庫的一致性。每次信息的讀取都需要反映最新更新后的數據。
可用性：高可用性意味著每一次請求都可以成功完成并受到響應數據
分區寬容度：這個是容錯機制的要求。一個服務需要在局部出錯的情況下，沒有出錯的那部分被復制的數據分區仍然可以支持部分服務的操作，可以簡單的理解為可以很容易的在線增減機器以達到更高的擴展性，即所謂的橫向擴展能力。
面向海量級的分布式服務設計，基本上分區容忍性(Partition tolerance)是第一要素，因此根據業務的情況，我們需要在一致性(Consistency)和可用性(Availability)之間做取舍。對于一些業務，譬如支付寶或財付通，一致性會是第一考慮要素，即使是延遲的不一致也是不可接受的，這種時候只能犧牲可用性以保證一致性。對于一些應用，譬如淘寶或拍拍交易中的評價信息，一般用戶是可以接受延遲的一致性，這種時候可以優先考慮可用性，而用最終一致性來保證數據一致，譬如通過某種對帳機制。對于一些應用，甚至一致性都并非要求，只需要保證差不多一致性即可，譬如Q-zone中的農場游戲中的偷菜。
根據我們應用的業務需求，選擇合適的一致性級別，以更好地保證系統的分區容忍性和可用性。
2.柔性可用
面向海量級的分布式服務設計，我們要意識到，一切都是不可靠的，在不可靠的環境的環境中構建可靠的應用，其中最重要的一點就是保持系統的柔性。
1)不可靠的環境
我們可能已經見慣一個遠程服務提供不了服務了，運行一段時間后WebServer突然不響應了，數據庫隨著負載的不斷增加再放上一條SQL語句就會垮掉。但是，硬盤壞掉、電源斷掉、光纖中斷，聽起來似乎多么不可思議，然而，當一個海量服務需要成千上萬臺服務器、需要部署全國各地的數十個數據中心、需要橫跨電信網通教育網三大網絡的時候，一切聽起來不可思議的事情會變成常態。一切都是不可靠的，唯一可靠的就是不可靠本身。
2)劃分服務級別
我們應該意識到，在這種不可靠的環境中提供完美的服務，本身就是一個神話，即使不是說完全不可能，但至少是代價高昂的，因此，當某些問題發生(環境變地不可靠的時候)，我們必須做出取舍，選擇為用戶提供用戶最關心的服務，這種服務雖然聽起來是有損的(至少是不完美的)，但卻能在一定程度上滿足用戶大部分的需求。譬如，當網絡帶寬無法為用戶提供最好的體驗而擴容又不是短期可以達到的時候，選擇降低一些非重要服務的體驗是一個比較好的選擇。
在面向海量互聯網的設計當中，對服務進行分級，當系統變地不可靠的時候，優先提供重要優先級的服務。
3)盡快響應
互聯網用戶的耐心是非常有限的，如果一個頁面需要3秒以上才能看到，也許大部分用戶的第一選擇就是關掉瀏覽器。在構建柔性可用的互聯網服務的時候，響應時間大部分情況下都是需要最優先考慮。還是一句話，環境是不可靠的，當我們無法盡快從遠程服務獲得數據、當數據庫已經慢如蝸牛，也許當后臺還在吭哧吭哧干活的時候，用戶老早已經關閉了頁面，處理返回的數據也只是在浪費表情，面向互聯網用戶，響應就是生命。
二、策略
如何讓我們的應用提供更高質量的服務呢，這里是一些在日常開發使用到或者觀察到的一些策略的總結：
1.數據sharding
海量服務相應也意味著海量的用戶和海量的用戶數據，大家都知道，即使是再強大的數據庫、再強大服務器，在單表上億規模的數據足夠讓一條簡單的SQL語句慢如蝸牛(甚至于在百萬、千萬級別上，如果沒有采取合適的策略，都無法滿足服務要求)，一般處理這種千萬上億級數據的大家基本上都會想到的就是數據sharding，將數據切割成多個數據集，分散到多個數據庫的多個表中(譬如將用戶數據按用戶ID切割成4個數據庫每個數據庫100個表共400個表)，由于每個表數據足夠小可以讓我們的SQL語句快速地執行。而至于如何切割，實際上跟具體的業務策略有關系。
當然，我們要認識到，這種數據sharding并非全無代價的，這也意味著我們需要做出一些折中，譬如可能很難進行跨表數據集的查詢、聯表和排序也變地非常困難、同時數據庫client程序編寫也會變地更加復雜、保證數據一致性在某些情況下會變地困難重重。sharding并非萬能藥，選擇是否sharding、如何sharding、為sharding如何換用一個近似的業務描述方式，這是業務設計需要仔細考慮的問題。
2.Cache
經驗會告訴我們，基本上大部分系統的瓶頸會集中在IO/數據庫上，常識也告訴我們，網絡和內存的速度比IO/數據庫會提升甚至不止一個數量級。面向海量服務，Cache基本上是一個必選項，分布式Cache更是一個不二選擇，根據我們的需要，我們可以選擇memcached(非持久化)、memcachedb/Tokyo Tyrant(持久化)，甚至構建自己的cache平臺。
在使用Cache上，下面是需要仔細考慮的點：
選擇合適的Cache分布算法，基本上我們會發現使用取模方式決定Cache位置是不可靠的，因為壞節點的摘除或者節點擴量會讓我們的Cache命中率在短時間內下降到冰點，甚至會導致系統在短期內的負載迅速增長甚至于崩潰，選擇一種合適的分布算法非常重要，譬如穩定的一致性哈希
Cache管理：為每個應用配置獨立的Cache通常不是一個好主意，我們可以選擇在大量的機器上，只要有空閑內存，則運行Cache實例，將Cache實例分成多個組，每個組就是一個完整的Cache池，而多個應用共享一個Cache池
合理的序列化格式：使用緊湊的序列化方案存儲Cache數據，盡量少存儲冗余數據，一方面可以最大能力地榨取Cache的存儲利用率，另一方面，可以更方便地進行容量預估。此外，不可避免地，隨著業務的升級，存儲的數據的格式有可能會變更，序列化也需要注意向上兼容的問題，讓新格式的客戶端能夠支持舊的數據格式。
容量估算：在開始運行之前，先為自己的應用可能使用到的容量做一個容量預估，以合理地分配合適的Cache池，同時為可能的容量擴充提供參考。
容量監控：Cache命中率怎么樣，Cache的存儲飽和度怎么樣，Client的Socket連接數等等，對這些數據的采集和監控，將為業務的調整和容量的擴充提供了數據支持。
選擇在哪層上進行Cache，譬如數據層Cache、應用層Cache和Web層Cache，越靠近數據，Cache的通用性越高，越容易保持Cache數據的一致性，但相應的處理流程也越長，而越靠近用戶，Cache的通用性越差，越難保證Cache數據的一致性，但是響應也越快，根據業務的特點，選擇合適的Cache層是非常重要的。一般而言，我們會選擇將粗粒度、極少變更、數據對用戶不敏感(即可以一定程度上接受誤差)、并且非針對用戶級的數據，在最靠近用戶的層面上Cache，譬如圖片Cache、TOP X等數據;而將一些細粒度、變更相對頻繁、用戶相對敏感的數據或者是針對用戶級的數據放在靠近數據的一段，譬如用戶的Profile、關系鏈等。
3.服務集群
面向海量服務，系統的橫向擴展基本上是第一要素，在我的經驗和經歷中，服務集群需要考慮如下因素：
分層：合理地對系統進行分層，將系統資源要求不同的部分進行合理地邏輯/物理分層，一般對于簡單業務，Client層、WebServer層和DB層已經足夠，對于更復雜業務，可能要切分成Client層、WebServer層、業務層、數據訪問層(業務層和數據訪問層一般傾向于在物理上處于同一層)、數據存儲層(DB)，太多的分層會導致處理流程變長，但相應系統地靈活性和部署性會更強。
功能細粒度化：將功能進行細粒度的劃分，并使用獨立的進程部署，一方面能更有利于錯誤的隔離，另一方面在功能變更的時候避免一個功能對其他功能產生影響
快慢分離/按優先級分離部署：不同的服務具備不同的特點，有些服務訪問速度快有些訪問速度慢，訪問慢的服務可能會阻塞住導致整個服務不可用，有些服務優先級別比較高(譬如打款之類的用戶比較關心的服務)，有些服務優先級別低(譬如日志記錄、發郵件之類)，優先級別低的服務可能會阻塞住優先級別高的服務，在部署上將不同特點的應用分離部署避免相互影響是一個常用的做法
按數據集部署：如果每一層都允許對下一層所有的服務接口進行訪問，將存在幾個嚴重的缺陷，一是隨著部署服務的增長，會發現下一層必須允許數量非常龐大的Socket連接進來，二是我們可能必須把不同的服務部署在不同的數據中心(DC)的不同機房上，即便是上G的光纖專線，機房間的穿梭流量也會變地不可接受，三是每個服務節點都是全數據容量接入，并不利于做一些有效的內部優化機制，四是只能采用代碼級控制的灰度發布和部署。當部署規模達到一定數量級的時候，按數據集橫向切割成多組服務集合，每組服務集合只為特定的數據集服務，在部署上，每組服務集合可以部署在獨立的相同的數據中心(DC)上。
無狀態：狀態將為系統的橫向擴容帶來無窮盡的煩惱。對于狀態信息比少的情況，可以選擇將全部狀態信息放在請求發器端，對于狀態信息比較多的情況，可以考慮維持一個統一的Session中心。
選擇合適的負載均衡器和負載均衡策略：譬如在L4上負載均衡的LVS、L7上負載均衡的Nginx、甚至是專用的負載均衡硬件F5(L4)，對于在L7上工作的負載均衡器，選擇合適的負載均衡策略也非常重要，一般讓用戶總是負載均衡到同一臺后端Server是一個很好的方式
4.灰度發布
當系統的用戶增長到一定的規模，一個小小功能的發布也會產生非常大的影響，這個時候，將功能先對一小部分用戶開放，并慢慢擴展到全量用戶是一個穩妥的做法，使用灰度化的發布將避免功能的BUG產生大面積的錯誤。如下是一些常見的灰度控制策略：
白名單控制：只有白名單上的用戶才允許訪問，一般用于全新功能Alpha階段，只向被邀請的用戶開放功能
準入門檻控制：常見的譬如gmail出來之初的邀請碼、QQ農場開始階段的X級的黃鉆準入，同樣一般用于新功能的Beta階段，慢慢通過一步一步降低門檻，避免在開始之處由于系統可能潛在的問題或者容量無法支撐導致整個系統的崩潰。
按數據集開放：一般常用于成熟的功能的新功能開發，避免新功能的錯誤產生大面積的影響
5.設計自己的通信協議：二進制協議、向上/下兼容
隨著系統的穩定運行訪問量的上漲，慢慢會發現，一些看起來工作良好的協議性能變地不可接受，譬如基于xml的協議xml-rpc，將會發現xml解析和包體的增大變地不可接受，即便是接近于二進制的hessian協議，多出來的字段描述信息(按我的理解，hessian協議是類似于map結構的，包含字段的名稱信息)和基于文本的http頭將會使協議效率變地低下。也許，在開始合適的時候而不是到最后不得已的時候，去設計一個良好的基于二進制的高效的內部通信協議是一個好的方式。按我的經驗，設計自己的通信協議需要注意如下幾點：
協議緊湊性，否則早晚你會為你浪費的空間痛心疾首
協議擴展性，早晚會發現舊的協議格式不能適應新的業務需求，而在早期預留變地非常地重要，基本上，參見一些常用的規范，魔術數(對于無效果的請求可以迅速丟棄)、協議版本信息、協議頭、協議Body、每個部分(包括結構體信息中的對象)的長度這些信息是不能省的
向下兼容和向上兼容：但功能被大規模地調用的時候，發布一個新的版本，讓所有的client同時升級基本上是不可接受的，因此在設計之處就需要考慮好兼容性的問題
6.設計自己的Application Server
事情進行到需要自己設計通信協議，自己構建Application Server也變地順理成章，下面是在自己開發Application Server的時候需要處理的常見的問題：
過載保護：當系統的某個部件出現問題的時候，最常見的情況是整個系統的負載出現爆炸性的增長而導致雪崩效應，在設計application server的時候，必須注意進行系統的過載保護，當請求可以預期無法處理的時候(譬如排隊滿載或者排隊時間過長)，丟棄是一個明智的選擇，TCP的backlog參數是一個典型的范例。
頻率控制：即便是同一系統中的其他應用在調用，一個糟糕的程序可能會將服務的所有資源占完，因此，應用端必須對此做防范措施，頻率控制是其中比較重要的一個
異步化/無響應返回：對于一些業務，只需要保證請求會被處理即可，客戶端并不關心什么時候處理完，只要最終保證處理就行，甚至最終沒有處理也不是很嚴重的事情，譬如郵件，對于這種應用，應快速響應避免占著寶貴的連接資源，而將請求進入異步處理隊列慢慢處理。
自我監控：Application Server本身應該具備自我監控的功能，譬如性能數據采集、為外部提供內部狀態的查詢(譬如排隊情況、處理線程、等待線程)等
預警：譬如當處理變慢、排隊太多、發生請求丟棄的情況、并發請求太多的時候，Application Server應該具備預警的能力以快速地對問題進行處理
模塊化、模塊間松耦合、機制和策略分離：如果不想一下子面對所有的復雜性或不希望在修改小部分而不得不對所有的測試進行回歸的話，模塊化是一個很好的選擇，將問題進行模塊切割，每個模塊保持合理的復雜度，譬如對于這里的Application Server，可以切分成請求接收/管理/響應、協議解析、業務處理、數據采集、監控和預警等等模塊。這里同時要注意塊間使用松耦合的方式交互，譬如，請求接收和業務處理之間則可以使用阻塞隊列通信的方式降低耦合。另外還需要注意的是機制和策略的分離，譬如協議可能會變更、性能采集和告警的方式可能會變化等等，事先的機制和策略分離，策略變更的處理將變地更加簡單。
7.Client
很多應用會作為服務的Client，去調用其他的服務，如下是在做為Client應該注意的一些問題：
服務不可靠：作為Client永遠要記住的一點就是，遠程服務永遠是不可靠的，因此作為Client自己要注意做自我保護，當遠程服務如果無法訪問時，做折中處理
超時保護：還是上面所說的，遠程服務永遠都是不可靠的，永遠也無法預測到遠程什么時候會響應，甚至可能不會響應(譬如遠程主機宕機)，請求方要做好超時保護，譬如對于主機不可達的情況，在linux環境下，有時會讓客戶端等上幾分鐘TCP層才會最終告訴你服務不可到達。
并發/異步：為了提速響應，對于很多可以并行獲取的數據，我們總是應該并行地去獲取，對于一些我們無法控制的同步接口——譬如讀數據庫或同步讀cache——雖然不是很完美，但多線程并行去獲取是一個可用的選擇，而對于服務端都是使用自構建的Application Server，使用異步Client接口至關重要，將請求全部發送出去，使用異步IO設置超時等待返回即可，甚至于更進一步異步anywhere，在將client與application server整合到一塊的時候，請求發送出去之后立即返回，將線程/進程資源歸還，而在請求響應回來符合條件的時候，觸發回調做后續處理。
8.監控和預警
基本上我們會見慣了各種網絡設備或服務器的監控，譬如網絡流量、IO、CPU、內存等監控數據，然而除了這些總體的運行數據，應用的細粒度化的數據也需要被監控，服務的訪問壓力怎么樣、處理速度怎么樣、性能瓶頸在哪里、帶寬主要是被什么應用占、Java虛擬機的CPU占用情況怎么樣、各內存區的內存占用情況如何，這些數據將有利于我們更好的了解系統的運行情況，并對系統的優化和擴容提供數據指導。
除了應用總體監控，特定業務的監控也是一個可選項，譬如定時檢查每個業務的每個具體功能點(url)訪問是否正常、訪問速度如何、頁面訪問速度如何(用戶角度，包括服務響應時間、頁面渲染時間等，即網頁測速)、每個頁面的PV、每個頁面(特別是圖片)每天占用的總帶寬等等。這些數據將為系統預警和優化提供數據上的支持，例如對于圖片，如果我們知道哪些圖片占用的帶寬非常大(不一定是圖片本身比較大，而可能是訪問比較大)，則一個小小的優化會節省大量的網絡帶寬開銷，當然，這些事情對于小規模的訪問是沒有意義的，網絡帶寬開銷節省的成本可能都沒有人力成本高。
除了監控，有效的預警機制也是必不可少，應用是否在很好地提供服務、響應時間是否能夠達到要求、系統容量是否達到一個閥值。有效的預警機制將讓我們盡快地對問題進行處理。
9.配置中心化
當系統錯誤的時候，我們如何盡快地恢復呢，當新增服務節點的時候，如何盡快地讓真個系統感知到呢?當系統膨脹之后，如果每次摘除服務節點或者新增節點都需要修改每臺應用配置，那么配置和系統的維護將變地越來越困難。
配置中心化是一個很好的處理這個問題的方案，將所有配置進行統一地存儲，而當發生變更的時候(摘除問題節點或者擴量增加服務節點或新增服務)，使用一些通知機制讓各應用刷新配置。甚至于，我們可以自動地檢測出問題節點并進行智能化的切換。
三、最后
構建面向海量用戶的服務，可以說是困難重重挑戰重重，一些原則和前人的設計思路可以讓我們獲得一些幫助，但是更大的挑戰會來源于細節部分，按我們技術老大的說法，原則和思路只要看幾本書是個技術人員都會，但決定一個系統架構師能力的，往往卻是對細節的處理能力。因此，在掌握原則和前人的設計思路的基礎上，更深入地挖掘技術的細節，才是面向海量用戶的服務的制勝之道。
【編輯推薦】
