- 团队名称：Canopus
- 作者：陈博钏，王贺，王超，Bear
- 项目信息
- TiDB (xhebox/tidb:latest): https://github.com/xhebox/tidb/tree/hack
- Operator (xhebox/operator:latest): GitHub - xhebox/tidb-operator at hack
- TiProxy (xhebox/tiproxy:latest):GitHub - xhebox/TiProxy at hack
- Local k8s env: pingcapcol/k8s at main · xhebox/pingcapcol
作为数据库核心模块的计算层，在数据库实现上云之后，是否能够也能够将其中的计算进行微服务化改造呢？我们这个项目将会对于这部分功能做一个非常有意思的尝试。
本次项目的背景是在 TiDB 上云后，由于 TiDB 集群已经完成计算/存储分离。同时 TiDB 节点的计算节点之间也是无状态的。因此我们很自然的会期望是否能够将现在集群的 TiDB 节点所具备的计算能力进行微服务化。那么对于计算做微服务化是否可行？有什么样的好处？ 首先我们来回答一下微服务化是否可行？
答案是肯定的，不过也不是免费的午餐，本次 hackathon 我们选择这样一个题目就是想在这方面做一些有益的探索与验证。
接着我们来回答做数据库微服务化有什么好处这个问题： 简单的来总结一下：
- 计算微服务化之后，云上的计算能够更加细粒度的进行配置与部署，对于用户使用数据服务来讲能够达到最大的性价比；
- 计算能力可以随着用户 workload 特点的变化，做最快速的响应，最好的达成用户业务目标；
- 能够最大效率的配置不同数量的计算资源服务于不同的用户业务；
- 微服务化后的计算业务弹性与线性增长比能够做到最佳
基于上述分析，我们组建了这个小队，参加 2022年度 hackathon 比赛，同时用代码和大家交流我们对于数据库内核计算微服务化的理解与探索。以代码交友。
这一部分可以对设计进行详细的解释；合理清楚地说明该功能将如何实现，通过实例剖析案例，如何使用功能等。
- 应用组：应用本身的架构设计，以及使用 TiDB 的具体功能解决了什么问题
- TiDB 产品组：说明主要想要实现/完善/改进 TiBD 的什么功能，会如何进行实现
这部分可以描述关键算法的伪代码，API 接口，UML 图等，以及还会修改哪些组件。
这部分我们将为大家详细展示，我们探索的一些思路与设计理念。
从图中我们可以看出，我们通过上图所示的架构图，来展示我们对于 TiDB 计算层面微服务的探索。我们利用 TiProxy 来作为各种微服务的入口与微服务的 proxy，能够将不同的负载引入到不同的微计算上。
同时我们发现其实光从计算层面来做拆分微服务，最后的效果依然不理想，我们通过探索发现，要做到符合预期的数据库计算层的微服务化，其实还有一个至关重要的环节是底层存储数据访问的解耦合。不同种类的计算可能需要根据其特征，来访问不同的不同的数据部分最终达到微服务之间的无状态且易扩展性。
从上图我们可以看到本方案会从整个数据访问的链路上来测底的解耦合微服务以及其需要访问的数据与其他微服务之间的关联，从而真正实现数据库层面计算微服务化。
- 我们将会通过 placement rule 将所有数据的 follow region 迁移到一个或多个新的 TiKV 节点下；
- 通过启动一个新的微服务处理这类型的请求，例如 DDL 或者 AP 查询；
- 通过读第一项新增的 TiKV follow 副本数据将查询对于用户读写业务的影响降低到最小；
- 完成某类请求后根据需要在对 fllow region 数据进行合适的均衡操作；
通过上面的设计，我们的集群将能够很好的将每一个微服务以及它处理的数据能够进行从上到下比较彻底的划分，通过引入这样的隔离机制，来达到微服务在弹性，部署与计算方面进一步符合云上微服务的特征，让用户使用数据库计算服务就像使用自来水一样，我们装好自来水龙头，用户根据需要只需要打开开关且通过开关来达成用多少计算起多少计算的目标。