灰度釋出-基於nginx的cookie實現
1、概念
灰度釋出是指在黑與白之間,能夠平滑過渡的一種釋出方式。AB test就是一種灰度釋出方式,讓一部分使用者繼續用A,一部分使用者開始用B,如果使用者對B沒有什麼反對意見,那麼逐步擴大範圍,把所有使用者都遷移到B上面來。灰度釋出可以保證整體系統的穩定,在初始灰度的時候就可以發現、調整問題,以保證其影響度。
更詳細的解釋大家可以自行百度一下。
http://baike.baidu.com/link?url=KToM_9SSL7N71bNRoGojDcq4N6JaZBzn37N5406H1OqcUsvveC9yASbqCWIkVqu3x9_wIfyKok4dN646yhRH5Lw-QP9LT4b4YGMj_vqDA7-qDkP_ECjCFaixQzMY-BHW
2、目前實現的方式有三種
- nginx+lua:根據訪問者ip地址區分,由於公司出口是一個ip地址,會出現訪問網站要麼都是老版,要麼都是新版,採用這種方式並不適合;
- nginx:根據權重來分配,實現很簡單,也可以嘗試;
- nginx:根據cookie分流,灰度釋出基於使用者才更合理(本例子採用該種方式)。
3、前期準備
安裝Nginx;
安裝瀏覽器cookie外掛(非必選)
外掛下載地址:
http://www.editthiscookie.com/start/
測試的兩臺伺服器分別為:
default 127.0.0.1:18080
test_1 127.0.0.1:18080
test_2 127.0.0.1:28080
需要監聽的埠為:80,根據轉發過來的cookie(約定為:test_version_code),對應的值來判斷跳轉,具體如下:
判斷如果,test_version_code = t1 , 則跳轉到 127.0.0.1:18080;
判斷如果,test_version_code = t2 , 則跳轉到 127.0.0.1:28080;
upstream test_1{
server 127.0.0.1:18080 max_fails=1 fail_timeout=60;
}
upstream test_2{
server 127.0 .0.1:28080 max_fails=1 fail_timeout=60;
}
upstream default{
server 127.0.0.1:18080 max_fails=1 fail_timeout=60;
}
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
#match cookie
set $group "default";
if ( $http_cookie ~* "test_version_code=t1" ) {
set $group test_1;
}
if ( $http_cookie ~* "test_version_code=t2" ) {
set $group test_2;
}
location / {
root html;
index index.html index.htm;
#gray
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
}
4、驗證
開啟谷歌瀏覽器cookie編輯外掛,如下圖:
我們驗證一下是否設值cookie值正確,F12即可看到:
結束。
相關推薦
灰度釋出-基於nginx的cookie實現
1、概念 灰度釋出是指在黑與白之間,能夠平滑過渡的一種釋出方式。AB test就是一種灰度釋出方式,讓一部分使用者繼續用A,一部分使用者開始用B,如果使用者對B沒有什麼反對意見,那麼逐步擴大範圍,把所有使用者都遷移到B上面來。灰度釋出可以保證整體系統的穩
灰度釋出系統的實現
灰度釋出,已經不是一個很新的概念了.一個產品,如果需要快速迭代開發上線,又要保證質量,保證剛上線的系統,一旦出現問題那麼可以很快的控制影響面,就需要設計一套灰度釋出系統.灰度釋出系統的作用在於,可以根據自己的配置,來將使用者的流量導到新上線的系統上,來快速驗證新的功能修改,而一
Istio 太複雜?KubeSphere基於Ingress-Nginx實現灰度釋出
在 Bookinfo 微服務的灰度釋出示例 中,KubeSphere 基於 Istio 對 Bookinfo 微服務示例應用實現了
基於ambassador實現K8S灰度釋出
為什麼需要灰度釋出 灰度釋出(又名金絲雀釋出)是指在黑與白之間,能夠平滑過渡的一種釋出方式。在其上可以進行A/B testing,即讓一部分使用者繼續用產品特性A,一部分使用者開始用產品特性B,如果使用者對B沒有什麼反對意見,那麼逐步擴大範圍,把所有使用者都遷移到B上面來。 總結下一些應用場景: 微服務依賴
K8S基於ingress-nginx實現灰度釋出
之前介紹過使用ambassador實現灰度釋出,今天介紹如何使用ingre-nginx實現。 介紹 Ingress-Nginx 是一個K8S ingress工具,支援配置 Ingress Annotations 來實現不同場景下的灰度釋出和測試。 Nginx Annotations 支援以下 4 種 Cana
K8s 1.18.6版本基於 ingress-nginx 實現金絲雀釋出(灰度釋出)
# K8s 1.18.6版本基於 ingress-nginx 實現金絲雀釋出(灰度釋出) ## 環境 | 軟體 | 版本 | | ------------------------ | ------- | | kubernetes |
Openresty+redis實現灰度釋出
一、架構 環境: 192.168.189.131:tomcat服務 192.168.189.132:tomcat服務 192.168.189.130:OpenResty服務、redis服務 流程: 請求到達openresty,openresty從redis獲取白名單,然後判斷請求地址是否再白名單,
Apollo學習(四):建立灰度配置並與zuul協作實現灰度釋出
說明 通過之前對Apollo的學習,對Apollo的使用已經有了大概的瞭解。本篇博文通過與Spring Cloud Zuul作為閘道器配合,Apollo配置灰度例項來學習灰度釋出。本文的核心是以github上的灰度釋出開源專案ribbon-discovery-filter-sprin
採用輕量ServiceMesh實現灰度釋出的實踐
軟體總會有缺陷的,解決問題的同時往往會引入新的問題,關鍵是看這些問題是否在我們的控制範圍內,“灰度釋出”就是讓問題受控的方法之一。 前言 我們的 CTO 經常說:“研發團隊最首要的任務是提供穩定的服務,然後才是提供符合客戶需求的、易用和低成本的產品”
基於springcloud服務灰度釋出(二)
灰度鏈路測試 文章目錄 灰度鏈路測試 1測試介面實現 2 繞過測度介面攔截 2.1 建立filter 或HandlerInterceptor 代理 2.2 處理是否跳過攔截
Linkerd + Namerd,實現Kubernetes 叢集的灰度釋出_Kubernetes中文社群
主要內容源於 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ,砍掉了 Jenkins 等附加部分,更換了更
zuul灰度釋出功能實現
灰度釋出、藍綠髮布、金絲雀釋出各是什麼意思,可以看這篇http://www.appadhoc.com/blog/product-release-strategy/。基於eureka、ribbon實現灰度釋出,是這一篇要講的知識。我們要釋出版本了,在不確定正確性的情況下,我們選
乾貨|採用Istio實現灰度釋出(金絲雀釋出)
點選上方“中興開發者社群”,關注我們 每天讀一篇一線開發者原創好文 灰度釋出(又名金絲雀釋出)介紹 當應用上線以後,運維面臨的一大挑戰是如何能夠在不影響已上線業務的情況下進行升級。做過產品的同
利用nginx+lua+memcache實現灰度釋出
一、灰度釋出原理說明 灰度釋出在百度百科中解釋: 灰度釋出是指在黑與白之間,能夠平滑過渡的一種釋出方式。AB test就是一種灰度釋出方式,讓一部分使用者繼續用A,一部分使用者開始用B,如果使用者對B沒有什麼反對意見,那麼逐步擴大範圍,把所有使用者都遷移到B上面 來。灰度釋出可以保證整體系統的穩定,在初
Linkerd + Namerd,實現Kubernetes 叢集的灰度釋出
主要內容源於 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ,砍掉了 Jenkin
基於 Istio 與 Kubernetes 對應用進行灰度釋出與 Tracing
灰度釋出,是指在黑與白之間,能夠平滑過渡的一種釋出方式。通俗來說,即讓產品的迭代能夠按照不同的灰度策略對新版本進行線上環境的測試,灰度釋出可以保證整體系統的穩定,在初始灰度的時候就可以對新版本進行測試、發現和調整問題,以保證其影響度。KubeSphere 基於 Istio 提供了藍綠部署、金絲雀釋出、流量映象
【Nginx】實現負載均衡、限流、快取、黑白名單和灰度釋出,這是最全的一篇了!
## 寫在前面 > 在《[【高併發】面試官問我如何使用Nginx實現限流,我如此回答輕鬆拿到了Offer!](https://mp.weixin.qq.com/s?__biz=Mzg3MzE1NTIzNA==&mid=2247485388&idx=1&sn=0854d3f9b4
手把手教你在 TKE 叢集中實現簡單的藍綠髮布和灰度釋出
## 概述 如何在騰訊雲 Kubernetes 叢集實現藍綠髮布和灰度釋出?通常要向叢集額外部署其它開源工具來實現,比如 Nginx Ingress,Traefik 等,或者讓業務上 Service Mesh(服務網格),利用服務網格的能力來實現。這些方案多多少少都是需要一點點門檻的,如果藍綠髮布或灰度釋出
01 . OpenResty簡介部署,優缺點,壓測,適用場景及用Lua實現服務灰度釋出
#### 簡介 > OpenResty® 是一個基於 [Nginx](http://openresty.org/cn/nginx.html) 與 Lua 的高效能 Web 平臺,其內部集成了大量精良的 Lua 庫、第三方模組以及大多數的依賴項。用於方便地搭建能夠處理超高併發、擴充套件性極高的動態 Web 應
架構設計:微服務模式下,實現灰度釋出模式
本文原始碼:[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、基本邏輯 請求通過8001