對不起，我代表編程導航，向大家道歉！

大家最近訪問網站可能會遇到很多莫名其妙的 Bug。

幸運的話，還可能會看到 “薛定諤的網站”！

誒，一會兒新頁面、一會兒老頁面、一會兒又來個報錯，不知道你們遇到沒有？

具體的 Bug 表現可以看：

怎么回事兒呢？

最近我們網站前端正在進行技術升級，為了保險起見，我們選擇 灰度發布，先讓一小部分用戶使用新版本，而不是全量上線。

但是無奈我們目前使用的項目部署平臺不支持按比例灰度發布。

為了降低灰度的實現成本，團隊心生一計：既然用戶訪問網站時，要先通過 DNS 服務器解析域名為 IP 地址。

那我只需要在 DNS 解析這邊動動手腳，給同一個域名配置 2 條相同類型的解析記錄，一條指向新網站、一條指向老網站，再設置不同的權重，這樣就通過 DNS 輪詢的方式分配了流量。

過程如圖：

結果翻車了！

哪怕是同一個用戶、同一臺電腦訪問我們的網站，都有可能出現一會兒新頁面、一會兒老頁面的情況，用戶體驗很差；而且由于新老網站技術棧不兼容，還出現了一些奇奇怪怪的 Bug。

這是因為 DNS 輪詢本質上是 隨機分配，無法綁定用戶身份。哪怕同一臺電腦，DNS 緩存過期后再次解析，也可能拿到新網站服務器的 IP，導致版本切換。

不過目前這個問題應該已經解決了，大家可以幫我試試看。

編程導航：

解決辦法很簡單，我們臨時更改了 DNS 解析規則的線路類型，將某一運營商（比如電信）的用戶統一解析到新版本，其他用戶解析到老版本。這樣避免了完全隨機的情況，解決了同一用戶反復切換的問題，達到了按用戶群體灰度的效果。

我承認基于 DNS 實現灰度并不優雅，也導致了一些線上 Bug。理想情況下應該根據用戶 ID、Cookie 等標識進行一致性分流，可以利用網關、容器編排、或者 CDN 等技術實現灰度。

但標準的灰度方案需要更復雜的基礎設施和更高的成本，對于俺們小團隊來說，在資源有限的情況下，還是選擇了一個 “看似可行” 的簡單方案，結果聰明反被聰明誤了。

把這次的事故分享出來，也是希望能給同樣是小團隊的朋友們一些參考。

你們遇到過類似的情況嗎？有什么更好的方案推薦？

更多編程學習資源