互聯網產品灰度發布

互聯網產品灰度發布

 

關于2016年5月15日，DevOps成都站｜架構與運維峰會活動總結

1. 前言 2

2. 灰度發布定義 5

3. 灰度發布作用 5

4. 灰度發布步驟 5

5. 灰度發布測試方法 6

6. 灰度發布引擎 6

7. 灰度發布常見問題 8

7.1. 以偏概全 8

7.1.1. 問題特點： 8

7.1.2. 解決方案： 8

7.2. 知識的詛咒 9

7.2.1. 問題特點： 9

7.2.2. 解決方案： 9

7.3. 發布沒有回頭路可走 9

7.3.1. 問題特點： 9

7.3.2. 解決方案： 9

7.4. 用戶參與度不夠 10

7.4.1. 問題特點： 10

7.4.2. 解決方案： 10

8. 讓產品具有灰度發布能力 10

8.1. 灰度機制的7個維度 10

8.1.1. 需求度 10

8.1.2. 速度 10

8.1.3. 靈活度 10

8.1.4. 冗余度 11

8.1.5. 開放協作度 11

8.1.6. 進化度 11

8.1.7. 創新度 11

8.2. 灰度發布的策略要素 11

8.2.1. 易于發布到云平臺 11

8.2.2. 設置用戶標識策略 12

8.2.3. 目標用戶選取策略 12

8.2.4. 提供數據反饋入口 12

8.2.5. 新版本回滾策略 12

8.2.6. 新版本公關運營支持 13

8.3. 灰度發布的方案 13

8.3.1. 方案1：代碼邏輯控制 13

8.3.2. 方案2：Alibaba預發機制 14

8.3.3. 方案3：SET部署 14

8.3.3.1. 依照業務隔離部署 14

8.3.3.2. 依照用戶隔離部署 15

8.3.4. 方案4：動態路由 16

9. 采取灰度發布的案例 16

9.1. 谷歌Gmail Labs 16

9.2. 騰訊QZone 17

9.3. 微信wechat 17

9.4. Ucloud高可用架構實踐 20

10. 參考資料 26

 

 

1. 前言

 互聯網產品有1個特點，就是不停的升級，升級，再升級。1般采取敏捷開發的團隊，基本上保持每周1次的發布頻率，系統升級總是伴隨著風險，新舊版本兼容的風險，用戶使用習慣突然改變而造成用戶流失的風險，系統down機的風險.....為了不這些風險，很多產品都采取了灰度發布的策略，其主要思想就是把影響集中到1個點，然后再發散到1個面，出現意外情況后很容易就回退。

很長時間，我們都1直在改進搜索引擎的排序算法，盡可能讓最好的商品出現在 搜索結果的第1屏。我們嘗試了很多種算法，不斷調劑各個排序因子所占的比重。但是我們沒法確信我們的排序結果能滿足所有用戶的需求。所以我們采取了灰度發 布，選取幾個1級商品類目，在其中利用不同的排序算法，比如在女裝類目中，我們把賣家信譽所占的比率調劑到60%，在珠寶類目中，我們把銷售量所占的比率 調劑到60%.. 然后發布出去，搜集用戶反饋，終究選擇1種大部份人認為好的算法。

     在傳統軟件產品發布進程中（例如微軟的Windows 7的發布進程中），1般都會經歷Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等幾個階段（參考Software release life cycle）。可以看出傳統軟件的發布階段是從公司內部->外部小范圍測試>外部大范圍測試->正式發布，觸及的用戶數也是逐漸放量的進程。

   在互聯網產品的發布進程中也較多采取此種發布方式：產品的發布進程不是一揮而就，而是逐漸擴大使用用戶的范圍，從公司內部用戶->虔誠度較高的種子 用戶->更大范圍的活躍用戶->所有用戶。在此進程中，產品團隊根據用戶的反饋及時完善產品相干功能。此種發布方式，依照中國特點的叫法被冠 以”灰度發布“、”灰度放量“、”分流發布“。

  關于“灰度發布”叫法的來源無從考察。只不過依照中國傳統哲學的說法來看，很符合中國人中庸的思惟模式：自然界所有的事物總是以對稱、互補、和諧的情勢存 在，例如黑與白、陰與陽、正與負、福與禍。在2元對峙的元素間存在相互過渡的階段，所謂”禍兮福所倚，福兮禍所伏“。具體到黑與白，在非黑即白中間還有中 間色——灰色。因而出現了很多關于灰色的說法：灰盒測試，灰色管理（極力推薦 任正非：管理的灰度），灰色收入，灰色地帶等等。因此對灰度發布實際上就是從不發布，然后逐步過渡到正式發布的1個進程。

