百万级qps网关服务的调度策略实践

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

为什么要建设Janus

部署拓扑：

核心问题

流量调度方案设计

为了将服务的转发规则更加清晰，Janus将路由分为了三级（与nginx类似）：

由上面的挑战分析可知：

通过树路由支持的部分规则如下：

上述的简单路由规则可以满足90%+的业务需求，但是对于类似`从某时刻后，将API1的A机房和B机房的流量切30%到C机房`这种需求是满足不了的。因此，在特征匹配阶段可以通过`变量表达式`+`条件表达式`进行精细化匹配。

变量表达式

为了能根据系统里面的常见特征进行精细化匹配，首先我们要对系统里面的常见特征进行描述。例如：

但是当特征越来越多的时候，就会略显臃肿，存在的特征变量越来越多，这时候Janus引入了分级的概念，比如：

如图所示，就可以用${request.query.id}来表示本次请求中key为id的query值。并且如上的特征变量是可以扩充的，每个使用方可以根据自己的系统差异、环境差异定义自己的特征变量体系。

条件表达式

有了上面实现的变量表达式，我们就可以用$描述我们需要的特征变量了，但是如何对这些特征变量进行操作呢？

Janus的方案是定义一门极简的语言（无论是用yacc等一类的生成语法分析的工具，还是自己做词法分析、语法分析，实现都比较简单，这里不再赘述实现细节），只支持逻辑运算+函数调用，部分例子如下：

函数调用：

逻辑运算：

性能对比

通过如上方案介绍可以看出，采用从控制面下发表达式的方式，可以满足绝大部分场景的需求，但是，对性能影响如何呢？ 

在数据面接收到控制面下发转发规则时，首先会对变量表达式和条件表达式进行编译，映射成go的代码，在后续运行时，与直接调用原生的go语言差异并不大。对比数据如下：

条件表达式：

"random(0,100) || random(100,100)"

对应的benchmark数据：

goos: windowsgoarch: amd64cpu: 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHzBenchmarkRandom-8       35817918            34.52 ns/op        0 B/op          0 allocs/op

原生go代码：

(0 > rand.Intn(100)) || (100 > rand.Intn(100))

对应的benchmark数据：

goos: windowsgoarch: amd64cpu: 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHzBenchmarkRawRandom-8     39136900          31.63 ns/op         0 B/op         0 allocs/op

可以看到使用表达式与使用原生go代码在性能上相差不到10%，区别并不是特别大。 

方案泛化

以容灾插件为例，用户可以把容灾插件配置在任意路由规则上，但是大家认定的触发容灾的规则可能不一样，比如：

一方面，我们想做一个通用的容灾插件，另一方面，大家的触发规则的标准又千奇百怪、各不相同。怎么解决这个矛盾呢？

Janus的答案是：把控制权交给用户，用户配置容灾插件的时候同时配置一个条件表达式，只有条件表达式返回true，才会运行容灾逻辑。

上面的问题对应的下发配置如下：

这样就做到了既是一个通用容灾插件，又可以做到个性化的触发逻辑。

当我们想做一个通用的redis缓存插件时，存取逻辑比较简单：

// 请求下游前if data, ok := redis.Get(key); ok {    return data}
// 请求下游data := reqeust(xxx)
// 请求下游后redis.Set(key, data)

但是，与上面的插件面临的问题类似，通用缓存插件的key怎么定义呢？ 

解决思路是用变量表达式来把key的定义交给用户，用户配置缓存插件的时候同时配置key的规则，比如：

这样就解决了通用缓存插件中的通用与个性化之间的矛盾。 

展望

在Janus网关服务中，通过常规路由规则+变量表达式+条件表达式的方式实现了各种流量调度策略，并将方案泛化到了各种其他功能的实现上，支撑了几百万QPS的流量及众多使用方的接入。通过已经实现的系统变量及规则的组合，基本可以实现任意功能，但是当需要新的规则时，则需要在Janus中上线新的条件表达式实现。为了进一步强化Janus中的动态配置表现能力，Janus正在进行表示式与Go官方标准库的无缝打通。这样就可以在控制面进行更加灵活的配置下发动态编程能力，满足更广泛的需求。 

如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享

·END·

相关阅读：
一张图看懂微服务架构路线
基于Spring Cloud的微服务架构分析
微服务等于Spring Cloud？了解微服务架构和框架
如何构建基于 DDD 领域驱动的微服务？
小团队真的适合引入SpringCloud微服务吗？
DDD兴起的原因以及与微服务的关系
微服务之间的最佳调用方式
微服务架构设计总结实践
基于 Kubernetes 的微服务项目设计与实现
微服务架构-设计总结
为什么微服务一定要有网关？
主流微服务全链路监控系统之战
微服务架构实施原理详解
微服务的简介和技术栈
微服务场景下的数据一致性解决方案
设计一个容错的微服务架构