混沌工程之

自混沌工程理念提出来之后，追随者甚多，实践者甚少，这是为什么？因为混沌工程是把双刃剑，稍不留神就会弊大于利，所以大家对混沌工程，特别是生产环境的混沌工程是慎之又慎。

本篇将围绕最小爆炸半径提出3个问题，并给出自己的一些解法。

    混沌工程的五大原则中有一条“在生产环境中进行试验”，混沌工程五级成熟度也把混沌实验的环境（预发布、灰度、生产）作为了评判标准之一，所以这个慢慢趋于生产的递进过程也就成为了行业大部分混沌工程推广的潜规则了。     其实这里面我个人觉得我们本末倒置了，既然最终是落地生产的，那为什么还要经过预发布和灰度的阶段呢，或者说预发布和灰度阶段的混沌有什么意义呢？当然，你给出的结论是“生产的稳定高于一切”、“这种渐进也是一种试错的过程”，那这些理由正是本末倒置的地方！因为忽略了另外一个原则“最小爆炸半径”！如果我告诉你有一种办法可以只让混沌试验影响到你这一个用户，你还会选择这么曲折的落地过程么？所以，如果有条件，请直接上生产环境！ 

    如果一个应用第一次进行混沌实验时最小爆炸半径应该是多大？我个人的答案是“一个用户”。为什么不是一个“QPS”呢？这就涉及到我们为什么要控制最小爆炸半径。原文是这样说的“While breaking things is fun, we do not enjoy causing our customers pain”。因为混沌试验会带来“customers pain”，所以我们要把影响降到最低，也就是说把对用户的影响降到最低，假如只影响到做试验的这一个用户，是不是可以理解为对其它生产用户是零污染的呢，这是最完美的初始最小爆炸半径。为什么不能一个“QPS”？因为流量很可能是轮询进来的，那就会影响到多个用户，爆炸半径是不可控制的。 

    既然方向已经很明确了，就看通过什么方式要精准的控制用户级别的流量了，这个需要前端和后端之间的配合，简单说就是前端给标识，后端根据标识分流。 

    前端需要有一个统一的http框架将代表用户唯一标识的信息（uid、did、手机号等）传递给后端，后端需要一个统一的接入层根据转发策略和收到的标识信息精准的调度流量。     以用户粒度为最小爆炸半径最大的难点在于标识的透传，因为后端对所依赖的后端发起的http是新建的，不会再保留北向传递来的标识信息，针对这个问题有如下几种解法： 

    方案一：统一HttpClientSDK，该方案需要侵入业务代码，适用于项目初期，可以用最小的代价统一依赖包。     方案二：统一网关下沉，服务间的调用都经过网关，这种方式实现技术成本最小，但会牺牲频响。     方案三：级联式混沌环境，该方案运维成本较高，但对研发和应用无侵入。 

     最小爆炸半径是混沌工程进入到生产环境必须面对的拦路虎，也是混沌工程第一个需要解决的难题，以上是给了自己实践中的一些收获和心得，总结为8个字：“直接生产，用户粒度”。