DBPack是一种以AT事务模式实现的DB网格解析，是一种分布式事务模型，不侵入业务逻辑，具有高性能。
分布式事务、读写拆分和分片的数据库代理！支持任何语言！它可以部署为 pod 中的 sidecar。
DBPack 意为数据库集群工具包。它可以作为一个Pod中的sidecar部署，它屏蔽了复杂的基础逻辑，使业务开发不需要依赖特定的SDK，简化了开发过程，提高了开发效率。
特征
- 支持MYSQL协议
- 受kubernetes启发的简单易用的分布式事务解决方案
- 支持读写拆分，支持通过Hint自定义SQL路由
- 作为sidecar部署，支持任何语言
- sharding：支持分表查询，支持order by，支持limit
DBPack 与 Seata AT 事务有点不同，它可以作为一个 sidecar 部署在 k8s 中，这样任何编程语言都可以使用这个 sidecar 来处理分布式事务。它还支持分片数据库和表
分布式事务中间件的工作流描述：
- Slient 向 Aggregation Service 的 DBPack 代理发送 HTTP 请求。（注意：请求地址和端口应该配置为 DBPack 代理而不是实际的聚合服务 API 地址）。
- DBPack 生成唯一的 XID（全局事务 ID），并将其存储在 ETCD 中。
- 如果全局事务开始成功（失败将结束事务），聚合服务可以通过 HTTP 头（X-Dbpack-Xid）获取 XID。然后聚合服务可以向 Service1 发送 API 请求并将 XID 传递给它。
- Service1收到XID后，向DBPack发送业务SQL，代理会为Service1注册分支事务（生成branchID，存入ETCD...）
- Service1注册后，DBPack会为业务SQL生成undo_log，然后undo_log会随着Service1的本地事务一起提交。
- Service2 将执行与 Service1 相同的 step4、5。
- Aggregation Service 可以从 Service1 和 Service2 获取 API 结果，并决定是全局提交还是回滚。如果两个 API 都成功，它会向 DBPack 响应 HTTP 200。如果失败，它会响应除 200 之外的其他状态码。DBPack 将相应地在 ETCD 中将全局事务更新为“commiting”或“rollbacking”。
- 通过 ETCD watch 机制，Service1 和 Service2 将知道是提交还是回滚他们的分支事务。（如果是提交，他们会删除 undo_log；如果是回滚，他们会执行 undo_log。）
- 在所有分支提交或回滚后，分支状态将在 ETCD 中更新。Aggregation Service 的 DBPack 代理会知道全局事务已经完成，然后它会从 ETCD 中删除 XID 和 BranchID 信息。