在《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，匹配的程序如下：

• 1. 首先对 host（vip.b.test1.com）进行匹配：

     • 1.1 对 host 做 准确匹配，未匹配胜利
     • 1.2 对 host 做 通配符匹配 ，发现申请的 host(vip.b.test1.com) 能够满足规定 2 和规定 3 的 host 条件。

• 2. 持续对 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

对应以上要求，根底规定表的配置为：

在根底规定表中，多条规定之间是无序的。匹配程序见下面对于根底规定匹配程序的阐明。

针对 Demo-D1 集群的灰度公布，因为须要应用 cookie 中的信息，所以应用 ADVANCED_MODE 将满足条件的申请透传到高级规定表持续解决；在不须要灰度公布的时候，在根底规定表中指标集群能够写为 Demo-D。

高级规定表的配置为：

在高级规定表中，多条规定之间是有序的。须要将转发给 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 开源我的项目”公众号，取得本我的项目的更多更新。谢谢！