2. 灰度發布定義

灰度發布是指在黑與白之間，能夠平滑過渡的1種發布方式。AB test就是1種灰度發布方式，讓1部份用戶繼續用A，1部份用戶開始用B，如果用戶對B沒有甚么反對意見，那末逐漸擴大范圍，把所有用戶都遷移到B上面 來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就能夠發現、調劑問題，以保證其影響度。

3. 灰度發布作用

a.盡早取得用戶的意見反饋，完善產品功能，提升產品質量

b.讓用戶參與產品測試，加強與用戶互動

c.下降產品升級所影響的用戶范圍

d.規避1定的發布風險

e.避免停服發布給用戶帶來不便

f.具有容災能力

4. 灰度發布步驟

  1）、定義目標

  2）、選定策略：包括用戶范圍、發布頻率、功能覆蓋度、回滾策略、運營策略、新舊系統部署策略等

  3）、挑選用戶：包括用戶特點、用戶數量、用戶經常使用功能、用戶范圍等

  4）、部署系統：部署新系統、部署用戶行動分析系統（web analytics）、設定分流規則、運營數據分析、分流規則微調

  5）、發布總結：用戶行動分析報告、用戶問卷調查、社會化媒體意見搜集、構成產品功能改進列表

  6）、產品完善

  7）、新1輪灰度發布或完全發布

 

5. 灰度發布測試方法

     灰度發布于互聯網公司經常使用A/B測試似乎比較類似，老外似乎并沒有所謂的灰度發布的概念。依照wikipedia中對A/B測試的定義，A/B測試又叫：A/B/N Testing、Multivariate Testing，因此本質上灰度測試可以算作A/B測試的1種特例。只不過為了術語上不至于同等弄混淆，談談自己理解的二者的差異。

    灰度發布是對某1產品的發布逐漸擴大使用群體范圍，也叫灰度放量

    A/B測試重點是在幾種方案當選擇最優方案

   關于A/B測試可以參考這篇文章：A/B測試終極指南

 

6. 灰度發布引擎

     對1般的小系統其實不需要單獨的灰度發布引擎，可以參考A/B測試中做法，在頁面javascript或服務器端實現分流的規則便可。但對大型的互聯網利用而言，單獨的用于管理用戶分流的發布引擎就很有必要了。“錢掌柜”分流發布模式 提到了原來阿里軟件所使用的灰度發布引擎，設計思路具有普遍性，可以供參考

下面是1個灰度發布的架構示意圖：

 

7. 灰度發布常見問題

7.1. 以偏概全

7.1.1. 問題特點：

a選擇的樣本不具有代表性；

b樣本具有代表性，但選擇樣本用戶使用習慣并沒有涵蓋所有核心功能

7.1.2. 解決方案：

樣本選擇要多樣化，樣本的組合涵蓋大部份核心功能

7.2. 知識的詛咒

“知識的詛咒”的說法來自《粘住》中實驗，具體可以自己搜索1下。我們自己對自己開發的產品極其熟習，因而乎想固然認為用戶也應當能夠理解產品的設計思路、產品的功能使用。

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. 解決方案：

    前期產品策劃重點斟酌這些問題，包括：回滾方案、 新舊系統兼容方案、用戶體驗的1致性、用戶使用習慣的延續性、新舊系統數據模型兼容性

7.4. 用戶參與度不夠

7.4.1. 問題特點：

a期望用戶自己去發掘所有功能。對1個產品，大部份用戶常常只使用部份功能，用戶大部份也很怠惰，不會主動去發掘產品功能

