Coinbase 交易所背后，究竟是一支怎样的团队？
作者 / Luke Demi Coinbase 工程师
编译 / kou、Guoxi
随着加密货币及区块链技术日益火爆，区块链的可扩展性逐渐成为制约其应用落地的痛点之一，2017年引爆加密世界的加密猫游戏就曾让以太坊网络濒临瘫痪。
尽管目前各行各业的去中心化应用如雨后春笋一般持续涌现，但其性能问题一直是未能突破的瓶颈，仍然存在应用场景受限、可扩展性不强等问题。当下，就连V神也是三句话离不开可扩展性话题。
而与之相对的中心化机构 Coinbase 交易所，虽然在2017年也曾受平台扩展性瓶颈影响而导致大规模故障停机，但自此以后，尽管数字货币交易人群不断暴增、交易请求数量呈指数增长，但 Coinbase 平台貌似并没有再受扩展性问题的影响，持续、稳定地运行着，令人差异，他们是如何做到的？
近日，Coinbase 的大牛工程师 Luke Demi 发文总结了平台去年故障停机的经验与教训，并详细介绍了其平台的可扩展性解决方案。
那么，Coinbase 团队是如何应对2017年突增的平台交易量？之后又是如何逐步扩展平台容纳量、持续稳定运行呢？其扩展性解决方案在去中心化应用领域是否有借鉴意义？接下来，听 Luke Demi 讲述 Coinbase 平台背后的故事！
2017年，加密货币市场经历了井喷式增长，整个加密货币生态系统的总市值从200亿美元跃升至6000亿美元。
在此期间，在中心化交易所 Coinbase 平台之上，几乎所有技术组件都经历了残酷的实战考验。
实践证明，在保障平台的安全性之外，其可靠性和可扩展性也是不容忽视的。
在2018年的 MongoDB 社区大会中，包括 Luke Demi 在内的 Coinbase 工程师都谈到了2017年的经验和教训，以及此后如何增加平台扩展性的解决方案。
2017年的经验教训
2016年，也就是加密货币市场井喷的前一年，Coinbase平台的交易量基本恒定。
在2017年首次爆发之前，Coinbase 团队就用表示四到五倍平台每日最大交易量的红线来标示出预计的平台交易量，即每分钟大约100000个后端API请求。
然而，在2017年5月和6月，随着以太币价格的飙升，平台的交易量也随之猛涨并超越了红线。
在此期间，平台的交易量持续超越了事先预定的红线，导致 Coinbase 平台出现了一段时间的故障停机。
为了快速解决 Coinbase 平台的可扩展性问题，工程师团队先从平台环境中常规的、容易实现的技术点进行了改进。
团队对平台进行垂直扩展，为改进其性能及优化检索过程升级数据库版本，此外，还将热点数据库集群拆分为单独数据库集群等。
经过以上方法改进，Coinbase 平台压力暂时得以缓解，但随着时间流逝，交易量总在持续攀升，平台断断续续出现了很多次故障。
每次故障停机的模式都是相同的：主监控平台会显示100倍的延迟峰值，Ruby 和 MongoDB 延迟时间各是50倍。
作为 Coinbase 的主要数据存储区，MongoDB 在数据流量大的时候会出现高延迟，而 Ruby 延迟时间并没有增加。
在早期的监控系统中，这就是“幽灵”出现的方式
Coinbase 已有的监控工具无法为当时遇到的一些关键问题提供明确的答案，我们把这个现象称为“幽灵”。
比如，这些查询操作来自哪里？ 这些操作是怎么回事？ 为什么Ruby时间显示出相关的峰值？ 问题可能源于应用程序方面吗？
简而言之，团队现有的监控服务并没有完全利用 Coinbase 平台环境中的可用信息。
因此，需要一个框架来回答这些问题并可视化 Coinbase 环境组件之间的关系。
团队通过修改 MongoDB 的数据库驱动程序来进一步改进数据库的查询操作。
修改后的数据库驱动程序会记录超过特定响应时间阈值的所有查询操作，以及请求/响应大小、响应时间、源代码和查询类型等重要信息。
这些改进提供的详细数据使团队能够快速找到一些故障停机期间的异常特征，甚至在非故障停机期间也可以。
第一个主要异常是查找设备操作的响应信息数据量过大。
当用户登录网站购买加密货币或查看相关信息时，大量的查询会导致过重的网络负载。
造成响应信息数据量过大的原因是当时用户和设备之间为多对多关系。
例如，一些用户可能拥有多个设备，而某些设备可能由多名用户共用。 糟糕的设备指纹（用于标定设备）识别算法将大量用户置于同一设备中，从而导致单个设备拥有大量 user_id 对象。
为了解决这个问题，Coinbase 团队将这种多对多关系重构为简单的一对多关系，其中每个设备只映射到一个用户。
这个改进为 Coinbase 平台带来了2017年最大的一次性能提升。
这一发现说明了良好监控平台的作用。
在精心改进我们的数据库查询操作之前，这几乎是不可能实现的调试问题，有了新工具，现在结果显而易见。
另一个问题是某些数据库集群的巨大读取流量。
添加一个查询缓存层，用于在 Memcached（一个高性能的分布式内存对象缓存系统，用于动态 Web 应用以减轻数据库负载）中缓存查询结果。
在查询数据库之前，特定高读取流量的数据库集群对任何单个文档的查询操作都会先在查询缓存层中进行，对数据库的任何写入操作也会同时更新缓存。
这样就能够同时在多个数据库集群中推出此更新。 查询缓存是在 ORM（Object Relational Mapping，对象关系映射）和驱动程序级别编写的，这使我们可以同时更新多个有问题的数据库集群。
事实证明，去年5月和6月经历的交易量井喷与去年12月和今年1月经历的交易量井喷根本不是一个数量级的。
借助这些修复和其他方法，Coinbase 平台就能够承受更大的交易量激增。
为未来做准备
今天，Coinbase 团队正积极努力为下一次加密货币市场的井喷做准备。
虽然在井喷期间做这些改进工作很容易，即使未来将处于交易量非常低的周期，但仍然需要找到一种方法来改善系统在未来的表现。
比较有效的方案就是通过模拟几倍于过去经历的交易量峰值来测试平台环境，来发现下一个问题点可能来自哪里。
解决方案就是执行交易流量的捕获和回放，明确地说就是在数据库上按需生成人为的“加密狂热（crypto mania）”。
这种方案比生成合成流量的方案更好，因为它去除了合成脚本需要保持最新的要求。每次运行套件时，都要确保查询操作根据捕获的数据准确映射到应用程序生成的流量类型。
为此，我们创建了一个名为“Capture”的工具，其内部封装了现有工具“mongoreplay”。
在环境中选择一个特定数据库集群后，Capture 会同时启动数据库集群快照并开始捕获定向到该数据库集群的应用程序服务器上的原始流量。然后，它会在一段时间后将这些捕获的加密信息保存到S3回放。
当准备好执行回放时，另一个基于“mongoreplay”名为“Cannon”的工具将根据之前的数据库集群快照将记录的流量回放到新启动的数据库集群上。
在这个过程中，面临的挑战就是如何同时横跨多个应用程序服务器来捕获单个数据库集群的所有 MongoDB 流量。
解决方法就是，Cannon 工具通过从每次捕获中打开一个10MB的缓冲区来同时进行合并和过滤捕获。
最终得到一个合并的捕获文件，然后 Cannon 工具可以将其定向到一个新启用的 MongoDB 数据库集群中。
Cannon 工具允许精确选择回放捕获信息的速度，从而模拟数千倍于平台一天可能遇到的交易数据量的负载。
虽然才刚刚开始使用 Capture 和 Cannon 工具，但在 MongoDB 数据库集群上执行这类的负载测试时，我们取得了一些新发现。
这个发现来自于 Cannon 工具的调试功能。 Cannon 工具能够检查特定的捕获文件并查看其中的前100条消息。 经过检查，确实发现了一些有趣的事：
有没有注意到 ping 命令（ping 命令用于检查网络是否连通，可以帮助分析和判定网络故障。）与 find 命令（查找）混合在一起？
事实证明，数据库 MongoDB 的 Ruby 语言驱动程序未完全遵循 MongoDB 驱动程序的设计规范，并且在每次查询数据库时通过执行 ping 命令以检查复制集状态。
虽然这种行为不太可能导致 Coinbase 平台故障停机，但几乎可以肯定，这是造成我们在监控中观察到的“幽灵”行为的原因。
在团队协作完成这次挑战后，我们为 Coinbase 目前的可靠性状态感到自豪。
2017年的事件再次证明，给客户提供访问和查看资金的可靠服务对于实现Coinbase 成为值得信赖的购买、销售和管理加密货币平台的目标至关重要。
虽然安全性始终是我们的首要任务，但我们也乐于将确保我们平台可靠性、可扩展性当作Coinbase的主要任务！
目前，我们已经组建了三个独立的专注维护平台高性能和可扩展性团队，为未来加密货币热情的暴涨做好准备。
原文链接：
https://blog.coinbase.com/how-were-scaling-our-platform-for-spikes-in-customer-demand-4a047cb3139c
最新热文：
大力戳↑↑↑ 加入区块链大本营读者⑦号群
（群满加微信 qk15732632926 入群）
（内容转载请联系微信：qk15732632926）
（商务合作请联系微信：fengyan-1101）