灰度路由用得好，发布就算出岔子也能先圈一小撮
新版本上线，直接全量放出去，一旦有暗病，所有用户一起踩。灰度路由就是先把一小撮流量引到新版本，看着稳了再慢慢放大，出了岔子影响也圈在那一小撮里。一、先放极小比例
灰度从百分之一甚至更低开始，看住了再往上加。加的节奏比比例本身更关键，一口气加太多，等于没灰。小比例跑几天，那些偶发的问题才有机会露头。回滚预案写清楚，写清楚的人遇到事才不手忙脚乱。指标先定哪些要看，定太多了反而没人看，没人看等于没采。
灰度的人群要能标识，标识不清就分不出哪批是实验组。标识清楚了，监控里能把新版本的数据单拉出来看，看它的错误率、耗时是不是和老版本一个水平。灰度先放百分之一，看住了再往上加，加的节奏比比例更关键。降级影响要知会下游，下游不知情会以为自己这边出了毛病。
二、异常自动切回
新版本错误率超了预设的线，要能自动切回老版本。切回要快，慢了用户已经感知到不对，感知到了口碑就掉，掉下去再拉回来比预防贵得多。灰度流量打标，打标后在监控里能单独拉出来看走势。调用链打通后，慢请求能追到具体哪一跳拖了后腿。
切回之后老版本要能稳住，别因为刚被切回来就出别的状况。两套版本都得过基本盘，基本盘稳了，灰度才是一个安全网，而不是换个方式冒险。灰度人群要能标识，标识不清就分不出哪批是实验组。频繁熔断说明上游真撑不住，光熔断不扩容只是延后爆点。
三、指标提前定
灰度前先把要看的指标定下来，定了的那个数超了才报警。不报警等于没灰，出了事还是靠用户反馈，用户反馈到你知道，中间已经丢了不止一波人。小范围试出的问题，修完要在同一批再验一遍才放更大范围。监控面板按角色分，值班的和开发的关注点不一样，混着反而乱。
指标别只看错误率，耗时、资源占用一起看。有的新版本错误率没变，但耗时悄悄涨了，涨到一定值用户就觉得卡，卡了就走，走了你还以为版本挺稳。新版本异常自动切回老版本，切回要快，慢了用户已经感知。熔断状态要可见，看不见状态的人还在往那个坑里发请求。
四、多版本配置分开
新老版本并存时，各自的配置要分开管。混用一套，改了新版本的参数把老版本也带歪，老版本本来稳稳的，被这么一拖也跟着出状况，状况叠加更难治。熔断阈值别拍脑袋，拍出来的数往往和实际扛不住的点差很远。
配置里标清版本归属，改哪版只动哪版。别图省事共用，共用一次省了十分钟，后面排查多花两小时，两小时里用户还在替你的省事买单。灰度指标提前定，定了的那个数超了才报警，不报警等于没灰。降级粒度要细，粗了会把不该砍的能力一起砍掉，体验更差。
五、窗口别拖太长
灰度窗口拉太长，两版不一致的地方越积越多。积到后面，你都分不清线上到底跑的什么状态，回滚也没个干净的点，只能硬着头皮继续灰，灰成了长期半拉子。降级方案先备好，备着的那个开关平时不用，急了才敢按。
回滚预案写清楚，写清楚的人遇到事不手忙脚乱。预案里写明触发条件、切回步骤、验证方式，照着做就行，不用现场拍脑袋，拍脑袋容易拍出更大的乱子。多版本并存时配置分开管，混用会把两个版本的参数搞串。演练时故意触发熔断，触发过才信这套机制真兜得住。
六、流量打标看走势
灰度流量打上标记，标记后在监控里能单独拉走势。走势平了再放大，走势一翘头就停，停了查原因，查明白了再决定下一步，步子乱了全靠运气。熔断后要能自愈，自愈的逻辑写清楚，写清了才不用半夜爬起来。
小范围试出的问题，修完要在同一批流量里再验一遍。验过了才敢放到更大范围，不验就放大，等于把没验证过的修复又赌了一次，赌输了的代价还是用户担。灰度窗口别拉太长，拖久了两版不一致的地方越积越多。恢复后慢慢放量，一下子全放回去刚稳下来的系统又会被冲。
灰度路由的本质是给发布加一道缓冲，缓冲用好了，坏版本伤不到多数人。比例、标识、切回、指标、配置、窗口，六件事做细，灰度才真是保护伞，不是走过场的形式。 感谢楼主无私分享经验，少走了很多弯路，对我们帮助特别大。 逻辑严谨，条理分明，一看就是经过认真思考和整理的内容。
页:
[1]