BFE路由转发模型如下图所示。
以http请求为例，当请求到达BFE时，BFE首先根据请求域名确定租户(哪个业务线)，再根据请求的路径确定集群(服务/微服务)，然后确定子集群(机房)，最后负载均衡选择实例(服务进程)。
那么我们为什么要重写这套路由转发机制?
BFE在路由到集群以及负载均衡选择实例上，与我们接触的网关很类似，在做网关时，我们最头疼的就是配置一堆路由规则。在七层流量代理上，由于多租户的存在，我们也需要配置一堆规则。
为了解决繁琐的配置问题，以及兼容历史遗留问题，我们重写了BFE的路由转发机制，让服务主动的，按“/租户/服务/机房/实例/接口”的格式注册到注册中心，BFE从注册中心读取和监听服务注册。要实现这一点，需要业务方使用我们提供的框架开发。
当然，这很大程度是由于历史遗留问题决定的。在使用BFE之前，我们公司使用的是自研的七层流量代理，使用自定义的客户端与服务端的通信协议。因此，客户端和服务端都需要依赖七层流量代理提供的SDK开发。
使用BFE后，除兼容旧的逻辑，为实现客户端与后端的rpc调用，提升开发效率，支持多语言(客户端ios与Android、h5使用的开发语言不同)生态，我们提供基于idl通用语言的rpc实现方案。
实现基于注册机制的转发逻辑，有利于实现跨区域流量调度。我们不需要知道哪个业务在哪个大区部署有服务，通过跨区域数据同步即可自动发现就近区域部署的服务，将请求通过专线转发到其它区域的BFE。也称南北路由。
在调整路由转发机制后，由于去掉了转发规则的配置，原有限流模块已经不适用，或者说太重，配置起来太繁琐，因此，我们也重写了限流模块，只保留按租户限流和按接口限流，并增加按连接数限流和按握手次数限流。
重写BFE的路由转发机制并非原有实现不好，而是为了兼容原有技术栈，解决繁琐配置问题，实现跨区域流量转发。很多时候，历史包袱并不是说丢弃就丢弃，每个迭代都要考虑兼容问题。
基于百度开源的BFE二次开发，目前为止，我们几乎重写了BFE，只保留BFE的骨干框架。由于要兼容一堆逻辑，BFE也变得越来越重，而这些兼容逻辑，也会是一个长期存在的逻辑。
本文转载自微信公众号「Java艺术」，可以通过以下二维码关注。转载本文请联系Java艺术公众号。
