一 提供海量服務時面對的場景

場景1:如何令黃村機房的TWS機器訪問黃村機房的APP服務，避免TWS跨機房呼叫永豐機房的APP機器？

場景2:DB和Redis如何實現快慢分離，讀寫分離，加速讀取速度，改善使用者體驗？

場景3:如何實現單節點錯誤不影響全域性服務，防止單點失效造成全域性服務掛掉？

場景4:如何實現使用者暴增或業務增加導致的機器負載過高效能下降問題？

二 SET模型是什麼

SET模型是在系統設計過程中，根據業務特徵為進行規模化擴容或部署而建立的基礎資源模型，一種工程化、規模化裝置容量建設單位。SET模型的核心是使用者模型、容量模型，其主要有以下三個特性：

1 高度標準化：充分考慮各種不同的環境以及場景，綜合成本、效率多個方面的要求。

2 高度規格化：充分考慮適用環境的一些要求，提供有限種規格。

3 高度模組化：強調的是麻雀雖小五臟俱全

三 SET模型能做什麼

3.1 有效防止故障擴散、單點失效

利用SET思想將一個服務按使用者範圍分成不同的小單元，每個小單元(SET)具備全部業務服務能力，當一個SET發生故障時候，隻影響這一小部分使用者從實現到有效防止故障擴散。

在帶有容錯機制的SET架構中，在SET之間增加容錯處理，當一個SET發生故障時，使用類似一致性雜湊的演算法，呼叫方可以自動切換到下一個SET來儲存，並且將新的位置記錄在index上以實現高效容錯。

3.2 實現海量服務的高效運營

SET模組就像一個集裝箱，把各模組標準化、模組化、規模化，它為海量服務運營，特別是裝置管理、網路架構，提供了巨集觀運營支撐框架，從而極大提高了海量服務運營效率。

以電商的SET模型為例，從接入層開始，資料開始sticky，按訂單號路由，即按單號分SET，同一個SET儘可能在一個IDC 裡，減少模組間呼叫的耗時，在同一個SET內，邏輯層任何一臺機器，呼叫方可實時摘除，如果是資料層發生故障，先在接入層，把新產生的訂單號遮蔽有故障對應的SET編號，比如，SET1 資料庫出現故障，為了避免在故障的SET1 上繼續產生新的支付請求，在訂單生成器直接跳過SET1的單號規則，把新請求匯入其它SET。只有未完成的訂單會提示故障，稍後恢復阻止了故障引發的進一步惡化。在故障DB上的資料，通過備機與業務邏輯層的資料核對，完成資料一致性的修復。

3.3 應對使用者及業務增加帶來的服務壓力

使用SET模型可以實現服務的動態伸縮，適應業務的增長。在微信手Q的後臺服務框架中，相應的TWS請求APP服務時，我們使用SET模型服務以實現壓力均分、同機房接入、動態增減APP伺服器以實現業務變更需要、使用者增長需要。

3.4 實現快慢分離、讀寫分離

使用SET模型可以方便的管理服務資源，有效實現服務的快慢分離，避免輕量級服務與重量級服務需求雜糅請求到同一服務點，高效避免了請求擁塞和拒絕服務的發生。

使用SET模型還可以做到讀寫分離，對DB或Redis的讀寫實施分離，以實現讀寫互不干擾、提高海量讀取服務速度與質量的目標。

3.5 實際場景分享（微信和手Q如何使用SET模型容災以確保高可用性）

首先是SET標準化。SET是標準業務部署模組，接入層、邏輯層和儲存層標準化成不同的SET。

每個SET內都有固定數量的伺服器和標準服務容量。譬如，上海XX接入SET設計容量XXX萬用戶，當前使用者數為XXX萬，離警戒水位還有XX%，XX小時後可進入擴容點。

SET都具有自動化部署能力，幾百臺伺服器的SET部署時間小於10分鐘。SET按單元分佈在不同城市之間。每個重點城市都會部署許多套接入SET，邏輯SET和儲存SET。

第三，SET間、城市間、區域間都具備全網排程能力。使用者到接入SET的排程通過GLBS來切換，譬如接入SET會有許多個VIP，通過域名服務變更VIP就可以把使用者請求從天津切到上海。

