同城雙活-流量分流
阿新 • • 發佈：2022-02-21
-
引言
現階段，在同城頻寬時延問題沒有經過大規模的生產實踐、驗證的情況下，我們只匯入“白名單或1%“的小比例請求流量，進入雙活環境，確保環境有效的（活的），同時能支援“容災切換“。那麼，請求流量如何匯入雙活環境？有哪些分流方法？存在什麼樣的問題和挑戰，需要注意些什麼？本文將從這些角度進行剖析。 -
流量分流方法
流量分流的主要方法有：1、HTTP-DNS
2、公網GSLB（公網DNS+公網F5出口）
3、SLB（F5+Nginx）
4、內網GSLB （內網DNS+內網F5）
5、點對點軟路由（Dubbo/SpringCloud）
2.1 HTTP-DNS
在口袋App渠道終端，通過HttpDNS模組，以“域名”為單位，按白名單或比例進行分流。
說明： 1. HTTP-DNS服務的IP地址列表，內建到APP中。App啟動時，非同步基於IP傳送請求，獲取各域名的對映IP。 2. 前端App傳送業務請求時，HTTP-DNS模組進行攔截，獲得域名對映IP，替代預設的DNS服務。 3. HTTP-DNS服務通過裝置ID返回不同的對映IP，實現白名單或比例分流 4. HTTP-DNS服務雙活，前端偵測模組定時偵測，當預設環境IP不可用時，切換使用雙活環境IP，進行域名對映IP獲取。 侷限性： 1. 依賴App的native能力，不適用於微信公眾號/小程式、PC、純H5等型別的終端渠道 2. 分流策略為全域性策略：以“域名”為單位，後端多個應用系統共享域名，分流策略也就多個應用系統共用，需要協同。 優點： 1. 相對於GSLB(公網DNS）方式，切換速度快，更改策略準實時生效 2. 基於裝置ID分流，也就是“使用者”請求只會進入到同一IDC，不會隨機進入不同的IDC。長遠來看，對於後端應用系統處理跨IDC延時和資料一致性是有利的。
2.2 公網GSLB
通過公網域名解析服務（DNS）進行分流，公網渠道端入口的分流方法：
說明：
1. GSLB服務在域名解析時，按照預先配置的分流規則（按比例或根據客戶端IP按地域），返回不同的域名對映IP，實現請求流量分流
2. GSLB服務本身雙活
侷限性：
1. 公網DNS服務提供方的DNS快取策略的不確定性，會影響分流策略的準確度，以及策略變更生效的時效性
2. 分流策略為全域性策略：以“域名”為單位，後端多個應用系統共享域名，分流策略也就多個應用系統共用，需要協同。
2.3 SLB（F5+Nginx）
SLB（F5+Nginx）通過Nginx配置動態變更，實現流量分流。內網動態分流方法。
說明：
1. 公網接入SLB雙活，實現網際網路出口雙活。上圖示例中，假設域名M由應用A和應用B共用，應用B尚未雙活，則域名M雙活流量中，請求應用B的部分，需要回到觀瀾IDC。
應用B雖未做雙活，但網際網路出口是雙活的，也是有價值的。
2. 內網SLB，上圖示例中，假設應用C通過內網SLB呼叫應用A，需要通過分流策略，將部分流量分流到應用A的雙活叢集。這種情況下，需要在SLB治理平臺上，設定分流策略。
3. 內網SLB，Nginx跨IDC連線雙活叢集所有節點，心跳偵測機制確保及時排除故障節點
4. SLB治理平臺，自身雙活，支援隨時線上變更分流策略
侷限性：
1. 內網系統間呼叫，大部分應用未使用SLB做負載均衡，大部分是直接使用F5。應用使用需要F5後面加Nginx，進行改造接入SLB
優點：
1. 可以按應用系統維度，設定不同的分流策略，且變更實時生效
2. 公網基於域名分流，域名下沒有做雙活的應用，可以通過SLB把雙活環境（福田IDC）流量導回觀瀾IDC，起到一個很好的補充作用
3. 對比內網GSLB(DNS域名解析），內網SLB（Nginx）策略變更實時生效，也不依賴呼叫方，呼叫方無需重啟或策略變更。
2.4 內網GSLB
通過內網DNS域名解析，結合內網F5，實現流量分流
說明：
1. 通過GSLB管理工具，進行分流策略管理。應用呼叫時，進行域名解析時，根據分流策略（按比例）返回不同IP，實現分流。
2. 目前已實現應用雙活的系統，基本上是基於此方案實現。
應用A-->F5-->ESB-->F5(DNS分流)-->應用B
侷限性：
1. 當呼叫方啟用連線池時，將受到呼叫方連線池策略的影響。分流策略可能得不到有效執行，同時策略變更時，策略可能不能生效。
2. 為了保證策略生效，呼叫方有可能需要重啟。
2.5 點對點軟路由
Pafa5(Dubbo)，Halo(SpringCloud)，是通過點對點軟路由方式進行流量分流的。本章節通過Dubbo來描述這塊的解決方案。
說明：
1. 兩套環境，通過服務提供者工具，將對方環境所有服務提供者（IP列表）同步到當前環境的註冊中心，保證當前環境的註冊中心中，有服務提供者的全集。
2. 當應用間進行點對點呼叫時，根據提供者權重或同IDC優先原則，篩選（路由選擇）提供者，獲得可用提供者列表，再進行負載均衡，點對點呼叫。
3. 當某應用沒有做雙活時，雙活環境將獲得預設環境的提供者列表，呼叫回到觀瀾IDC（預設環境），比如：示例圖中的應用C。
4. 當其中某一環境不可用時，對方環境的服務同步者工具偵測到，自動刪除對方環境的提供者。
侷限性：
1. 需要升級Pafa5或Halo的新版本才能支援
- 分流存在挑戰
流量分流，是雙活建設最為重要的課題之一。
3.1 同IDC優先 VS IDC權重
如果從公網渠道入口分流（如：HTTP-DNS），內網執行“同IDC優先原則“，則內網系統間，是不需要設定“分流策略”，
但這前提條件是：主要渠道或呼叫方已完成雙活，業務場景比較全，能有效驗證雙活環境，通過“同IDC優先“方式實現全鏈路雙活。
同IDC優先的優點：雙活環境獨立，流量分流由渠道入口統一控制，內部應用系統不需要單獨做“分流策略”。
如果應用系統的呼叫方或主要接入渠道，都沒有實現雙活，那隻能自己在應用系統維度設定分流策略（IDC權重），匯入部分流量來驗證自己的雙活環境和雙活能力。例如：
那我們到底選用哪一種方案呢？現階段，D+等核心業務系統，接入渠道較多，且多沒有完成雙活，
可以以應用系統為維度，自已獨立驗證雙活能力，建議先使用“IDC權重“方案，後續主要渠道及呼叫方完成雙活後，再切換到“同IDC優先“的方案上來。
以口袋APP為主要渠道的渠道系統，則建議以“同IDC優先“的方案，協同進行全鏈路的雙活建設和驗證。
3.2跨IDC時延和頻寬問題
跨IDC時延和頻寬問題，問題影響有多大，應用系統能否接受，終端使用者體驗能否接受，目前還沒有大規模生產實踐、論證過，暫時是沒有答案的。
現階段，我們只匯入極小部分流量（白名單，百分之一，甚至萬分之一），進入雙活環境，能驗證雙活環境可用，保證它是活的即可。
長期手段，我們慢慢增加匯入的流量，持續監控觀察，持續改進，在實踐過程中，逐步把這個問題解決掉或規避掉。
所以，短期我們可以忽略這個問題。
3.3 白名單分流的支援
白名單分流，是比較安全的雙活環境驗證方式。
目前支援白名單分流的方式，只有HTTP-DNS，且口袋APP是行內的主要C端渠道，場景也比較全。所以要充分利用這個渠道和HTTP-DNS這個方法做雙活分流。
3.4 變更實時生效
公網GSLB、內網GSLB，存在實時生效問題，如果有替代方式，儘量用替代方式。
比如：HTTP-DNS替代公網GSLB，SLB替代內網GSLB。
3.5 B端如何分流
B端合作方渠道，一般通過專線或公網，服務端對服務端連線進行互動，分流方式需要合作方商定。
4.總結
前面，我們分析了各分流方法，及各自優劣，也分析了現階段存在的挑戰和問題，並給出瞭解決辦法，有以下觀點，我們再闡述一下：
1. 現階段，應該儘快把雙活環境搭建起來。大家都搭建起來了，才能執行”同IDC優先“原則，保證雙活環境獨立性，並全鏈路雙活驗證。
2. 現階段，只要匯入極小部分流量，進入雙活環境，保證它是可用的，是活的，就可以了。當容災切換時，儲存手工切換，確保所有流量能即時切入雙活環境。
3. 現階段，只匯入極小部分流量進入雙活環境，先忽略掉跨IDC時延和頻寬問題。容災切換後，雙活環境確保沒有跨IDC流量。
4. 推薦使用：HTTP-DNS、SLB、點對點軟路由（Dubbo/SpringCloud）這三種分流方法。GSLB儘量不使用。
5. "同IDC優先“的策略下，在渠道入口端進行分流，後端應用系統無需設定自己的分流策略，由運維統一變更和協同。
6. “同IDC優先“與”IDC權重“二選一，應用系統可以根據自身情況選擇”IDC權重“，自己設定自身的分流策略，匯入一定比例的流量進入自己的雙活環境。
7. 所有分流方法都需要同時支援這二種策略：“同IDC優先“與”IDC權重“。
8. 現階段，在達到目的的前提下，儘量保持架構簡單，謹防過度設計