b互動渠道單1

c墮入“知識的詛咒”，不尊重參與用戶意見

7.4.2. 解決方案：

a善待吃螃蟹的樣本用戶，包括給予參與測試的用戶小嘉獎（例如MS給參與Win7測試用戶正版License）、給用戶冠以title

b通過郵件、論壇、社區、Blog、Twitter等新媒體與用戶構成互動

c提供產品功能向導。在hotmail最近的升級后的功能tip，gmail的tip都有類似的產品功能導向。在產品中會提示類似于：你知道嗎，xx還提供xx功能，通過它你可以xx 。

8. 讓產品具有灰度發布能力

8.1. 灰度機制的7個維度

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. 易于發布到云平臺

    1般采取灰度發布都是具有自主產品的平臺模式發布，而不是在客戶服務器端進行發布，具有自主研發產品和有1定硬件部署能力的企業可以斟酌灰度發布。

灰度發布1般是基于云的需要，如負載均衡，用戶隔離等機制。如大型的電商網站等都是采取的散布式部署方式，利用負載均衡實現服務器分發，將用戶訪問分配到不同的地區服務器訪問，確保用戶訪問效力，提升用戶體驗。

之所以強調易于發布，就是公司要具有自己可操作的服務器裝備（云服務裝備），這樣可以實現在用戶不知情的情況下實現灰度發布。即，在用戶無感知的情況下實現最優配置的測試部署，提升產品質量，實現產品快速迭代——頻繁發布，實現具成心義的‘實時發布’策略。

注：需要開通云服務模式（有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. 灰度發布的方案

灰度發布1般有3種方式 nginx+lua，nginx根據cookie分流，nginx 根據權重來分配：
     nginx+lua根據來訪者ip地址辨別，由于公司出口是1個ip地址，會出現訪問網站要末都是老版，要末都是新版，采取這類方式其實不合適nginx 根據權重來分配，實現很簡單，也能夠嘗試nginx根據cookie分流，灰度發布基于用戶才更公道。

 

Nginx+lua配置可以參考以下文章進行實踐：

利用nginx+lua+memcache實現灰度發布

 

Nginx+Lua+Redis實例

 

nginx灰度方案---基于ip或基于cookies

 

8.3.1. 方案1：代碼邏輯控制

實現：

在代碼中埋開關，做if-else判斷，對需要灰度的機器，設置開關為on，否則為off。每次版本發布都是有兩個版本。

優點

· 快速回滾，不需要重新發布和重啟系統。

缺點

· 對代碼有傾入性。

· 分支邏輯，帶來復雜性。

這類方式筆者曾利用過，就是在阿里的時候把商品的數據庫從Oracle切換到MySql，使用了1個狀態變量進行控制。從而打到平滑遷移的效果。

 

8.3.2. 方案2：Alibaba預發機制

    其實這個不是真正意義上的灰度。由于這個預先發布機器是內部IP，沒有對外服務的。需要綁定域名進行驗證。但是數據是完全的線上。所以本質上是灰度 某些特定用戶（可以訪問灰度機器的用戶，內部測試用戶）的1種簡單做法。其實API這邊也有類似的做法，就是我們的Gamma環境，而且我們還提供了 Gamma機器的域名，方便外部合作用戶配合測試。

優點

· 簡單

缺點

· 浪費1臺機器（這個可以預先發布完成以后投入正式環境，預發布的時候從nginx摘除，不過需要運維支持。）

· 不夠靈活

· 只能針對接入層機器，IDL服務灰度需要另外斟酌。

8.3.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

    上面是大業務級別的隔離部署。還可以進1步細化到模塊級別，比如虛擬服務電商的API，是掛在拍拍下面的1個子業務模塊，但是由于他們接入微信之 后，訪問量大增，為了不影響拍拍其他業務，也為了不受其他業務影響，API這里是給他們單獨部署了兩臺機器，nginx配置1下就能夠將針對虛擬的 API訪問引流過來了：

虛擬API Container：http://api.paipai.com/v2/virbiz