接入SET到邏輯SET，或邏輯SET到儲存SET的訪問則通過內部名字服務系統來切換。這樣當任何一個IDC或某城市出現問題時，運維人員通過排程可以在幾分鐘內把流量切到正常的SET，甚至可以通過排程系統做到自動化切換。

第四，儲存層的多地同步。儲存層會在三地以上部署多套，譬如華南、華中和華北各部署一套儲存SET。有寫請求時先寫華南SET，寫成功後通過同步中心把資料同步到華中和華北SET，通過最終一致性保證資料儲存在多地儲存。資料在三地同步最長時間才幾千毫秒，因此使用者對資料的不一致基本無感知。

四 應用SET模型到實際專案

以【金手指專案】為例，本節將對上述模型應用進行列舉介紹，並回答開始的四個問題

下圖是專案整體的SET服務配置

4.1 TWS訪問相同機房APP服務問題

使用SET模型服務可以很簡單的實現同機房的服務呼叫，防止跨地域呼叫帶來的各種問題，下圖是IDC的APP服務機的SET配置

圖中人為的將不同機房的機器進行SET劃分，將APP機器劃分為黃村、永豐、灰度機三個集合，對應的TWS機器也進行相應劃分，如下圖：

如此即可將不同機房的TWS對應不同機房的APP以實現服務呼叫，即TWS的SET0集合的黃村機器呼叫APP的SET0集合的黃村機器；TWS的SET1集合的永豐機器呼叫APP的SET1集合的永豐機器；TWS灰度機訪問APP灰度機。下面兩張圖分別是機房的配置情況及同機房TWS訪問相同位置APP的模型：

目前只有在異常情況或測試情況下才會配置TWS跨機房訪問APP。

4.2 讀寫分離

應對DB、Redis的讀寫分離問題，可以將APP服務機劃分為DB、Redis讀訪問機和寫訪問機兩個服務組。

【金手指專案】中我們需要對DB進行讀取和非讀取劃分，因此我們將APP劃分為兩組：DB訪問組、DB隔離組，如下圖：

上圖所示APP機器無DB讀取許可權，僅用於接收TWS使用者獲取已生成資料的請求；

上圖所示APP機器有DB讀取許可權，用於接收管理端、Daemon端的生成規則關鍵詞請求，該請求需要訪問資料庫獲取黑名單、規則詳情等資訊，並生成規則下關鍵詞以儲存或返回管理端。

上述DB許可權不同的服務被被調程式分別呼叫以實現相應服務，將兩個許可權組的機器再進行地區SET劃分：SET0是黃村機房機器，SET1是永豐機房機器，SET2是灰度機，以實現區域隔離，加速訪問效率。下圖是對應請求服務的TWS機器的SET劃分。

4.3 實現容錯、預防單點失效

根據上述圖表，每個SET有至少一個以上機器可供使用，SET中設定多機器即可實現不同TWS對應APP的SET中的不同機器獲取服務，以防止單臺服務機失效問題

4.4 應對業務變化、使用者增加

對於業務變化問題，如圖所示

專案後期，由於IDC機器不能根據域名訪問相應JSS機器拉取資料，根據需要增加了HTTP服務SET，如圖橙色和淺紫色所示，使用該服務可以令相應APP機器訪問JSS伺服器82號機。

對於使用者增加業務增加問題，我們也可以相同的增加相應服務SET或增加SET中的機器數量以適應業務變更，同樣的當活動結束需求降低，可以摘除部分SET內的機器或整體摘除服務。

4.5 關於監聽埠

SET集合的埠是用於被調的，即該埠用於監聽並提供來自於該埠的請求服務，因此APP的SET集合的埠應該向上級申請，並實現絕對獨立，而TWS不用於向APP提供服務，所以其監聽埠無用，但是該埠號不能重合現有服務，防止其阻塞TWS正常服務的監聽。

4.6 寫在最後

其實SET模型只是一種解耦、內聚的思想，用於方便操作和業務需要，應該因地制宜的使用，就如上圖的Daemon服務機SET組，僅用於Daemon服務呼叫單臺機器以實現每天重新整理當天最新資料。

原文地址：http://www.wtoutiao.com/p/LecwhR.html

其他參考文章：http://www.doc88.com/p-3823718714156.html