灰度釋出的一種技術實踐
前段時間業務組負責人提出因為合規原因,一個功能模組需要在 App 實現灰度釋出,具體來講就是要在不同的地域和使用者等級開展差異化的活動內容展示。利用這個契機惡補了一些“灰度釋出”相關的知識,順勢將其中有價值的一些內容梳理與大家進行分享。
什麼是灰度?
要想了解這個問題就要先明白什麼是灰度。灰度從字面意思理解就是存在於黑與白之間的一個平滑過渡的區域,所以說對於網際網路產品來說,上線和未上線就是黑與白之分,而實現未上線功能平穩過渡的一種方式就叫做灰度釋出。
灰度釋出又叫金絲雀釋出,起源是,礦井工人發現,金絲雀對瓦斯氣體很敏感,礦工會在下井之前,先放一隻金絲雀到井中,如果金絲雀不叫了,就代表瓦斯濃度高。
灰度釋出和 AB Test 的區別
和大部分人一樣,我個人之前對灰度釋出和 AB Test 存在一定的混淆,認為就是換了一種說法,但實際調研發現兩者之間存在著本質上的區別。
1、AB Test
AB測試一般由產品經理和運營來主導。它是把兩種功能,或者兩個版本,交給相同的使用者來使用,看使用者喜歡哪種功能。
要點是,AB的兩種功能都是可用的, 投放的使用者群體無差別,讓使用者選擇更受歡迎的功能,後期可能是A上線,也可能是B上線。
2、灰度釋出
灰度測試一般由研發,測試或運維來主導。它是把系統的新版本,或者說新功能,以部分上線的方法來上線,驗證新版本是否足夠可靠。
關鍵要點是,灰度版本未必是可用的,或者說沒有嚴重bug的,投放的客戶群體可能只是北上廣深等一線城市的使用者,由監控確定是否有問題,後續可能會繼續放量上線。
灰度釋出的優勢
1、提前獲得使用反饋,縮減風險影響範圍
因為灰度釋出可以透過地域、性別、使用者等級、使用客戶端等一系列的策略條件對目標使用者群進行篩選,所以可以保證驗證版本影響的使用者在最小可接受的範圍內。此外,基於驗證版本提前收集使用者使用意見,及時完善產品功能,並且根據使用者和監控的反饋結果,做到查漏補缺,對於過程中發現的重大問題,甚至可以及時的回滾至“舊版本”。
2、自定義規則引擎,精準控制內容投放
此外灰度釋出可以作為一個自定義的規則引擎,可按地域、人群、時段等自定義標籤對 App 模組或者 Web 頁面進行內容的精準投放,滿足企業產品的精準化投放釋出需要。就像是我們業務組負責人提出的需求,把新上線的活動僅投放給北上廣深四個一線城市的高等級使用者。
灰度釋出方案分析
1、TestFlight
對於 iOS 開發者來講有一個較為方便的灰度測試方案,也是大家使用最多的 —— TestFlight。TestFlight測試工具允許開發者透過郵件等方式邀請使用者測試。TestFlight 在被蘋果收購之後,和 AppStoreConnect 進行了深入整合,現在,它可以生成一個公開的連結,使用者可以直接安裝測試。
當使用者開啟現有版本的 App 後,伺服器可以根據當前使用者的標籤判斷是否為灰度使用者。如果是的話,需下發TestFlight 的安裝連結,App 端引導使用者進入TestFlight 安裝。
但 TestFlight 也有一定的不足:
-
使用者必須安裝 TestFlight ;
-
有效測試時間為60天,在有效期結束之前需引導使用者更新正式版本;
-
測試使用者可以達到最多10000。
2、功能小程式化
第二種對於很多開發者來講可能比較陌生,起因是因為公司的 App 較為臃腫,迭代發版非常麻煩,希望功能模組互相解耦實現模組化開發,各業務模組間互不影響,所以計劃整合
FinClip SDK ,讓整個 App 具備小程式的執行能力,繼而把 App 之前的業務功能都小程式化,透過管理後臺去實現動態更新與釋出。
剛好在進行技術體驗時發現,FinClip 的小程式是藉助部署的 FinClip 管理後臺實現上下架,上下架的同時可以進行上架規則的制定。這樣一來,相當於有了一個自定義的灰度釋出引擎去自由配置地域、性別、使用者等級等自定義條件,不需要編寫任何複雜的應用邏輯程式碼,完成上下架的同時就完成了精準的上線釋出。
相對於 TestFlight ,這種方式的優勢在於:
-
不僅可以用在iOS系統中,Android 和桌面端應用也能整合 FinClip SDK ,相當於灰度測試覆蓋的範圍更加廣;
-
自身的迭代升級,不會影響到宿主 App 執行的穩定性,也無需對 App 進行全迴歸測試;
-
小程式業務功能開發可以高度並行;
-
灰度釋出粒度更細緻(例如一個小程式是可以僅在測試白名單的範圍內試點)。
由於本次調研的範圍和時間有限,所以我認為較好用的輕量化灰度釋出方案就暫時羅列這兩類,當然方案有千千萬,選擇自己合適的就好。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70021577/viewspace-2915330/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一鍵實現自動化部署(灰度釋出)實踐
- 基於 Istio 的灰度釋出架構方案實踐之路架構
- 分散式全鏈路灰度釋出的探索與實踐分散式
- nginx 實現實用的灰度釋出Nginx
- SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出(可灰度)SpringGCCloud
- Knativa 基於流量的灰度釋出和自動彈性實踐
- 如何實現灰度釋出輕量化?
- 使用 Nginx Ingress 實現金絲雀釋出/灰度釋出Nginx
- nginx+lua+redis實現灰度釋出NginxRedis
- 如何用istio實現應用的灰度釋出
- 大規模微服務場景下灰度釋出與流量染色實踐微服務
- 阿里雲基於ALB實現灰度釋出阿里
- 乾貨分享|使用 Istio 實現灰度釋出
- Vue + Webpack 灰度釋出控制VueWeb
- 《資料安全與流通:技術、架構與實踐》新書釋出架構新書
- F5與Openshift整合,實現灰度釋出
- Kubernetes 使用 Ingress-nginx 實現灰度釋出功能Nginx
- 灰度釋出-上線前的最後一公里
- Spark 灰度釋出在十萬級節點上的成功實踐 CI CDSpark
- 雲原生灰度更新實踐
- 如何優雅進行灰度釋出測試?中國工商銀行是這樣實踐的
- 基於Nodejs的前端灰度釋出方案_20190228NodeJS前端
- 手把手教你搭建一個灰度釋出環境
- 分散式中灰度方案實踐分散式
- 最佳實踐|Apache Pulsar 在拉卡拉的技術實踐Apache
- CODING DevOps + Nginx-ingress 實現自動化灰度釋出devNginx
- 掘金技術徵文活動釋出一週,十三篇優秀的徵文出爐 | 掘金技術徵文
- Istio最佳實踐:在K8s上透過Istio服務網格進行灰度釋出K8S
- 架構設計:微服務模式下,實現灰度釋出模式架構微服務模式
- 《可信計算技術最 佳實踐白皮書》釋出,龍蜥助力可信計算技術應用推廣(可下載)
- 一文搞懂灰度釋出與 AB Test 的聯絡與區別
- 重磅釋出 | 《不一樣的 雙11 技術,阿里巴巴經濟體雲原生實踐》電子書開放下載阿里
- React最佳實踐嘗試(一)技術選型React
- Istio技術與實踐04:最佳實踐之教你寫一個完整的Mixer AdapterAPT
- 如何用一個外掛解決 Serverless 灰度釋出難題?Server
- 騰訊 iOA 技術實踐
- 使用npm釋出一個react元件(踩坑實踐)NPMReact元件
- Spring Cloud Alibaba Nacos 之 灰度釋出(思路分享)SpringCloud