# BFE Ingress 重定向实现方案

## 背景

BFE Ingress支持在Ingress的Annotation中实现重定向能力配置。详见[需求文档](https://github.com/bfenetworks/ingress-bfe/issues/53#issuecomment-1168283041)和[设计文档](https://github.com/bfenetworks/ingress-bfe/issues/53#issuecomment-1168283261)。

## 现有代码结构

在BFE Ingress中，真正负责接收并管理流量的是BFE Engine。BFE Engine通过加载各个模块的配置文件实现预期功能。租户在使用BFE Ingress时，本质上就是在通过创建和修改Ingress对象来实现对BFE Engine配置文件的修改。因此，BFE Ingress的主要任务就是将租户提交的Ingress对象转换为BFE Engine的配置文件。

为了实现上述功能，BFE Ingress在内部维护了`ConfigBuilder`数据结构。其工作方式大致如下图所示：


## 实现思路

通过上述讨论，与`ClusterConfig`、`ServerDataConfig`和`TLSConfig`类似，对于重定向功能，也可以考虑实现一个类似的数据结构`modRedirectConfig`，该结构可以应该包含`UpdateIngress`、`DeleteIngress`、`Reload`等方法，并将其交给`ConfigBuilder`管理。当`ConfigBuilder`需要执行`UpdateIngress`等方法时，直接调用`modRedirectConfig`中的对应方法即可。


## 实现细节

### 接口抽象

考虑到BFE Ingress后续还会支持更多的模块功能配置，而这些配置的工作原理与`modRedirectConfig`大致相同，它们在具体实现上会有大量重复逻辑。因此，可以抽象出一个`BFEModuleConfig`接口，该接口包含以下方法：

type BFEModuleConfig interface {
	UpdateIngress(ingress *netv1.Ingress, routeRuleCache *RouteRuleCache) error
	DeleteIngress(ingressNamespace, ingressName string)
	Reload() error
	Name() string
}

每个module的`Config`都会实现该接口。这样，`ConfigBuilder`将会得到一个`BFEModuleConfig`接口的列表，当`ConfigBuilder`需要执行`UpdateIngress`等方法时，遍历该接口列表调用每个接口中的对应方法即可。

- 方法不全
- 为什么这么设计接口，每个方法什么时候被调用到，以及大概应该实现哪些功能
- name 和 reload 方法在Redirect中的实现

### `modRedirectConfig`的实现

#### 结构体定义

`ModRedirectConfig`的定义如下：

type ModRedirectConfig struct {
	version string
	redirectConfFile *mod_redirect.RedirectConfFile
}

#### `UpdateIngress`

核心是以每一条httpRule为核心，构建每条RedirectRule。


- routetableCache 中的cache

#### `DeleteIngress`

RedirectRuleList完全依赖于`routeTableCache`。当`ModRedirectConfig`需要进行`DeleteIngress`时，`routeTableCache`中已经删除了对应的Ingress中的信息，所以`ModRedirectConfig`只需要重新执行一遍更新逻辑即可。

- delete ingress
- error： delete ingress，回到初始状态