gRPC-Go 工程实践
新的一年伊始，也是我加入 gRPC-Go 项目整一年的尾声，我想借此机会提供 gRPC-Go 开发现状的更新，并介绍我们如何管理该项目。对我个人而言，这是我第一次有意义地贡献开源项目，所以今年对我来说是一次学习经历。在这一年里，团队不断改进我们的工作习惯和沟通方式。我仍然看到改进的空间，但我相信我们现在比一年前有了显著的进步。
仓库健康状况
当我第一次加入 gRPC-Go 团队时，他们已经有几个月没有技术负责人了。当时，我们有 45 个开放的 PR，其中最老的一个已经超过一年。作为新团队成员和维护者，积压的陈旧 PR 使得评估优先级和理解项目现状变得困难。对于贡献者来说，忽略 PR 既不尊重他们，也带来了不便，尤其当我们开始要求他们因其他提交而进行 rebase 时。为了解决这个问题，我们齐心协力合并或关闭了所有这些 PR，现在我们每周召开会议审查每个活跃 PR 的状态，以防止这种情况再次发生。
同时，我们有 103 个开放的 issue，其中许多已经被修复、过时或未分类。从那时起，我们修复或关闭了其中的 85 个，并建立了一个流程，以确保我们每周轮流对新 issue 进行分类和确定优先级。与我们的 PR 类似，我们也在每周会议中审查分配给我们的和高优先级的 issue。
我们对新 issue 和 PR 的持续服务水平目标 (SLO) 是在 1 周内完成分类和首次响应。
我们还改进了用于 issue 和 PR 的标签，以帮助组织。我们通常为每个 issue 应用优先级（P0-P3）和类型（例如，Bug、Feature 或 Performance）。我们还有一系列状态标签用于不同情况。类型标签也应用于 PR，以帮助生成我们的发布说明。
版本控制和向后兼容性
我们最近记录了我们的版本控制策略。我们的目标是保持完全的向后兼容性，除非在有限的情况下，包括实验性 API 和缓解安全风险（最值得注意的是#1392）。如果您注意到行为回归，请随时在我们的仓库中提出 issue（请保持理性）。
gRFC
gRPC 提案仓库包含 gRPC 重大功能变更的提案，这些变更需要预先设计，称为 gRFC。此过程的目的是提供可见性并征求社区的反馈。每次变更都会在我们的邮件列表上讨论和辩论，然后才能做出更改。我们在进行破坏向后兼容性的元数据更改（gRFC L7）之前利用了这一点，也用于设计新的解析器/负载均衡器 API（gRFC L9）。
回归测试
我们仓库中的每个 PR 都必须通过单元测试和端到端测试。我们当前的测试覆盖率为 85%。每当发现回归时，我们都会添加一个测试来覆盖失败的场景，既是为了证明问题已通过修复解决，也是为了防止将来再次发生。这也有助于我们提高整体覆盖率。我们还打算重新启用所有 PR 的覆盖率报告，但以非阻塞的方式进行（相关 issue）。
除了正确性测试外，任何我们怀疑会影响性能的 PR 都会运行我们的基准测试。我们在开源仓库中和 Google 内部都有一套基准测试。这些测试包含我们认为对用户最重要的各种工作负载，包括流式和一元调用，其中一些专门设计用于衡量我们的最佳 QPS、吞吐量或延迟。
发布
gRPC-Go 的 GA 版本与 2016 年 7 月的其他语言版本同步发布。该团队在当时到 2016 年底之间进行了几次补丁发布，但都没有包含发布说明。我们随后的发布在规律性（每六周进行一次次要发布）和发布说明的质量方面都有所改进。我们还对补丁发布做出了快速响应，在一周内按需或针对更严重的问题将错误修复回溯到旧版本。
在进行发布时，除了我们仓库中的测试之外，我们还运行与其他 gRPC 语言实现进行互操作测试的全套测试。这个过程对我们来说运行良好，我们将在未来的博客文章中详细介绍这一点。
非开源工作
我们采取了“开源优先”的方法来开发 gRPC。这意味着，只要可能，gRPC 功能都会直接添加到开源项目中。然而，为了在 Google 的基础设施中工作，我们的团队有时需要在 gRPC 之上提供额外的功能。这通常通过诸如统计 API、拦截器或自定义解析器之类的钩子来实现。
为了使 Google 的内部 gRPC 版本与开源版本保持最新，我们每周或按需进行导入。在导入之前，我们会运行 Google 内部所有依赖 gRPC 的测试。这为我们在进行开源发布之前发现问题提供了另一种方式。
展望未来
在 2018 年，我们打算做更多相同的事情，并保持我们在处理 issue 和接受项目贡献方面的 SLO。我们还希望更积极地为 issue 打上需要帮助标签，以便寻找贡献的人有更多 issue 可供选择。
对于 gRPC 本身，我们目前的主要关注点之一是性能，我们希望这将透明地惠及许多用户。在短期内，我们即将完成一些令人兴奋的更改，这些更改应能在高并发情况下将延迟降低 30% 以上，从而使 QPS 提高约 25%。完成这项工作后，我们还有一系列其他性能 issue 将在之后解决。
在用户体验方面，我们希望提供更好的文档，并开始改进我们的 godoc，添加更详细的注释和更多示例。我们希望提升使用 gRPC 的整体体验，因此将密切关注分布式追踪、监控和测试等项目，使 gRPC 服务在生产环境中更易于管理。我们希望做得更多，并希望从这些方面开始并倾听反馈，这将帮助我们稳步推出改进。