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