在《BFE 和 Nginx 有什么差别?转发模型的比照》中,对 BFE 的转发模型进行了具体的阐明。
在 BFE 转发的过程中,“转发表”是一个十分重要的组件。在 BFE 中为每个租户保护一张独立的“转发表”,在转发表中蕴含多条程序执行的转发规定。
在 2015 年后,BFE 转发表的设计没有做过大的批改,除了减少一些“条件原语”(什么是“条件原语”,见 BFE 开源我的项目帮忙文档 中的阐明)。往年,咱们对转发表做了一个较大的降级。
1. 转发表降级的背景
之前 BFE 转发表的劣势是:
(1) 转发表在多个租户间互相独立,升高了转发表的复杂性和保护老本
(2) 基于 BFE 特有的条件原语和条件表达式,能够形容非常复杂的转发条件
(3) 在转发表内,转发规定的程序执行,非常容易管制
但 BFE 的转发表也有一个缺点,就是无奈反对较大规模的转发表。程序执行的算法复杂度为 O(N),当转发表中规定的数量达到肯定规模(上百条),会察看到性能有显著的降落。
这个问题在设计之初就是晓得的,然而因为之前的应用场景中一个租户内转发规定的数量都比拟少,这方面的问题并不突出。往年在某个应用场景中,单个租户的转发规定数量达到了几百条、甚至上千条,性能降落的景象比拟显著,这就给转发表的优化降级价发明了契机。
2. 转发表的新计划
在降级后,BFE 每个租户的转发表蕴含 2 局部:
(1) 根底规定表 :可应用域名(Host) 和门路 (Path) 作为匹配条件。反对最长匹配准则。
(2) 高级规定表:反对应用申请中的多种信息做匹配。反对程序匹配。在高级规定表中能够设置默认规定。
和原计划相比,BFE 原来的转发表成为“高级规定表”,持续放弃原来机制形容能力强、执行顺序控制能力强的劣势;新增的“根底规定表”,应用树形查找,匹配速度快,能够反对较大数量(几千甚至上万)转发规定的疾速查找。
依据实测,在单租户内规定规模为 3000 条(这些规定只应用域名和门路作为匹配条件)的状况下,应用根底规定表比原来的计划性能晋升了 5 倍。
上面重点介绍引入根底规定表后的变动。对于高级规定表的状况,请大家参考 BFE 开源我的项目中原有的材料。
3. 转发表内的优先级
在根底规定表和高级规定表之间有明确的优先级。BFE 会依照根底规定表、高级规定表的程序来查找,以确定指标集群。在根底规定表中,也能够将某条规定的指标集群设置为“ADVANCED_MODE”(高级模式)。如果在根底规定表中匹配到这条规定,则转至高级规定表进一步匹配。
具体的匹配程序见下图。
4. 根底规定表
根底规定表由多条“根底规定”组成。
- 根底规定的匹配条件包含域名 (host) 和门路 (path) 两个局部。
- 目标集群通过集群名称来指定,也能够设置为“ADVANCED_MODE”转至高级规定表持续匹配。
- 多条根底规定之间没有前后程序关系,而是基于准确优先的准则。
根底规定表的具体匹配规定,见 BFE 开源我的项目文档中“集群间分流”中的阐明。
上面是根底规定的表的一个例子,用于帮忙大家了解根底规定表的匹配过程。
有四条根底规定,别离为:
- 规定 1:host 条件:*.test1.com,path 条件:空值,指标集群:StaticCluster
- 规定 2:host 条件:*.b.test1.com,path 条件:/interface/*,指标集群:PhpCluster
- 规定 3:host 条件:*.b.test1.com,path 条件:/*,指标集群:StaticCluster
- 规定 4:host 条件:www.test1.com,path 条件:/interface/d,指标集群:PhpCluster
收到一个申请,申请 URL 为 vip.b.test1.com/interface/d,匹配的程序如下:
-
-
首先对 host(vip.b.test1.com)进行匹配:
- 1.1 对 host 做 准确匹配,未匹配胜利
- 1.2 对 host 做 通配符匹配 ,发现申请的 host(vip.b.test1.com) 能够满足规定 2 和规定 3 的 host 条件。
-
-
-
持续对 path(/interface/d)进行匹配:
- 2.1 对 path 做 准确匹配,未匹配胜利
- 2.2 对 path 做 前缀匹配 ,发现申请的 path(/interface/d) 能够满足规定 2 和规定 3 的 path 条件。依据最长匹配准则,匹配到从左开始有最多路径元素的那条规定,即规定 2。
-
匹配完结,在根底规定表中命中规定 2。依据规定 2 的设置,将申请转发到集群 PhpCluster。
5. 一个例子
上面举一个例子,综合应用了根底规定表和高级规定表的能力。
产品线 demo,蕴含多种服务集群:Demo-A, Demo-B, Demo-C, Demo-D,Demo-E。
冀望的转发逻辑条件如下:
- 对于 host 为 www.a.com,path 为 ”/a/*” (除了 ”/a/b”)的申请,转发至 Demo- A 集群
- 对于 host 为 www.a.com,path 为 ”/a/b” 的申请,转发至 Demo- B 集群
- 对于其余 host 为 *.a.com 的申请,转发至 Demo- C 集群
- 对于 host 为 www.c.com 的申请,转发至 Demo- D 集群
- 针对 Demo- D 集群,另外开启了一个灰度集群 Demo-D1。如果 cookie 中蕴含 deviceid,且这个 cookie 的值以“x”结尾,则转发至 Demo-D1
- 其它申请,都发往 Demo-E
对应以上要求,根底规定表的配置为:
host 条件 | path 条件 | 指标集群 |
---|---|---|
www.a.com | /a/* | Demo-A |
www.a.com | /a/b | Demo-B |
*.a.com | * | Demo-C |
www.c.com | * | ADVANCED_MODE |
在根底规定表中,多条规定之间是无序的。匹配程序见下面对于根底规定匹配程序的阐明。
针对 Demo-D1 集群的灰度公布,因为须要应用 cookie 中的信息,所以应用 ADVANCED_MODE 将满足条件的申请透传到高级规定表持续解决;在不须要灰度公布的时候,在根底规定表中指标集群能够写为 Demo-D。
高级规定表的配置为:
匹配条件 | 指标集群 |
---|---|
req_host_in(“www.c.com”) && req_cookie_value_prefix_in(“deviceid”, “x”, false) | Demo-D1 |
req_host_in(“www.c.com”) | Demo-D |
default | Demo-E |
在高级规定表中,多条规定之间是有序的。须要将转发给 Demo-D1 的规定放在后面。
在高级规定表中蕴含默认规定,对于没有命中其它规定的申请将被转发到 Demo-E。
以上配置信息,对应的配置文件(/conf/server_data_conf/route_rule.conf)如下:
{
"Version": "1.0",
"ProductRule": {
"demo": [
{"Cond": "req_host_in(\"www.c.com\") && req_cookie_value_prefix_in(\"deviceid\", \"x\", false)",
"ClusterName": "Demo-D1"
},
{"Cond": "req_host_in(\"www.c.com\")",
"ClusterName": "Demo-D"
},
{"Cond": "default_t()",
"ClusterName": "Demo-E"
}
]
},“BasicRule”: {
"demo": [
{"Hostname": ["www.a.com”],“Path”: [“/a/*”],
"ClusterName": "Demo-A"
},
{"Hostname": ["www.a.com"],“Path”: [“/a/b”],
"ClusterName": "Demo-B"
},
{"Hostname": ["*.a.com"],“Path”:“*”,
"ClusterName": "Demo-C"
},
{"Hostname": ["www.c.com"],“Path”:“*”,
"ClusterName": "ADVANCED_MODE"
}
]
}
}
6. 总结
BFE 开源软件已实现对于转发表能力的降级。在降级后,BFE 既能够反对以域名和门路作为匹配条件的大量规模规定,也能够持续放弃对于转发条件的弱小形容机制。基于这个能力,BFE 能够适应更宽泛的利用场景,满足大家对于七层转发的各种需要。
欢送关注“BFE 开源我的项目”公众号,取得本我的项目的更多更新。谢谢!