互聯網產品灰度發佈
原文地址：http://blog.csdn.net/boonya/article/details/51537674
關於2016年5月15日，DevOps成都站｜架構與運維峯會活動總結
1. 前言
互聯網產品有一個特點，就是不停的升級，升級，再升級。一般採用敏捷開發的團隊，基本上保持每週一次的發佈頻率，系統升級總是伴隨着風險，新舊版本兼容的風險，用戶使用習慣突然改變而造成用戶流失的風險，系統down機的風險.....爲了避免這些風險，很多產品都採用了灰度發佈的策略，其主要思想就是把影響集中到一個點，然後再發散到一個面，出現意外情況後很容易就回退。
很長時間，我們都一直在改進搜索引擎的排序算法，儘量讓最好的商品出現在 搜索結果的第一屏。我們嘗試了很多種算法，不斷調整各個排序因子所佔的比重。但是我們無法確信我們的排序結果能滿足所有用戶的需求。所以我們採用了灰度發 布，選取幾個一級商品類目，在其中應用不同的排序算法，比如在女裝類目中，我們把賣家信用所佔的比率調整到60%，在珠寶類目中，我們把銷售量所佔的比率 調整到60%.. 然後發佈出去，收集用戶反饋，最終選擇一種大部分人認爲好的算法。
在傳統軟件產品發佈過程中（例如微軟的Windows 7的發佈過程中），一般都會經歷Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等幾個階段（參考Software release life cycle）。可以看出傳統軟件的發佈階段是從公司內部->外部小範圍測試>外部大範圍測試->正式發佈，涉及的用戶數也是逐步放量的過程。
在互聯網產品的發佈過程中也較多采用此種發佈方式：產品的發佈過程不是一蹴而就，而是逐步擴大使用用戶的範圍，從公司內部用戶->忠誠度較高的種子 用戶->更大範圍的活躍用戶->所有用戶。在此過程中，產品團隊根據用戶的反饋及時完善產品相關功能。此種發佈方式，按照中國特色的叫法被冠 以”灰度發佈“、”灰度放量“、”分流發佈“。
關於“灰度發佈”叫法的來源無從考察。只不過按照中國傳統哲學的說法來看，很符合中國人中庸的思維模式：自然界所有的事物總是以對稱、互補、和諧的形式存 在，例如黑與白、陰與陽、正與負、福與禍。在二元對立的元素間存在相互過渡的階段，所謂”禍兮福所倚，福兮禍所伏“。具體到黑與白，在非黑即白中間還有中 間色——灰色。於是出現了很多關於灰色的說法：灰盒測試，灰色管理（極力推薦 任正非：管理的灰度），灰色收入，灰色地帶等等。因此對於灰度發佈實際上就是從不發佈，然後逐漸過渡到正式發佈的一個過程。
2. 灰度發佈定義
灰度發佈是指在黑與白之間，能夠平滑過渡的一種發佈方式。AB test就是一種灰度發佈方式，讓一部分用戶繼續用A，一部分用戶開始用B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B上面 來。灰度發佈可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
3. 灰度發佈作用
a.及早獲得用戶的意見反饋，完善產品功能，提升產品質量
b.讓用戶參與產品測試，加強與用戶互動
c.降低產品升級所影響的用戶範圍
d.規避一定的發佈風險
e.避免停服發佈給用戶帶來不便
f.具有容災能力
4. 灰度發佈步驟
1）、定義目標
2）、選定策略：包括用戶規模、發佈頻率、功能覆蓋度、回滾策略、運營策略、新舊系統部署策略等
3）、篩選用戶：包括用戶特徵、用戶數量、用戶常用功能、用戶範圍等
4）、部署系統：部署新系統、部署用戶行爲分析系統（web analytics）、設定分流規則、運營數據分析、分流規則微調
5）、發佈總結：用戶行爲分析報告、用戶問卷調查、社會化媒體意見收集、形成產品功能改進列表
6）、產品完善
7）、新一輪灰度發佈或完整發布
5. 灰度發佈測試方法
灰度發佈於互聯網公司常用A/B測試似乎比較類似，老外似乎並沒有所謂的灰度發佈的概念。按照wikipedia中對A/B測試的定義，A/B測試又叫：A/B/N Testing、Multivariate Testing，因此本質上灰度測試可以算作A/B測試的一種特例。只不過爲了術語上不至於等同搞混淆，談談自己理解的兩者的差異。
灰度發佈是對某一產品的發佈逐步擴大使用羣體範圍，也叫灰度放量
A/B測試重點是在幾種方案中選擇最優方案
關於A/B測試可以參考這篇文章：A/B測試終極指南
6. 灰度發佈引擎
對於一般的小系統並不需要單獨的灰度發佈引擎，可以參考A/B測試中做法，在頁面javascript或服務器端實現分流的規則即可。但對於大型的互聯網應用而言，單獨的用於管理用戶分流的發佈引擎就很有必要了。“錢掌櫃”分流發佈模式 提到了原來阿里軟件所使用的灰度發佈引擎，設計思路具有普遍性，可以供參考
下面是一個灰度發佈的架構示意圖：
7. 灰度發佈常見問題
7.1. 以偏概全
7.1.1. 問題特徵：
a選擇的樣本不具有代表性；
b樣本具有代表性，但選擇樣本用戶使用習慣並沒有涵蓋所有核心功能
7.1.2. 解決方案：
樣本選擇要多樣化，樣本的組合涵蓋大部分核心功能
7.2. 知識的詛咒
“知識的詛咒”的說法來自《粘住》中實驗，具體可以自己搜索一下。我們自己對於自己開發的產品極爲熟悉，於是乎想當然認爲用戶也應當能夠理解產品的設計思路、產品的功能使用。
7.2.1. 問題特徵：
a結果沒有量化手段；
b只依賴於用戶問卷調查；
c沒有web analytics系統；
d運營數據不全面，只有核心業務指標（例如交易量），沒有用戶體驗指標
e對結果分析，只選擇對發佈有利的信息，對其他視而不見
7.2.2. 解決方案：
a產品設計考慮產品量化指標
b結果分析依據量化指標而不是感覺
7.3. 發佈沒有回頭路可走
7.3.1. 問題特徵：
a新舊系統用戶使用習慣差異太大，沒有兼容原有功能
b新舊系統由於功能差異太大，無法並行運行，只能強制升級
c新系統只是實現了舊系統部分功能，用戶要完整使用所有功能，要在 在新舊系統切換
d新舊系統數據庫數據結構差異太大，無法並行運行
7.3.2. 解決方案：
前期產品策劃重點考慮這些問題，包括：回滾方案、 新舊系統兼容方案、用戶體驗的一致性、用戶使用習慣的延續性、新舊系統數據模型兼容性
7.4. 用戶參與度不夠
7.4.1. 問題特徵：
a指望用戶自己去挖掘所有功能。對於一個產品，大部分用戶經常只使用部分功能，用戶大部分也很懶惰，不會主動去挖掘產品功能
b互動渠道單一
c陷入“知識的詛咒”，不尊重參與用戶意見
7.4.2. 解決方案：
a善待吃螃蟹的樣本用戶，包括給予參與測試的用戶小獎勵（例如MS給參與Win7測試用戶正版License）、給用戶冠以title
b通過郵件、論壇、社區、Blog、Twitter等新媒體與用戶形成互動
c提供產品功能嚮導。在hotmail最近的升級後的功能tip，gmail的tip都有類似的產品功能導向。在產品中會提示類似於：你知道嗎，xx還提供xx功能，通過它你可以xx 。
8. 讓產品具備灰度發佈能力
8.1. 灰度機制的七個維度
8.1.1. 需求度
用戶需求是產品核心，產品對需求的體現程度，就是企業被生態所需要的程度;
8.1.2. 速度
快速實現單點突破，角度、銳度尤其是速度，是產品在生態中存在發展的根本;
8.1.3. 靈活度
敏捷企業、快速迭代產品的關鍵是主動變化，主動變化比應變能力更重要;
8.1.4. 冗餘度
容忍失敗，允許適度浪費，鼓勵內部競爭內部試錯，不嘗試失敗就沒有成功;
8.1.5. 開放協作度
最大程度地擴展協作，互聯網很多惡性競爭都可以轉向協作型創新;
8.1.6. 進化度
構建生物型組織，讓企業組織本身在無控過程中擁有自進化、自組織能力;
8.1.7. 創新度
創新並非刻意爲之，而是充滿可能性、多樣性的生物型組織的必然產物。
8.2. 灰度發佈的策略要素
8.2.1. 易於發佈到雲平臺
一般採用灰度發佈都是具有自主產品的平臺模式發佈，而不是在客戶服務器端進行發佈，具備自主研發產品和有一定硬件部署能力的企業可以考慮灰度發佈。
灰度發佈一般是基於雲的需要，如負載均衡，用戶隔離等機制。如大型的電商網站等都是採用的分佈式部署方式，利用負載均衡實現服務器分發，將用戶訪問分配到不同的地區服務器訪問，確保用戶訪問效率，提升用戶體驗。
之所以強調易於發佈，就是公司要具備自己可操作的服務器設備（雲服務設備），這樣可以實現在用戶不知情的情況下實現灰度發佈。即，在用戶無感知的情況下實現最優配置的測試部署，提升產品質量，實現產品快速迭代——頻繁發佈，實現具有意義的‘實時發佈’策略。
注：需要開通雲服務模式（有一定硬件和經濟實力的公司可以考慮）。
8.2.2. 設置用戶標識策略
用於區分用戶，輔助數據統計，保證灰度發佈過程中用戶體驗的連貫性（避免用戶在新舊版本中跳變，匿名Web應用比較容易有這個問題）。匿名Web應用可採用IP、Cookie等，需登錄的應用可直接採用應用的帳號體系。
8.2.3. 目標用戶選取策略
即選取哪些用戶先行體驗新版本，是強制升級還是讓用戶自主選擇等。可考慮的因素很多，包括但不限於地理位置、用戶終端特性（如分辨率、性能）、用戶自身特點（性別、年齡、忠誠度等）。對於細微修改（如文案、少量控件位置調整）可直接強制升級，對於類似新浪微博改版這樣的大型升級，應讓用戶自主選擇，最好能夠提供讓用戶自主回滾至舊版本的渠道。
對於客戶端應用，可以考慮類似Chrome的多channel升級策略，讓用戶自主選擇採用stable、beta、unstable channel的版本。在用戶有明確預期的情況下自行承擔試用風險。
8.2.4. 提供數據反饋入口
用戶數據反饋：在得到用戶允許的前提下，收集用戶的使用新版本應用的情況。如客戶端性能、客戶端穩定性、使用次數、使用頻率等。用於與舊版本進行對比，決策後續是繼續擴大新版本投放範圍還是回滾。
服務端數據反饋：新版本服務端性能、服務端穩定性等，作用與用戶數據反饋類似。
8.2.5. 新版本回滾策略
當新版本灰度發佈表現不佳時，應回滾至舊版本。對於純粹的Web應用而言，回滾相對簡單。主要難點在於用戶數據的無縫切換。對於客戶端應用，如果期待用戶自行卸載新版本另行安裝舊版本，成本和流失率都太高。可以考慮通過快速另行發佈新版本，利用升級來“回滾”，覆蓋上次灰度發佈的修改。
對於移動客戶端，新版本發佈成本較高，需要Appstore、Market審覈。本人沒有移動客戶端產品的經驗，不太確定移動客戶端產品如何處理灰度發佈及回滾。但儘量將客戶端打造成Web App，會更有利於升級和回滾。（不過蘋果對純Web App類的App有較強的限制，好像已經不允許在Appstore上發佈這類應用了？）
8.2.6. 新版本公關運營支持
對於改版級別的大型升級，需要配合公關運營支持，用於及時處理用戶在微博、博客等渠道給出的“顯式反饋”。對比通過隱式數據反饋得到的結論後，綜合考慮應對策略。
8.3. 灰度發佈的方案
灰度發佈一般有三種方式 nginx+lua，nginx根據cookie分流，nginx 根據權重來分配：
nginx+lua根據來訪者ip地址區分，由於公司出口是一個ip地址，會出現訪問網站要麼都是老版，要麼都是新版，採用這種方式並不適合nginx
根據權重來分配，實現很簡單，也可以嘗試nginx根據cookie分流，灰度發佈基於用戶才更合理。
Nginx+lua配置可以參考如下文章進行實踐：
8.3.1. 方案一：代碼邏輯控制
實現：
在代碼中埋開關，做if-else判斷，對於需要灰度的機器，設置開關爲on，否則爲off。每次版本發佈都是有兩個版本。
優點
· 快速回滾，不需要重新發布和重啓系統。
缺點
· 對代碼有傾入性。
· 分支邏輯，帶來複雜性。
這種方式筆者曾經應用過，就是在阿里的時候把商品的數據庫從Oracle切換到MySql，使用了一個狀態變量進行控制。從而打到平滑遷移的效果。
8.3.2. 方案二：Alibaba預發機制
其實這個不是真正意義上的灰度。因爲這個預先發布機器是內部IP，沒有對外服務的。需要綁定域名進行驗證。但是數據是完全的線上。所以本質上是灰度 某些特定用戶（可以訪問灰度機器的用戶，內部測試用戶）的一種簡單做法。其實API這邊也有類似的做法，就是我們的Gamma環境，而且我們還提供了 Gamma機器的域名，方便外部合作用戶配合測試。
優點
· 簡單
缺點
· 浪費一臺機器（這個可以預先發布完成之後投入正式環境，預發佈的時候從nginx摘除，不過需要運維支持。）
· 不夠靈活
· 只能針對接入層機器，IDL服務灰度需要另外考慮。
8.3.3. 方案三：SET部署
8.3.3.1. 按照業務隔離部署
比如現在API Container的做法，部署的粒度可以到API級別，前端根據nginx進行轉發。比如：
· 微購物 API Container: api.weigou.qq.com
· 拍拍 API Container：api.paipai.com
· 易迅 API Container: api.yixun.com
· 網購 API Container：api.buy.qq.com
上面是大業務級別的隔離部署。還可以進一步細化到模塊級別，比如虛擬服務電商的API，是掛在拍拍下面的一個子業務模塊，但是由於他們接入微信之 後，訪問量大增，爲了避免影響拍拍其他業務，也爲了避免受其他業務影響，API這裏是給他們單獨部署了兩臺機器，nginx配置一下就可以將針對虛擬的 API訪問引流過來了：
虛擬API Container：http://api.paipai.com/v2/virbiz
這樣，我們在發佈一個版本的時候，可以先選擇業務量最小的易迅進行發佈，觀察沒有問題再全量其他平臺。
8.3.3.2. 按照用戶隔離部署
這個對於開放平臺來說不是很適合，不過對於SNS這種應用場景就很合適了。比如QQ系統，按照用戶號碼段分爲若干個set，每個set包含連續1億 個號碼的用戶。假設現在最新的QQ號碼接近10億，則總共有10個set（Set 1到Set 10）。這樣每次可以選擇其中一個SET進行發佈，而且高位QQ往往是不是很重要的用戶，所以會先發布SET10。
優點
· 隔離部署，各個業務線影響最小。自動支持灰度發佈。
缺點
· 灰度的粒度取決於隔離部署的粒度，一般會偏大。
· 相對於集中部署比較浪費機器。
· 各個業務線版本可能不一致，不利於統一管理。
· 有一定的實現和部署成本
8.3.4. 方案四：動態路由
採用一個可以靈活配置的灰度策略，影響Load Balance的行爲，讓其根據灰度策略，返回灰度服務的IP和端口。
適合與後臺IDL的服務灰度。
優點
· 靈活，可控。
缺點
· 現在的配置中心和L5本身沒有考慮指定路由策略，且不具有擴展性，需要在其外邊開發。
· API的元數據來源比較分散，目前 API和IDL元數據，API等級和頻率限制 分佈在不同的數據源，現在需要增加一個 灰度路由 數據源。
9. 採用灰度發佈的案例
9.1. 谷歌Gmail Labs
Gmail Labs是一個新特性櫥窗，用戶可以自己選擇一些未正式發佈的新特性進行體驗，不喜歡可以關閉，在這個過程中，吃了螃蟹，也當了Google的小白鼠。
這個做法比傳統的灰度要高明很多，更加尊重用戶：
1、它沒有強加用戶，用戶是否願意當小白鼠完全自願
2、新特性不是打包在一起的一個大版本，可以選擇某幾個喜歡的螃蟹嚐嚐
3、螃蟹不好吃可以扔掉，不用硬吃進肚子裏引發腸胃炎
當然這些好處也是有代價的：
1、要開發一個labs平臺實現新特性上架、獨立嘗試的功能，這可能要改動Gmail的前後臺架構
2、新特性要按照一定規範來寫，才能發佈到這個平臺上，可能會增加一些工作量
3、小白鼠用戶增多之後，對系統的壓力可能會有一定提升，因爲每一位用戶調用的界面都不一樣了
既然Gmail Labs能夠順利發佈，那麼說明對Google來說，以上這些問題都不算問題。另外，現在展示的新特性，都註明了開發者的名字，那麼，Gmail Labs可能會開放這個平臺讓外部開發者也能提交特性？這倒是很open的一種開發模式，非常適合Google的web app產品線。
9.2. 騰訊QZone
QZone是另外一個採用灰度發佈的例子。大家都知道，QZone的改進是巨大的，從以前慢悠悠的老爺爺變成了一個充滿青春活力的小夥子。其中經歷了大小無數次的發佈，他們的發佈也都是採用了灰度發佈的策略，用戶數據的升級並不是大 面積的一次性升級，而是通過一個用戶升級標誌服務器，如果用戶數據沒有升級，後臺會把此用戶的數據逐步遷移到新版本上，然後將升級標誌位置1，升級過程 中，用戶仍然可以訪問舊的數據，升級完成後的訪問都將轉發給新的版本。
QQ的很多產品發佈都採用灰度發佈，有些是抽取部分QQ號段升級成新系統，然後根據用戶反饋再大範圍升級。
9.3. 微信wechat
灰度、灰度、再灰度
在變更後的部署方式上，微信在一些規則會限定不能一次把所有的邏輯變更上去，每一次變更一小點觀察到每一個環節沒有問題的時候，才能佈局到全網上去。微信後臺每一天可以支撐超過20個後臺變更，在業界來說，通常做到5個已經是比較快了，但是微信可以做到快4倍。
騰訊內部的上線系統
而所謂灰度發佈，是指在黑與白之間，能夠平滑過渡的一種發佈方式。AB test就是一種灰度發佈方式，讓一部用戶繼續用A，一部分用戶開始用B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B上面 來。灰度發佈可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。(在騰訊，灰度發佈是最常採用的發佈方式之一)
孫子兵法：古之所謂善戰者，勝於易勝者也
常識上，解決一個複雜問題的時候，會用高明的技巧解決複雜的問題，這個不是微信團隊的目標，他們追求的要做到讓所有問題很自然和簡單的方式解決掉。在周顥看來，微信架構的技術複雜點在四個要點：協議、容災、輕重、監控。
微信架構
· 協議。手機終端跟後臺服務器之間的交互協議，這個協議的設計是整個系統的骨架，在這一點做好設計可以使得系統的複雜度大大降低。
· 容災。當系統出現了若干服務器或若干支架(宕機的時候)，仍然需要讓系統儘可能的提供正常的服務。
· 輕重。如何在系統架構中分佈功能，在哪一個點實現哪一個功能，代表系統中間的功能配置。
· 監控。爲系統提供一個智能儀表盤。
在協議設計上，移動互聯網和常規互聯網有很大的區別。首先有CMWAP和CMNET的不同，在中國現在有相當多的手機用戶使用WMWAP連接，還有 就是在線和離線的概念，當QQ下線的時候叫離線，當你登錄的時候叫在線。但是在移動互聯網這兩個概念比較模糊。從微信的設計中，不管在線還是離線系統表現 都應該是一致的。還有一個是連接不穩定的問題，由於手機信號強弱的變化，當時信號很好，5秒鐘走到信號不好的地區，連接就必須斷掉。這個中間帶來不穩定的 因素爲協議設計帶來較大困難。此外就是資費敏感的問題，因爲移動互聯網是按照流量計費的，這個計費會使得在協議設計中如何最小化傳輸的問題。最後就是高延 遲的問題。
對此，業界標準的解決方案：Messaging And Presence Protocol：1)XMPP;2)SIP/SIMPLE。它的優點是簡單，大量開源實現。而缺點同樣明顯：1)流量大：狀態初始化；2)消息不可靠。
微信在系統中做了特殊設計，叫SYNC協議，是參考Activesyec來實現的。特點首先是基於狀態同步的協 議，假定說收發消息本身是狀態同步的過程，假定終端和服務器狀態已經被遲了，在服務器端收到最新的消息，當客戶端、終端向服務器對接的時候，收取消息的過 程實際上可以簡單的歸納爲狀態同步的過程，收消息以及收取你好友狀態更新都是相同的。在這樣的模式之下，我們會也許會把交互的模式統一化，只需要推送一個 消息到達的通知就可以了，終端收到這個通知就來做消息的同步。在這樣的簡化模式之下，安卓和塞班都可以得到統一。這樣的系統本身的實現是更爲複雜的，但是 獲得很多額外的好處。
讓剩下系統實現的部分更加簡單，簡化了交互模式，狀態同步可以通過狀態同步的差值獲得最小的數據變更，通過增量的傳輸得到最小的數據傳輸量。通過這 樣的協議設計，微信可以確保消息是穩定到達的，而且是按序到達。引用一句俗話：比它炫的沒它簡單，比它簡單的沒它快，沒誰比他更快，哪怕在GPRS下，微 信也能把進度條輕易推到底。
9.4. Ucloud高可用架構實踐
DevOps成都站｜架構與運維峯會活動總結地址：
此處主要截取賬戶計費系統架構演進過程的六個階段進行整理。
服務架構的演進過程
UCloud服務架構的演進主要經歷了以下六個階段：
a.單體模式；
b.具有灰度發佈能力；
c.前後端分離；
d.服務化改造；
e.按SET部署；
f.分機房按SET部署，按SET進行跨機房熱備容災。
1. 單體模式架構上線業務系統
UCloud服務初期上線時的架構主要分三部分：
·
PHP Web Conosle,負責所有前端展現交互、後臺服務間邏輯組裝；
·
·
平臺類服務，賬戶、計費、監控、名字服務等公共服務；
·
·
各業務系統分數據中心後臺服務的接入層。
·
PHP Web Console、業務系統分數據中心的服務、平臺類服務組合上線，Web Console 通過Protobuf與所有後端服務進行通信。
2. 具備灰度發佈能力
要解決前面面臨的問題，我們首先需要支持Web層灰度發佈包含以下的灰度方式：
·
無用戶態特性按照 單IP -> IP段(地區) -> 到IP取模逐步灰度控制影響範圍；
·
·
有用戶態特性按照 單內部用戶(開發賬號) -> 內部測試賬號 -> 用戶分級逐步灰度發佈控制影響範圍。
·
3. 前後端分離
·
開發API Gateway 層用來管理後端 API 註冊和管理、權限驗證管理、流量控制；
·
·
開發API層，解決前臺交互層，需要整合跨系統邏輯調用問題，前端只專注產品交互和用戶體驗；
·
·
開發統一的單點登陸Token，系統方便前端實現跨域API調用讓前端代碼可以完全靜態化。
·
在此階段，完成前端展現可以獨立控制發佈，徹底實現了前後端解耦，API協議保證向前兼容，Web端可以隨意重構交互優化前端架構,實現了跨域獨立部署,獨立的灰度策略互相之間不受影響，極大的提高了前端團隊開發效率和穩定性。
4. 服務化改造
對業務端API開發效率優化：
·
按照業務模塊化，所有業務API由後臺產品研發部門獨立部署發佈上線；
·
·
抽象通用平臺類特性例如：子賬號特性，權限體系，計費等特性抽象公共能力讓業務端在API中組裝。
·
總體目標：讓業務API開發效率提升並單獨部署維護，提高產品特性的研發迭代效率並提高穩定性。
5. 按SET部署
基礎架構優化完畢，各個業務系統單獨部署發佈，開始對系統進行容量和容災方面的考慮，從部分平臺類系統開始考慮按SET部署架構測底解決容量和容災問題，每個SET只服務一部分用戶，保證遇到物理服務器宕機等故障情況下隻影響部分用戶或業務。
例如圖上所示， SET 1 服務1 ～ 服務50000000 用戶，SET 2 服務50000001 ~ 100000000 的用戶，一個SET 出現問題隻影響一個部分用戶，不同的業務根據自身情況進行SET切分，規模大小也視情況而定，按SET部署後合理的劃分方式下不同SET之間數據還可以互相遷移，來平衡搞負載或高容量的SET,極大的提高了可運維性。
6. 分機房部署SET
按SET部署架構改造完畢後還沒有達到最理想的狀態，如果所有服務部署在單機房還是可能會出現問題，機房整體出現斷電、斷網等故障還是會出現大面積影響。
·
對SET架構進行分機房部署，讓不同的用戶運行在不同的機房中，這依賴一些基礎設施比如跨機房光線專線。
