采访形式：文字访谈
采访嘉宾：APISIX 参赛团队
TiDB Hackathon 2021 的比赛已经圆满落下帷幕，本次大赛涌现出不少精彩项目，APISIX 赛队尤为令人印象深刻。希望通过本次访谈和思想碰撞，给开发者们未来基于 TiDB 开发自己的应用和项目带来一些启示。
关于队伍
1. 首先请团队成员介绍下自己
大家好，我们是 APISIX 参赛团队的队员，以下是我们的团队组成：
- 队长：张超，Apache APISIX PMC Member
队员：白泽平，Apache APISIX PMC Member
队员：屠正松，Apache APISIX Committer
队员：陈婧晗，Apache APISIX Contributor
2. 你们队伍的成员是临时组成的还是原先就很熟？团队成员之间是如何分工的？怎么安排项目推进？
我们几位很早之前就在社区中认识了，大家也一起协作完成过很多事情。就本次比赛来说，我们的分工主要如下：
- 张超主要负责设计项目的方案，把控项目的进度，同时负责一部分的开发工作；
- 白泽平和屠正松两位同学负责核心的开发工作；
- 陈婧晗除了参与一部分开发工作外，还会为项目进行 demo 视频的录制；
因为几位成员都在不同的城市，因此我们每周都会不定期举行线上会议来同步各自的进度，确保方向没有问题并及时发现潜在的风险。
3. 你们是第一次参加 Hackathon 吗？最早是怎么了解到 TiDB Hackathon 的？
是的，我们四位都是第一次参加 Hackathon，最早是通过同事和圈内朋友介绍了解到 TiDB Hackathon 的。
关于项目
4. 你们最初为什么会想到要做这样一个项目的？能分享下你们的灵感是什么吗？
最早是想到 Apache APISIX 目前强依赖于 ETCD 作为其配置中心，这对于某些没有 ETCD 使用经验的个人和团队来说可能将会是一个负担，因此我们想要为 APISIX 实现通用的配置中心对接能力，于是想把 TiDB 作为第一个对接的项目。
5. 这个项目会给 APISIX 的使用者带来哪些提升吗？
有了这个项目，APISIX 的用户在选择 APISIX 的配置中心方案时将会有更多的选择，而不必被 ETCD 所“绑架”，比如 A 组织历来就在使用 TiDB，那么在使用 APISIX 的时候即可选择 TiDB 作为 APISIX 的配置中心。
6. 在比赛过程中你们遇到过什么比较大的技术困难？是如何解决的？
因为我们并没有考虑去修改 Apache APISIX 的核心代码，而是通过一个中间组件来实现 TiDB 的对接，所以困难主要来自于：
- 如何实现 APISIX 所使用到的 ETCD V3 API 的子集；
- 如何优雅地对接 TiDB，将配置变更封装成 ETCD 的数据格式从而传递给 APISIX；
关于第一点，我们通过阅读 ETCD V3 API 的 IDL 来了解其格式，并通过挂载 etcd gRPC Gateway 来暴露 HTTP RESTful API，以便 APISIX 可以方便对接；至于第二个难点，我们站在巨人的肩膀上，参考了 k3s-io/kine 这个项目的做法来对接 TiDB，包括如何设计表结构，如何感知配置变更等。
7. 这次 Hackathon 的时间有限，你们在比赛过程中有什么遗憾？在组队及参赛过程中有什么有趣的事儿可以分享吗？
最大的遗憾应该是没有实现从管理员侧到 APISIX 侧整条链路的打通，目前用户还是只能通过手写 SQL 的方式来写入 APISIX 的配置，我们希望后面用户可以使用 APISIX 提供的 Manager API 或者 Admin API 来完成这一侧的操作。
展望与期待
8. 对这个项目未来有什么展望与期待？未来会如何维护？
我们希望这个项目未来能够变得更加通用，对接更多的组件，如 Redis、HashiCorp Consul 等；我们会在 APISIX 社区发起提议，邀请更多社区成员来参与这个项目的规划和开发维护。未来，如果有可能的话，我们也希望这个项目能够捐赠给 Apache 基金会，做为 APISIX 的子项目进行孵化。
9. 期待 TiDB Hackathon 接下来有哪些改进？
如果有可能的话，希望 TiDB Hackathon 未来可以覆盖更多的城市，有更多的线下答辩点。
10. 这个项目可以说开启了 APISIX 和 TiDB 的生态合作，你们认为双方在未来还有哪些技术上可以合作的点吗？
我们认为 Apache APISIX 所具备的可扩展性使得它不仅仅能够作为南北向的 API 网关和东西向的服务代理，而且能够作为任意组件的代理层，我们认为 APISIX 也能作为 TiDB 的数据库代理服务。
活动预告：TiDB X APISIX
来线上沙龙聊聊~