這樣，我們在發布1個版本的時候，可以先選擇業務量最小的易迅進行發布，視察沒有問題再全量其他平臺。

8.3.3.2. 依照用戶隔離部署

    這個對開放平臺來講不是很合適，不過對SNS這類利用場景就很適合了。比如QQ系統，依照用戶號碼段分為若干個set，每一個set包括連續1億 個號碼的用戶。假定現在最新的QQ號碼接近10億，則總共有10個set（Set 1到Set 10）。這樣每次可以選擇其中1個SET進行發布，而且高位QQ常常是否是很重要的用戶，所以會先發布SET10。

優點

· 隔離部署，各個業務線影響最小。自動支持灰度發布。

缺點

· 灰度的粒度取決于隔離部署的粒度，1般會偏大。

· 相對集中部署比較浪費機器。

· 各個業務線版本可能不1致，不利于統1管理。

· 有1定的實現和部署本錢

 

 

8.3.4. 方案4：動態路由

   采取1個可以靈活配置的灰度策略，影響Load Balance的行動，讓其根據灰度策略，返回灰度服務的IP和端口。

合適與后臺IDL的服務灰度。

優點

· 靈活，可控。

缺點

· 現在的配置中心和L5本身沒有斟酌指定路由策略，且不具有擴大性，需要在其外邊開發。

· API的元數據來源比較分散，目前 API和IDL元數據，API等級和頻率限制 散布在不同的數據源，現在需要增加1個 灰度路由 數據源。

 

 

9. 采取灰度發布的案例

9.1. 谷歌Gmail Labs

Gmail Labs是1個新特性櫥窗，用戶可以自己選擇1些未正式發布的新特性進行體驗，不喜歡可以關閉，在這個進程中，吃了螃蟹，也當了Google的小白鼠。

這個做法比傳統的灰度要高明很多，更加尊重用戶：

1、它沒有強加用戶，用戶是不是愿意當小白鼠完全自愿

2、新特性不是打包在1起的1個大版本，可以選擇某幾個喜歡的螃蟹嘗嘗

3、螃蟹不好吃可以扔掉，不用硬吃進肚子里引發腸胃炎

固然這些好處也是有代價的：

1、要開發1個labs平臺實現新特性上架、獨立嘗試的功能，這可能要改動Gmail的前后臺架構

2、新特性要依照1定規范來寫，才能發布到這個平臺上，可能會增加1些工作量

3、小白鼠用戶增多以后，對系統的壓力可能會有1定提升，由于每位用戶調用的界面都不1樣了

既然Gmail Labs能夠順利發布，那末說明對Google來講，以上這些問題都不算問題。另外，現在展現的新特性，都注明了開發者的名字，那末，Gmail Labs可能會開放這個平臺讓外部開發者也能提交特性？這倒是很open的1種開發模式，非常合適Google的web app產品線。

9.2. 騰訊QZone

QZone是另外1個采取灰度發布的例子。大家都知道，QZone的改進是巨大的，從之前慢吞吞的老爺爺變成了1個充滿青春活力的小伙子。其中經歷了大小無數次的發布，他們的發布也都是采取了灰度發布的策略，用戶數據的升級其實不是大 面積的1次性升級，而是通過1個用戶升級標志服務器，如果用戶數據沒有升級，后臺會把此用戶的數據逐漸遷移到新版本上，然后將升級標志位置1，升級進程 中，用戶依然可以訪問舊的數據，升級完成后的訪問都將轉發給新的版本。

QQ的很多產品發布都采取灰度發布，有些是抽取部份QQ號段升級成新系統，然后根據用戶反饋再大范圍升級。

9.3. 微信wechat

灰度、灰度、再灰度

    在變更后的部署方式上，微信在1些規則會限定不能1次把所有的邏輯變更上去，每次變更1小點視察到每個環節沒有問題的時候，才能布局到全網上去。微信后臺每天可以支持超過20個后臺變更，在業界來講，通常做到5個已是比較快了，但是微信可以做到快4倍。

騰訊內部的上線系統

