BFE Ingress重定向功能实习总结

[loheagn]

很高兴参加了BFE Ingress项目的重定向功能的开发。在一个多月的时间里，我完整地经历了从需求分析，到功能设计，到技术方案，到编码实现，再到测试完结的整个过程，收获了很多。

在项目开始之前，我本来以为既然在issue中已经有了基本的proposal，就可以直接进入编码阶段。但实际上在项目前期，花了很多时间进行需求细化和Annotation的重新设计。在这一过程中，我对“要做什么”有了更清楚的认识，也拓展了我对HTTP协议的了解，比如，重定向的Response中Header的Location字段等。

本次实习项目整体的需求看起来并不复杂，BFE本身已经对重定向有了比较完整的支持，BFE Ingress的主要功能就是将租户提交的Ingress资源转换为BFE的配置文件，并对BFE引擎进行热加载；在定义好重定向相关的Annotation后，需要做的仅仅是将Annotation“一对一”地翻译到BFE的重定向模块的配置文件。实际上，本次实习项目最核心的工作是在添加重定向功能的同时，设计一种通用的架构或模式，以方便在未来类似的其他模块（比如Rewrite模块），以及考虑在这个通用的架构下，是否需要对现有的类似模块（比如Route模块）进行重构。

在最初编码的时候，我只设计了最简单的module接口，为所有的mod_xxxx模块增设了统一的抽象。这一层抽象设计有用，但还不够。在一开始的时候，我一直是以一种总体的视角去看待Ingress，让Ingress中定义的所有流量都去适配mod_redirect中的一条规则。但这样会在不同的Ingress匹配到相同规则的流量时发生冲突。在林明老师（@zhugelianglongming）的帮助下，我认识到，与Kubernetes不同，BFE处理流量的基本单位是“Rule”，而不是Ingress。BFE Ingress Controller承担的很重要的一个功能就是将租户提交的Ingress分解为若干个“Rule”，并根据优先级进行排序。在既有的Route模块中是这样，对于Redirect模块也是如此，对于未来需要支持的Rewrite等模块也是如此。进一步地，从Ingress到“Rule”的分解过程和优先级排序方式在各个模块中是类似的，而且各个模块都是首先将Ingress分解出来的“Rule”暂存到一个cache中，然后再读取cache去构建最终的配置文件。因此，有必要将各个模块中的这些共通的方法抽取出来，并可以考虑定义一些抽象的接口或基类，以方便不同模块之间进行复用和拓展。

从传统的软件工程的角度来说，完成了前期的设计文档和实现方案后，后续实际的编码工作应该是非常快的。但实际上，由于本身对BFE Ingress的设计理念不是很了解，在具体的实现过程中走了一些弯路。我想可能是因为接触项目的时间太短，而且本身也是远程线上的“兼职”实习，从这个角度上，这一问题几乎是无法避免的。

最后非常感谢BFE团队，特别是林明老师（@zhugelianglongming）提供的全程指导，让我能快速入手BFE Ingress项目的开发，并在整个实习过程的每个环节中为我提供帮助，及时纠正我的错误，并帮我细致地review代码。希望后续能有机会继续参与到BFE社区的工作中。

[zhugelianglongming]

首先，我想先对李楠（@loheagn ） 同学在这次重定向项目的表现给予肯定。

李楠在项目过程中体现了不错的计算机专业水平，不仅仅是因为在对目标功能的设计和实现，更是因为可以在结构和框架的抽象中，考虑到后续模块开发的影响，同时对实现性能也有合理的思考。在我认识的这批同龄同学中，属于比较优秀的水平。
在沟通方面，总体感觉我们沟通比较顺畅，每周的例行同步沟通、方案 Review 都可以比较高效、准时推进；对于插入的特殊情况，也可以做到及时沟通，动态调整。整个项目过程中，李楠是一位良好的 co-worker。

其次讲讲此次项目中，我看到李楠同学的提升：

1. 对于软件功能的理解有了明显的提升，更加意识到文档内容在项目中的重要性，并且文档编写的能力有了明显提升。
2. 需求分析能力的提升
3. 设计实现能力的提升
4. 质量保证相关能力的提升，掌握了 Ingress 场景的自动化回归测试

最后感谢 李楠 在 BFE Ingress 开源项目中的贡献，也希望更多的朋友和我们一起参与到 BFE 开源社区的建设~