共計 2930 個字符,預計需要花費 8 分鐘才能閱讀完成。
本篇內容介紹了“怎么使用 Istio 進行 A / B 測試”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
問題 1:我不相信我的測試
如果測試范圍并沒有完全涵蓋你所更改的應用程序,那么你可能會很快采取行動進行新一輪測試,但也有可能應用程序無法正常運行了。
在理想狀況下,我們都想要確保每個代碼經過全面的測試,否則就不會將功能添加到應用程序中。但是現實總歸是骨感的,我們常常被 ddl 追趕,可能還未編寫或者更新測試,功能就得上傳到項目中了。
解決方案:放慢速度
那么,如何確保我絕大多數用戶不受代碼中潛伏的任何錯誤的影響,又如何進行更改和部署新功能呢?答案是通過先將新版本部署到最少數量的用戶來最大程度地減少這些小問題的輻射范圍。
如果更改能夠按照預期工作的話,你可以緩慢增加使用新版本的用戶百分比。如果各項指標出現問題,你可以輕松回滾你的更改,然后重試。
在沒有 Istio 的情況下可以在 Kubernetes 上運行金絲雀部署嗎?當然沒問題,但是如果要自動化這一過程,你需要完全將自己的精力放在 web 服務器代碼和自定義自動化腳本方面。這樣的操作方式性價比并不高。
Istio 有一些十分優雅的流量分配解決方案,我們可以使用它們在恰當的時間為合適的版本提供適當的客戶端服務,并且我們只需調整其中的 1 個或 2 個參數。
為了實現這一點,你需要設置一個網關入口(Ingress gateway)、一個虛擬服務(virtual service)和一個 destination rule。這將位于一般的部署和服務之上,并為你分配流量。
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: http-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hos
- *
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app
spec:
hosts:
- *
gateways:
- http-gateway
http:
- match:
- uri:
prefix: /my-app
rewrite:
uri: /
route:
- destination:
host: my-app
subset: v1
port:
number: 80
weight: 90
- destination:
host: my-app
subset: v2
port:
number: 80
weight: 10
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: my-app
spec:
host: my-app
subsets:
- name: v1
labels:
version: v1.0.0
- name: v2
labels:
version: v2.0.0
從虛擬服務的權重字段中可以看到,Istio 將根據指定的值在應用程序的兩個版本之間分配流量。這些值的總和必須為 100%,否則,API 將拒絕應用該定義。
然后,你(或者理想情況下,在“持續集成 / 連續交付”流水線中手動執行一個或多個步驟)將調整權重,以將新版本推廣給更多用戶,直到所有請求由新版本滿足為止,并且以前的版本可以停止維護。
通過使用 Istio 的故障注入功能來模擬網絡中斷和實際流量性能下降,還可以將 Istio 集成到您的集成測試策略中。
如果在生產中進行測試的想法給你留下了心理陰影,那一定是你的做法有所欠缺。例如,嘗試在你的虛擬服務規范中添加以下代碼片段以添加一些混亂,然后再找一篇文章來看看怎么用 Istio 解決這樣的混亂。
spec:
hosts:
- my-app
http:
- fault:
delay:
fixedDelay: 7s
percent: 100
route:
- destination:
host: ratings
subset: v2
問題 2:市場策略無法確定發布版本
通常,業務需要針對實際用戶測試應用程序的多個版本。但是有時實在無法搞清楚是哪種營銷策略可以帶來最佳轉化率,或者哪種設計選擇可以帶來最佳的客戶留存率。
使用 Kubernetes,你可以將流量分為兩個版本,但是要想從練習中獲得任何有價值的見解,則再次需要一大堆自定義代碼來獲取相關信息,并以非技術同事可以理解的方式對其進行處理。
解決方案:使用 Istio 進行 A / B 測試
Istio 的流量分配規則可以再次解決這一問題,它與 Prometheus 和 Grafana 的緊密集成可以幫助你獲取直觀的 A / B 測試的結果。一般而言,根據傳入數據包內容的某些部分,幾乎有無數種方法來決定哪些用戶可以獲取你的應用程序的版本。
在這一示例中,我們將使用 User-Agent 字段為不同的瀏覽器提供不同的版本。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app
spec:
hosts:
- *
gateways:
- http-gateway
http:
- match:
- headers:
user-agent:
regex: .*Chrome.*
uri:
prefix: /my-app
rewrite:
uri: /
route:
- destination:
host: my-app
subset: v1
port:
number: 80
- match:
- headers:
user-agent:
regex: .*Mozilla.*
uri:
prefix: /my-app
rewrite:
uri: /
route:
- destination:
host: my-app
subset: v2
port:
number: 80
從上面的代碼中可以看到,使用 Firefox 的用戶將獲得應用程序的版本 1,而 Chrome 用戶將獲得版本 2。如果瀏覽器的“User-Agent”字段不包含“mozilla”或“chrome”,則他們都將不會獲得任一版本。
要為其他客戶提供服務,您需要添加一條默認路由,我將作為練習留給你。(嘿嘿)
如果你不想安裝其他瀏覽器,只是想嘗試一下,則可以使用帶有頭部標志的 curl 偽裝成所需的任何瀏覽器,例如:
curl /my-app -H User-Agent: Chrome
通過更改 user-agent 的值,你可以從命令行測試所有不同的路由。
“怎么使用 Istio 進行 A / B 測試”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站,丸趣 TV 小編將為大家輸出更多高質量的實用文章!