而所謂灰度發布，是指在黑與白之間，能夠平滑過渡的1種發布方式。AB test就是1種灰度發布方式，讓1部用戶繼續用A，1部份用戶開始用B，如果用戶對B沒有甚么反對意見，那末逐漸擴大范圍，把所有用戶都遷移到B上面 來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就能夠發現、調劑問題，以保證其影響度。(在騰訊，灰度發布是最常采取的發布方式之1)

孫子兵法：古之所謂善戰者，勝于易勝者也

常識上，解決1個復雜問題的時候，會用高明的技能解決復雜的問題，這個不是微信團隊的目標，他們尋求的要做到讓所有問題很自然和簡單的方式解決掉。在周顥看來，微信架構的技術復雜點在4個要點：協議、容災、輕重、監控。

微信架構

· 協議。手機終端跟后臺服務器之間的交互協議，這個協議的設計是全部系統的骨架，在這1點做好設計可使得系統的復雜度大大下降。

· 容災。當系統出現了若干服務器或若干支架(宕機的時候)，依然需要讓系統盡量的提供正常的服務。

· 輕重。如何在系統架構中散布功能，在哪個點實現哪個功能，代表系統中間的功能配置。

· 監控。為系統提供1個智能儀表盤。

在協議設計上，移動互聯網和常規互聯網有很大的區分。首先有CMWAP和CMNET的不同，在中國現在有相當多的手機用戶使用WMWAP連接，還有 就是在線和離線的概念，當QQ下線的時候叫離線，當你登錄的時候叫在線。但是在移動互聯網這兩個概念比較模糊。從微信的設計中，不管在線還是離線系統表現 都應當是1致的。還有1個是連接不穩定的問題，由于手機信號強弱的變化，當時信號很好，5秒鐘走到信號不好的地區，連接就必須斷掉。這個中間帶來不穩定的 因素為協議設計帶來較大困難。另外就是資費敏感的問題，由于移動互聯網是依照流量計費的，這個計費會使得在協議設計中如何最小化傳輸的問題。最后就是高延 遲的問題。

對此，業界標準的解決方案：Messaging And Presence Protocol：1)XMPP;2)SIP/SIMPLE。它的優點是簡單，大量開源實現。而缺點一樣明顯：1)流量大：狀態初始化；2)消息不可靠。

微信在系統中做了特殊設計，叫SYNC協議，是參考Activesyec來實現的。特點首先是基于狀態同步的協 議，假定說收發消息本身是狀態同步的進程，假定終端和服務器狀態已被遲了，在服務器端收到最新的消息，當客戶端、終端向服務器對接的時候，收取消息的過 程實際上可以簡單的歸納為狀態同步的進程，收消息和收取你好友狀態更新都是相同的。在這樣的模式之下，我們會或許會把交互的模式統1化，只需要推送1個 消息到達的通知就能夠了，終端收到這個通知就來做消息的同步。在這樣的簡化模式之下，安卓和塞班都可以得到統1。這樣的系統本身的實現是更加復雜的，但是 取得很多額外的好處。

讓剩下系統實現的部份更加簡單，簡化了交互模式，狀態同步可以通過狀態同步的差值取得最小的數據變更，通過增量的傳輸得到最小的數據傳輸量。通過這 樣的協議設計，微信可以確保消息是穩定到達的，而且是按序到達。援用1句俗話：比它炫的沒它簡單，比它簡單的沒它快，沒誰比他更快，哪怕在GPRS下，微 信也能把進度條輕易推到底。

9.4. Ucloud高可用架構實踐

DevOps成都站｜架構與運維峰會活動總結地址：

http://mp.weixin.qq.com/s?__biz=MjM5NDE0MjI4MA==&mid=2656298704&idx=2&sn=68d5d42a9c26640a21eebd3253ca81c3&scene=1&srcid=0519IBq6Q2k77kYAQmXuofuV&from=groupmessage&isappinstalled=0#wechat_redirect

此處主要截取賬戶計費系統架構演進進程的6個階段進行整理。

服務架構的演進進程

UCloud服務架構的演進主要經歷了以下6個階段：

a.單體模式；

