大家最近访问我们网站可能会遇到很多莫名其妙的 Bug。这是因为最近我们网站前端正在进行技术升级，为了保险起见，我们选择 灰度发布，结果翻车了。对不起，我代表编程导航，向大家道歉！
大家最近访问网站可能会遇到很多莫名其妙的 Bug。
幸运的话，还可能会看到 “薛定谔的网站”！
诶，一会儿新页面、一会儿老页面、一会儿又来个报错，不知道你们遇到没有？
具体的 Bug 表现可以看：https://bilibili.com/video/BV1NgpqzQETJ
怎么回事儿呢？
最近我们网站前端正在进行技术升级，为了保险起见，我们选择 灰度发布，先让一小部分用户使用新版本，而不是全量上线。
但是无奈我们目前使用的项目部署平台不支持按比例灰度发布。
为了降低灰度的实现成本，团队心生一计：既然用户访问网站时，要先通过 DNS 服务器解析域名为 IP 地址。
那我只需要在 DNS 解析这边动动手脚，给同一个域名配置 2 条相同类型的解析记录，一条指向新网站、一条指向老网站，再设置不同的权重，这样就通过 DNS 轮询的方式分配了流量。
过程如图：
结果翻车了！
哪怕是同一个用户、同一台电脑访问我们的网站，都有可能出现一会儿新页面、一会儿老页面的情况，用户体验很差；而且由于新老网站技术栈不兼容，还出现了一些奇奇怪怪的 Bug。
这是因为 DNS 轮询本质上是 随机分配，无法绑定用户身份。哪怕同一台电脑，DNS 缓存过期后再次解析，也可能拿到新网站服务器的 IP，导致版本切换。
不过目前这个问题应该已经解决了，大家可以帮我试试看。
编程导航：
解决办法很简单，我们临时更改了 DNS 解析规则的线路类型，将某一运营商（比如电信）的用户统一解析到新版本，其他用户解析到老版本。这样避免了完全随机的情况，解决了同一用户反复切换的问题，达到了按用户群体灰度的效果。
我承认基于 DNS 实现灰度并不优雅，也导致了一些线上 Bug。理想情况下应该根据用户 ID、Cookie 等标识进行一致性分流，可以利用网关、容器编排、或者 CDN 等技术实现灰度。
但标准的灰度方案需要更复杂的基础设施和更高的成本，对于俺们小团队来说，在资源有限的情况下，还是选择了一个 “看似可行” 的简单方案，结果聪明反被聪明误了。
把这次的事故分享出来，也是希望能给同样是小团队的朋友们一些参考。
你们遇到过类似的情况吗？有什么更好的方案推荐？
