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

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

需求

在今年的双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对应的服务器列表,然后随机调用。如下图所示:

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高,被限流。
  • 小集群支持单业务,发布,回滚,都更快。当特定业务出问题时,可以更快地响应。
相关文章
|
弹性计算 监控 API
新浪微博上云实践:极端流量下的峰值应对与架构挑战
在混合云架构中,核心关键是专线,它是实现内部与公有云之间弹性的核心。目前微博和阿里云之间已经拉通了多条专线,日常的核心消息通过多机房的消息组件同步到阿里云缓存中,实现前端层面和缓存层面的弹性伸缩。在混合云的模式下,微博目前采用了两种部署方案。
8744 0
|
5月前
|
容灾 安全 关系型数据库
618大促数据流量高峰来袭,你的核心业务做好容灾措施了吗?
一年一度的618大促销即将到来,在核心业务高峰期间,电商平台将迎来巨大的访问量与交易压力,保证在线交易业务的高可用,是大促支撑系统的重中之重。为了确保企业的核心业务在这个关键时刻平滑运行,避免潜在的数据丢失风险,企业需要实施一个稳健的容灾计划。阿里云数据传输服务DTS+云数据库RDS备库强强联合,能够搭建核心业务数据的容灾链路,保证核心交易业务数据的高可用,最大化确保618期间核心业务的顺畅和数据的安全,让企业能够安心迎接商业高峰所带来的挑战。
487 6
|
11月前
|
Kubernetes Cloud Native 容灾
携程乐鸿辉:混合云弹性如何帮助携程应对业务的低迷与快速恢复
2023年10月31日-11月2日,2023云栖大会在中国杭州·云栖小镇举行,携程容器与混合云研发总监乐鸿辉在【云服务器 & 计算服务】专场中带来了题为《混合云弹性如何帮助携程应对业务的低迷与快速恢复》的主题演讲,分享了携程的云原生之旅、混合云弹性实践以及最终实践效果。
|
消息中间件 Cloud Native 中间件
云原生重磅产品组合!5分钟打造应对流量洪峰的商城交易系统
云原生重磅产品组合!5分钟部署一个微服务电商商城,领社区好礼!
1009 7
|
消息中间件 负载均衡 Java
5分钟轻松打造应对流量洪峰的稳定商城交易系统
本实验通过SAE极速部署一个微服务电商商城,同时结合RocketMQ异步解耦、削峰填谷的能力,带大家体验面对流量洪峰仍旧稳定可靠的商城交易系统!
|
消息中间件 运维 应用服务中间件
5分钟轻松打造应对流量洪峰的稳定商城交易系统实验场景
本实验通过SAE极速部署一个微服务电商商城,同时结合RocketMQ异步解耦、削峰填谷的能力,带大家体验面对流量洪峰仍旧稳定可靠的商城交易系统!
355 0
|
双11
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.2 大促保障最佳实践——4.2.2 双十一快递业务峰值晴雨表
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.2 大促保障最佳实践——4.2.2 双十一快递业务峰值晴雨表
|
Prometheus 监控 数据可视化
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.2 大促保障最佳实践——4.2.5 大促保障全链路监控
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.2 大促保障最佳实践——4.2.5 大促保障全链路监控
107 0
|
弹性计算 NoSQL 关系型数据库
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.2 大促保障最佳实践——4.2.4 大促保障故障&预案演练
《快递行业云上技术服务白皮书》——4. 快递行业技术服务最佳实践——4.2 大促保障最佳实践——4.2.4 大促保障故障&预案演练
102 0
|
运维 监控 安全
《2023云原生实战案例集》——06 医疗健康——谱尼测试 基于SAE实现业务快速上线并从容应对流量洪峰
《2023云原生实战案例集》——06 医疗健康——谱尼测试 基于SAE实现业务快速上线并从容应对流量洪峰
下一篇
无影云桌面