serviceport: 80在annotations.nginx.ingress.kubernetes.io/service-match中 ，其代表的是分流規則配置, 一條path 分流規則配置內 ，其oldrules 與 newrules 只能存在其中乙個 ，不能共存
[,],
"oldrules": [,]
},,
],"oldrule": [,]
}][ ,
],"oldrules": [,]
},,
],"oldrules": [,]
}]
當前的設計方案是根據ingress-controller最新版本0.18.0 設計的， 當前ingress-controller 邏輯流程 與 現有的**邏輯流程差別在於upstream 歸於dynamic module 管理， 保證upstream 資料在nginx 在不進行reload 場景下，可以動態維護其ip組。
0.18.0 版本 ingress-controller 邏輯流程
根據邏輯流程以及對當前分流需求分析， 主要要進行兩個模組進行修改：nginx.conf 維護， dynamic configuration 更新
更新nginx.conf , 來保證其支援分流配置； 首先要進行對ingress-controller 進行修改，新增上關於分流配置的**， 之後是對nginx.tmpl 進行修改， 從而保證生成的nginx.conf 能夠有分流配置，nginx reload 操作 只會影響長連線服務， 其他不會影響， 故當前nginx-ingress 支撐長連線服務，則進行灰度分流配置的時候， 需要在晚間進行該操作
ingress-controller **修改達到滿足場景：
根據當前ingress，區分出是否是需要進行分流的灰度場景， 將新舊endpoint 進行區分， 整合進templateconfig 結構體內（還需要加入分流標誌，來保證在nginx.tmpl層面能夠進行判斷）， 並改造結構體，提供關於分流規則判斷
為了分流，其nginx.tmpl需要進行對應修改， 將 $proxy_upstream_name 修改為指定的值；
當前為當前ingress-controller 其某一服務例子， 其 $proxy_upstream_name 對應為
// 或者 return 503; 這個場景是在沒有endpoint
proxy_pass http://upstream_balancer;
if （$rule-new）
if （$rule-old）
更新 dynamicconfiguration ， 主要是通過呼叫http 介面： /configuration/backends 進行全量更新upstream， 為了能夠讓nginx 的server 找到對應的分流server ， 需要在呼叫介面更新upstream 時， 將相應的分流upstream name 傳遞過去， 比如以上述例子，則需要額外新增兩種upstream： cmos-im-xc-svc-test-80-new ， cmos-im-xc-svc-test-80-old
小話灰度方案實現
在日常軟體建設中，我們有時會遇到乙個新舊邏輯 新舊元件灰度切流的過程。如何能夠平滑的切流，相信會是每個開發者面臨的問題。好的，我們進入正題。灰度切流的用例圖很簡單。根據這個用例最直觀的設計就是 在乙個gateway中包含乙個router，通過讀取配置去選擇究竟是實現a還是實現b。使用的是策略模式最直...
恆御分流器作為前端分流裝置的解決方案
背景 隨著運營商骨幹線路頻寬的大幅擴容提公升，高速率介面的快速換代公升級，基於pos鏈路進行監控 測量 業務分析 資料增值等多種應用，也得到了迅速發展。這些業務需要大量的高效能伺服器來處理相關的流量資料，但是單個2.5g 10g甚至是多條10g的資料量是任何一種高效能的單台伺服器都無法處理的。因此可...
網路遊戲使用者分流設計淺淡 一 新手村分流方案
一般網路遊戲為了避免在開服初期大量玩家湧入都會考慮到分流及擴容，針對這部分內容我做乙個簡單的歸納分析。以之前所從事的一款mmog為例，它的設計方式是新手村以副本的形式存在，在伺服器啟動時先建立固定數量的副本，使用者在進入時優先使用這些建立好的副本 如果不夠，根據使用者數和伺服器承受能力不斷的建立副本...