过去一周对Bitbucket Cloud的工程和支持团队以及我们的客户来说是一个动荡的时期。最近几天，你们中的一些人对我们的服务的性能和可靠性表示担忧。幸运的是，对于大多数Bitbucket用户来说，我们的服务一直在顺利运行。但是考虑到每天使用Bitbucket的开发者的数量，即使是我们活跃用户的一小部分也代表了很多人。
这篇文章的目的是提供一些答案：发生了什么，为什么我们会有这些问题，以及你应该期待什么。
简而言之：我们即将完成一个长达一年的项目，转移到一个全新的平台，这将有利于Bitbucket的安全性和可靠性的发展。这次搬迁导致了最近的性能问题，我们正在积极解决，预计在未来几天内会得到解决:
- 合并拉动请求的时间比以前长。虽然我们一直在对性能提升进行投资，并可能在这一领域看到改进，但重要的是要认识到，合并是在后台异步进行的，所以你不需要等待拉动请求被合并。如果你浏览了，它就会在你做其他事情时完成。我们正在更新用户体验以明确这一点。
- 目前，渲染拉动请求差异的速度较慢，有时会出现超时。我们正在积极解决这个问题，并希望这个问题很快就能为所有客户解决--在几天之内，而不是几周。
发生了什么事？
十多年来，Bitbucket的大部分服务都被托管在一个数据中心。虽然多年来这对我们很有帮助，但运营一个数据中心也有很大的开销和风险。例如，当我们遇到意外的能力问题（如硬件故障或上游服务的意外中断）时，我们受限于可用的物理服务器，影响了我们的恢复时间。
在过去的一年里，我们一直在将所有的Bitbucket云迁移到 微观，Atlassian基于AWS的内部云平台。这对Bitbucket云来说确实是一个质的飞跃，将解决许多可靠性问题，包括上面描述的问题和更多。当然，这并不意味着搬迁很容易；如果是这样，我们早就完成了。
为什么我们一直有问题
虽然我们在过去的12个月里在幕后取得了巨大的进步，但最近我们的一些大客户的性能下降，凸显了我们在执行方面的重大差距，我们正在积极努力弥补。
也许我们的团队在这个项目上面临的最重大的挑战是文件系统的延迟。10多年来，Bitbucket的服务一直以超低延迟访问位于同一设施内的物理文件系统服务器来运行。这促进了许多功能的实现，从页面渲染到API序列化，再到缓存数据，都是以烘烤的方式进行的。迁移到一个新的环境中，我们的计算资源和文件存储都是虚拟的，这是个权衡。这对我们的可扩展性非常有利，因为我们可以根据需要动态地增加容量；然而，这也带来了性能上的代价，因为运行我们应用程序代码的服务器和存储存储库数据的服务器之间的延迟大大增加。
我们确实预见到了这种延迟的增加，并做了许多改变以减少其影响。这些变化包括消除和重构许多以前需要文件系统访问的代码路径，引入新的钩子来自动优化存储库，广泛地缓存Git对象和其他需要文件系统访问的数据，以及将普通数据的存储卸载到S3。这些努力和更多的努力是成功地将我们的生产流量迁移到Micros而没有看到响应时间急剧增加的关键。但正如过去一周所表明的那样，仍有工作要做。
合并拉动请求
在我们计划这次迁移时，我们的工程团队优先考虑确保Bitbucket继续保持响应，同时支持用户一天中通常高频率进行的所有操作：访问仪表板、浏览源代码、审查拉动请求等。我们主要关注的是读取操作，因为这些操作的数量比写入操作要多得多。
相比之下，我们接受了写操作会增加延迟的说法--例如，创建存储库、提交代码、创建拉动请求--理由是这些操作代表了典型用户执行的频率远远低于读。
合并拉动请求的情况显然是一个需要更仔细考虑的问题。在我们开始收到支持案例并听到用户说合并时间太长后，我们认识到我们的UX（用户体验）中存在一个很大程度上没有被注意到的差距：用户认为合并是一个同步操作，需要他们等待合并完成并在页面上显示一个横幅，而实际上它们是异步的（发生在后台）。
当你点击 "合并 "按钮时，会将一条消息添加到一个队列中。一个后台工作者进程随后从队列中获取该消息并执行实际的合并。在这个过程中，前端会轮询Bitbucket的API以了解合并的状态，一旦变化被提交到版本库，就会动态地更新页面。
现实情况是，绝大多数合并拉动请求都被成功处理了，但我们现有的用户体验并没有明确说明这一点，导致用户感到困惑和担忧。我们正在更新我们的用户体验，使之更加清晰:
- 我们已经更新了横幅本身，以表明合并是在后台进行的，你可以安全地从该页面导航。(已完成)
- 我们正在推出一些变化，以保持页面上的横幅，即使在页面刷新之后。这应该可以减轻用户在刷新页面时看到横幅不见了，然后不知道拉动请求处于什么状态的困惑。
- 我们还将重新审视我们如何通知用户成功或合并过程中可能出现的任何错误。
当我们对我们的用户体验进行这些更新时，请容忍我们。同时，希望至少了解我们合并拉动请求的异步方法对一些团队是有帮助的。
查看拉动请求的差异
不久前，我分享了我们的目标是优化开发人员在一天中使用的核心功能，包括审查拉动请求。拉动请求中最重要的部分是差异。事实上，拉动请求差异的平均加载时间只有一秒多。然而，在过去的一周里，我们的差异渲染功能出现了一些重大的问题，对我们最大的客户造成了极大的影响。
如前所述，我们的新平台为我们提供了更好的可扩展性，但其代价是增加了文件系统的延时。为了保持网站的响应速度，我们的方法是接受在不面向用户的领域进行权衡，以优化网站的响应时间，因为我们的网站是用户对增加的等待时间最敏感的服务（没有人喜欢等待页面加载）。
为了优化我们的diff和diffstat端点，我们的工程师实施了一个解决方案，在拉动请求创建过程中主动生成diff并进行缓存。然后在查看拉动请求时，他们会看到diff、diffstat和冲突信息都是从缓存中获取的，绕过了文件系统，避免了延迟的增加。不幸的是，尽管进行了内部测试，当我们将这些变化推广到生产中时，我们发现了大量的边缘案例和错误，导致差异有时显示为人工制品，或者更糟的是，根本无法加载。
从现在开始，我们已经禁用了这个缓存优化，以解决这些错误。好消息是，我们已经修复了其中的许多问题，并有望在未来几天内修复其余的问题。目前这意味着对许多用户来说，差异的加载速度较慢，并将继续比平时慢，直到我们能够完成所有的修复工作并重新启用优化功能。
确保你的差异加载速度的提示:
- 保持你的拉动请求分支是最新的。Bitbucket中的差异包括自你从目标分支中分离出来后发生的变化。通过保持你的分支与目标分支接近，你可以减少计算差异的成本。
- 保持你的拉动请求小。将大的单体变化分解成多个更小的增量变化，这不仅有利于性能，也有助于你的团队成员理解和审查你的代码。
你可以期待什么
关于我所描述的问题，我将重复本帖顶部的总结，以确定对近期的期望:
- 合并拉动请求的时间比以前长，但重要的是要认识到，合并是在后台异步进行的，所以你不需要等待拉动请求被合并。如果你浏览了，它将在你做其他事情时完成。我们正在更新用户体验以明确这一点。
- 目前显示拉动请求差异的速度较慢，有时会出现超时，但我们正在积极努力解决这个问题，预计这个问题很快就会为所有客户基本解决--在几天内，而不是几周。
我再次理解，过去一周对你们中的许多人来说是令人沮丧的。我期待着在我们恢复了diff和diffstat API的性能之后，以及在我们向云端迁移达到终点之后，对这个帖子进行更新。
