这周干的最勇的一件事情就是去 PingCAP 的 #sig-migrate 自我营销了一把 go-storage。这样做的起因是看到了 pingcap/dumpling 的 Write to cloud storage (S3, GCS) natively 功能还没有实现，所以想借着实现这个功能来把 go-storage 带进去。经过一番沟通之后，大家决定在这周的社区 Meeting 上讨论，为此我还写了一份 Proposal: Use aos-dev/go-storage to replace storage.ExternalStorage。在会议上大家各自提了自己关注的一些点，然后我也都一一做了回应，最后大家一致通过了这个 Proposal。
会议上 PingCAP 的同学关注的是这样几点：
- 兼容性：他们期望不管实现如何，现在的命令行和配置项必须兼容（这个其实跟 go-storage 的关系不是很大，是 dumpling 的实现问题）
- 功能：他们很关心 go-storage 有没有实现，或者计划实现他们现有的功能（对 dumpling 项目来说，是加密相关的功能）
- 响应时间：社区也很关注响应时间的问题，他们询问了项目维护者对新功能和 BUG 修复的响应时间
- 文档：社区期望 go-storage 能够提供平台兼容性相关的文档
- 授权：他们非常关注 go-storage 是采用什么协议授权的（Apache 2.0），这样在最坏情况下，他们可以 Fork 自行维护
- 测试：他们期望 go-storage 能有一个良好的测试覆盖率
- 性能：他们期望性能回退不得超过 10%
这实际上是 go-storage 第一次在外部被应用，也是第一次收到来自用户的反馈：
- 可以看出来之前花了很多时间重构和设计的 API 并不是用户关注的重点，只要满足他们项目的需求，API 好不好看都是次要的。换句话来说，如果没实现他们想要的功能，再漂亮的 API 也没用。
- 之前觉得很细小，花几分钟就能搞定的工作却是用户关注的重点：以服务器端加密支持为例，go-storage 想要支持这个功能，实际上只需要增加一个新的参数即可，但是如果没有这个功能的话，用户是绝对不可能接受使用 go-storage 的。
- 还有一个收获是，用户实际上也不想自己来维护这些存储库的对接，如果 go-storage 能很好的完成这些工作，那用户实际上是很乐意进行替换的。
所以我调整了接下来 go-storage 的一些工作重点：
- 实现 Multiparter 和 Appender：之前计划将这部分的工作交给社区来完成，但是现在看来这是一个悖论，在这些核心功能没有实现之前，go-storage 不可能被大规模采用；在 go-storage 被大规模采用之前，也不能有用户来帮助实现这些核心功能。所以这些工作还是需要我们自己来完成。
- 实现 Server Side Encrypt： pingcap/dumpling 是我们社区目前最大的用户，他们的需求就是第一需求，所以要优先实现 SSE 的支持
- 完善测试：之前集成测试只覆盖了 Storager 的常用接口，接下来会覆盖到 Multiparter 和 Appender 等接口
- 完善文档：之前总觉得文档的事情还不着急，但是现在发现文档不写真的没有用户会用，所以也在完善文档
被 pingcap/dumpling 采用只是第一步，在 dumpling 完成迁移之后，我们还会实现 rs-storage，将这一存储抽象带到 rust 平台上，这样我们就能够替换 pingcap/br 中的存储实现。如果被 br 采用了，我们 go-storage 就会成为 tidb 生态的一部分，可以跟着 tidb 项目一起成长了 （开始做梦） 。
如果你的应用使用 golang 开发，同时有着对接各种存储平台的需求，欢迎来我们的 Matrix 频道找我们聊聊：
下周再见！
