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

 

摘要: 本文做者: 思邪,阿里巴巴中间件技术专家,全程参与2018 双11的技术支撑工做,长期关注RPC及微服务技术领域,擅长系统架构和性能优化。性能优化

需求

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

需求总结下来就是:架构

  • 针对特殊流量能够在链路上按需选择一些应用,从全部机器(公共集群)里圈定一些机器做为特殊流量的专属机器,以便对特殊流量进行特殊支持。
  • 普通流量不进入专属服务器,特殊流量能够按需使用普通服务器
  1. 若是链路上某个应用app_x没有划出专属机器,那么特殊流量和普通流量公用app_x的全部机器(咱们称之为公共集群)。
  2. 若是app_x划了专属机器,可是这些机器由于某种缘由不可达,那么特殊流量能够根据配置的failover策略决定是否使用公共集群。
  • 整个链路上各个应用的划出来的专属机器组成了特殊流量的专属通道,相似公交专用道。
  • 咱们的RPC框架已有的路由功能是在单次调用上生效,基于单次调用的路由功能实现全链路的路由会很是麻烦。因此咱们提出了一个全链路上的作流量隔离的方案Dpath(Dedicated path)。

方案工做机制

咱们分三步来讲明Dpath如何工做:app

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

圈定专属机器

简单来讲,咱们须要的信息就是一个专属环境里包含哪些应用的哪些机器。该信息以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对应的服务器列表,而后随机调用。以下图所示:

dpath4

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

dpath3

整个链路上,一个专属环境里全部应用的专属服务器串起来构成了特殊流量的专属路径。以下图所示:

dpath2

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

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

dpath1

野流量隔离

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

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

总结

Dpath是一个通用的流量隔离方案,能够支持一些须要隔离或者引导流量的场景,好比全链路常态隔离,灰度测试,蓝绿发布等。

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

如下列举一些业务流量隔离的好处:

  • 业务方能够根据业务属性的不一样作不一样的支持:个性的配置,更全的监控等。
  • 重要业务不受其余流量影响,不会由于其余流量突增而致使load高,被限流。
  • 小集群支持单业务,发布,回滚,都更快。当特定业务出问题时,能够更快地响应。

做者: 中间件小哥
原文连接 本文为云栖社区原创内容,未经容许不得转载。 

相关文章
相关标签/搜索