什么是smi ，以及对流量的思考

聊smi 之前，先梳理一下，我们遇到的一些问题

当服务只有一层时，以上都还比较容易解决

比如配置个nginx，通过nginx 的upstream 就可以比较轻松地完成负载均衡问题。

但是，场景一旦来到多层依赖后。情况就变得复杂了起来

比如：

Client  -> ServiceA.v1  - 
       |                |-> ServiceB.v1
       |                |-> ServiceB.v2
        -> ServiceA.v2  -

我们暂且两层吧。多了，码字也比较辛苦

ServiceA 依赖服务ServiceB 这时候。恰巧，服务A 有v2 版本要上线，服务B 也有v2版本要上线

这时候，我们先定义Client 有哪些角色呢

他们几个，在不同阶段，对流量的诉求，肯定是不一样的。

以灰度阶段举例:

正常用户，需要走 A.v1 -> B.v1 稳定版本

被灰度的用户 A.v2 -> B.v2

测试人员 A.v1 -> B.v2 A.v2 -> B.v1 A.v2 -> B.v2

说到这里，我们就明白，这不是一个简单问题。

如果我们通过中间部署多个代理来解决这个问题，那么，就会得到，我们需要维护一大堆代理，一大堆奇奇怪怪的规则。如果规则配置错误，那么可能导致灾难性后果。

故，我们需要一套系统来解决，而这套系统，也许就是service mesh

而smi 就是一套为service mesh 设计的，用来做

参考：

只不过，想要用上，得先用上service mesh。而service mesh 确是另外一个大部头。

enjoy :)