流量隔离方案 Dpath 护航双十一新零售

需求

在今年的双11准备期间，业务同学提出要针对新零售进行特殊的保障，希望新零售过来的流量，单独进入到一批机器，和其他普通流量隔离开来，这对新零售系统稳定性提出更高的要求。

需求总结下来就是：

• 针对特殊流量可以在链路上按需选择一些应用，从所有机器（公共集群）里圈定一些机器作为特殊流量的专属机器，以便对特殊流量进行特殊支持。
• 普通流量不进入专属服务器，特殊流量可以按需使用普通服务器

1. 如果链路上某个应用app_x没有划出专属机器，那么特殊流量和普通流量公用app_x的所有机器（我们称之为公共集群）。
2. 如果app_x划了专属机器，但是这些机器因为某种原因不可达，那么特殊流量可以根据配置的failover策略决定是否使用公共集群。

• 整个链路上各个应用的划出来的专属机器组成了特殊流量的专属通道，类似公交专用道。
• 我们的RPC框架已有的路由功能是在单次调用上生效，基于单次调用的路由功能实现全链路的路由会非常麻烦。所以我们提出了一个全链路上的做流量隔离的方案Dpath(Dedicated path)。

方案工作机制

我们分三步来说明Dpath如何工作：

• 圈定专属服务器
• 识别特殊流量
• 在链路上引导流量到对应的服务器

圈定专属机器

简单来说，我们需要的信息就是一个专属环境里包含哪些应用的哪些机器。该信息以JSON形式存放在配置中心，样本如下：

{
"enable": true,
"envRules": [
    {
        "envName": "newRetail",
        "failoverPolicy": 0,
        "envAppRules": [
            {
                "appName": "app1",
                "ips": [ ],
                "machineGroups": [
                    "app1_newRetail_host"
                ]
            },
            {
                "appName": "app2",
                "ips": [ ],
                "machineGroups": [
                    "app2_newRetail_host"
                ]
            },
            {
                "appName": "app3",
                "ips": [ ],
                "machineGroups": [
                    "app3_newRetail_host"
                ]
            },
            {
                "appName": "newRetailEntryApp",
                "ips": [ ],
                "machineGroups": [
                    "newRetailEntryApp_host"
                ]
            }
        ]
    }
]
}    

上述配置申明了一个名为newRetail的专属环境，里边包含app1,app2,app3,newRetailEntryApp四个应用以及对应的机器。

Dpath工具包会订阅该配置，各个中间件使用Dpath工具包即可获知所需的信息。

识别流量

Dpath通过trace模块(全链路的trace功能，可以在链路上传递数据)携带的dpath_env属性来识别当前流量属于哪一个专属环境。具体如何根据请求信息映射到一个专属环境是业务逻辑，由业务同学完成。这个识别动作可以放在如下三个地方：

• Nginx

可以根据http请求信息来识别流量。根据业务规则实现请求到dpath_env的映射，通过Nginx模块生成将env信息添加到trace模块的上下文

• 入口应用

中间件取环境信息如果为空，默认会使用当前机器所属的环境。所以如果入口应用确定，那么将整个入口应用划到专属环境即可。目前新零售都是这种模式。

• 业务代码

业务代码可以根据需要设置trace模块上下文中的的dpath_env，随时改变流量所属的环境。

引导流量

dpath只定义了机器，环境，以及流量的关系，并没有规定如何引导流量。引导流量由各个中间件自行实现。

这里只以rpc为例说明如何基于Dpath的规则来引导流量到对应的服务器。

为了方便理解，先忽略RPC其他的路由逻辑，看最简单情况下，单次调用的处理。没有Dpath功能时，RPC客户端就是从注册中心拿到service对应的服务器列表，然后随机调用。如下图所示：

增加Dpath功能之后，服务名到服务器的映射中间插入了一个dpath_env的逻辑。RPC客户端先根据请求上下文中的环境信息选中对应环境的地址，然后随机调用。如下图所示：

整个链路上，一个专属环境里所有应用的专属服务器串起来构成了特殊流量的专属路径。如下图所示：

• newRetailEntryApp进入的newRetail流量使用专属机器
• 链路上没有划机器给newRetail的应用，使用公共集群

RPC之外，消息等中间件，都用各自的方式达到了类似的隔离效果。这里不再赘述细节。下面只提供一个RPC和消息支持Dpath的效果简图：

野流量隔离

根据上面的描述，RPC的隔离逻辑是在客户端生效。那么如果客户端没升级的话（很难快速协调所有客户端统一升级），就会有未知流量打到专属服务器，老客户端过来的不符合规则的流量我们称之为野流量。

为了解决野流量问题。注册中心的同学在发布订阅功能的基础上，提供了一个namespace功能。我们会把专属服务器的服务发布到Dpath这个namespace下，普通服务器默认发布到default这个namespace。新版本的客户端会订阅default+dpath两个namespace的数据，相当于拿到全量地址。而注册中心保证老的客户端只能看到default空间下的数据，这样就不会有野流量达到专属服务器了。

总结

Dpath是一个通用的流量隔离方案，可以支持一些需要隔离或者引导流量的场景，比如全链路常态隔离，灰度测试，蓝绿发布等。

目前业务方主要是在全链路上按业务属性进行常态流量隔离，已经在几个新零售场景线上使用，并且经历了双11的考验。

以下列举一些业务流量隔离的好处：

• 业务方可以根据业务属性的不同做不同的支持：个性的配置，更全的监控等。
• 重要业务不受其他流量影响，不会因为其他流量突增而导致load高，被限流。
• 小集群支持单业务，发布，回滚，都更快。当特定业务出问题时，可以更快地响应。

阅读原文​​​​​​​

更多技术干货 请关注阿里云云栖社区微信号 ：yunqiinsight