b.具有灰度發布能力；

c.前后端分離；

d.服務化改造；

e.按SET部署；

f.分機房按SET部署，按SET進行跨機房熱備容災。

 

1. 單體模式架構上線業務系統

UCloud服務早期上線時的架構主要分3部份：

· 

PHP Web Conosle,負責所有前端展現交互、后臺服務間邏輯組裝；

· 

· 

平臺類服務，賬戶、計費、監控、名字服務等公共服務；

· 

· 

各業務系統分數據中心后臺服務的接入層。

· 

PHP Web Console、業務系統分數據中心的服務、平臺類服務組合上線，Web Console 通過Protobuf與所有后端服務進行通訊。

 

2. 具有灰度發布能力

要解決前面面臨的問題，我們首先需要支持Web層灰度發布包括以下的灰度方式：

· 

無用戶態特性依照 單IP -> IP段(地區) -> 到IP取模逐漸灰度控制影響范圍；

· 

· 

有用戶態特性依照 單內部用戶(開發賬號) -> 內部測試賬號 -> 用戶分級逐漸灰度發布控制影響范圍。

· 

 

3. 前后端分離

· 

開發API Gateway 層用來管理后端 API 注冊和管理、權限驗證管理、流量控制；

· 

· 

開發API層，解決前臺交互層，需要整合跨系統邏輯調用問題，前端只專注產品交互和用戶體驗；

· 

· 

開發統1的單點登陸Token，系統方便前端實現跨域API調用讓前端代碼可以完全靜態化。

· 

在此階段，完成前端展現可以獨立控制發布，完全實現了前后端解耦，API協議保證向前兼容，Web端可以隨便重構交互優化前端架構,實現了跨域獨立部署,獨立的灰度策略相互之間不受影響，極大的提高了前端團隊開發效力和穩定性。

 

4. 服務化改造

 對業務端API開發效力優化：

· 

依照業務模塊化，所有業務API由后臺產品研發部門獨立部署發布上線；

· 

· 

抽象通用平臺類特性例如：子賬號特性，權限體系，計費等特性抽象公共能力讓業務端在API中組裝。

· 

整體目標：讓業務API開發效力提升并單獨部署保護，提高產品特性的研發迭代效力并提高穩定性。

 

5. 按SET部署

基礎架構優化終了，各個業務系統單獨部署發布，開始對系統進行容量和容災方面的斟酌，從部份平臺類系統開始斟酌按SET部署架構測底解決容量和容災問題，每一個SET只服務1部份用戶，保證遇到物理服務器宕機等故障情況下只影響部份用戶或業務。

例如圖上所示， SET 1 服務1 ～ 服務50000000 用戶，SET 2 服務50000001 ~ 100000000 的用戶，1個SET 出現問題只影響1個部份用戶，不同的業務根據本身情況進行SET切分，范圍大小也視情況而定，按SET部署后公道的劃分方式下不同SET之間數據還可以相互遷移，來平衡弄負載或高容量的SET,極大的提高了可運維性。

 

6. 分機房部署SET

按SET部署架構改造終了后還沒有到達最理想的狀態，如果所有服務部署在單機房還是可能會出現問題，機房整體出現斷電、斷網等故障還是會出現大面積影響。

· 

對SET架構進行分機房部署，讓不同的用戶運行在不同的機房中，這依賴1些基礎設施比如跨機房光線專線。

· 

· 

跨地域SET在相鄰節點部署熱備，以便出現機房故障時能具有異地快速恢復服務的能力。

· 

整體介紹了UCloud在不同的階段架構演進的1些進程和經驗，架構沒有最好的，只有最適合當前業務發展的架構。

 

 

10. 參考資料

甚么是灰度發布

 

從騰訊的“灰度機制”到產品的“灰度上線”，你了解多少？

 

“錢掌柜”分流發布模式

百度百科：灰度發布

A/B testing

A/B測試終極指南

互聯網產品的灰度發布

聊聊灰度發布

1億用戶增長背后的架構秘密-騰訊微信技術總監周顥

 

馬化騰談互聯網產品：灰度法則的7個維度