我们的使命是使网络商务个性化。我们希望我们的客户能够像与朋友交谈一样，拥有与客户交谈的愉快的个人体验。实现企业与其客户之间的所有这些对话和交互需要一个极其强健的存储系统，该系统可以随着数据集的扩展而扩展—毕竟，我们的存储需求不仅要与我们自己的增长保持同步，还要与我们所有客户的综合增长保持同步。在我们的系统中，我们使用术语"用户"来描述通过对讲机与客户交互的人，不用说，这意味着存储了非常广泛的实时用户列表。"管理用户存储是对讲机平台的基础，自从我们启动公司以来，它需要不断和快速的演进"。管理这个用户存储是内部通话平台的基础，并需要不断和快速的演变，因为我们开始了公司。最近，我们完成了一项雄心勃勃的向全新用户存储系统的转型——我们的用户存储系统从最初的时代到现在的发展历程，让我们看到了对讲机本身在过去八年中作为一个平台和一家公司是如何演变和扩展的。用户存储的简要历史2011–MySQL一开始，我们使用一个AmazonRDS（关系数据库）实例来处理所有事情，包括用户数据。当我们为用户启动自定义数据时，我们选择在MySQL文本字段中序列化它。这个解决方案一直有效，直到我们希望通过允许客户对自定义数据进行排序和筛选来改进用户列表，这时我们需要一个更灵活的解决方案。2011-2014–MongoDB我们求助的解决方案是MongoDB，它对于我们的目的来说非常灵活。它允许我们轻松地存储自定义数据和其他复杂的数据结构。我们实现了一个非常灵活的查询模式来支持用户列表。在我们的早期，这已经足够了。然而，随着我们的发展，低规模的东西开始吱吱作响——我们在使用MongoDB驱动用户列表时遇到了问题，并且一些客户开始出现超时。为数据库提供大量的"单用户读/写"以及搜索工作量成为了一个挑战，而且很明显，我们迫切需要升级。2014-2017–MongoDB和Elasticsearch作为回应，我们开始将用户数据流式传输到Elasticsearch，并用它来驱动用户列表。与此同时，MongoDB本身也变得更加稳定。这段稳定时期并没有持续下去——2016年末，为了我们的目的，MongoDB确实开始吱吱作响。我们经历了定期停机（有时是每天一次），对大客户的限制变得难以忍受。在内部，我们也很痛苦——我们的基础架构团队几乎把所有的时间都花在保持用户存储的可用性上，而这并不是我们通过在AWS上花费更多时间来解决的问题。是时候做出改变了这种情况不可持续，对团队来说压力极大——随叫随到的人必须随身携带笔记本电脑，甚至是参加聚会。这种持续的焦虑状态会在任何时候出现问题，这是一种严重的损失，显然需要改变一些东西。"为了支持我们的新规模，我们需要从根本上改变我们的用户存储层"为了支持我们的新规模，我们需要从根本上改变我们的用户存储层。选择似乎是：用MongoDB重新构建架构，使其实际上具有水平可伸缩性（这是由于初始设置也支持搜索而变得困难）。使用另一个数据库实现同样的效果。评估AWS数据库我们的"无需运行的软件"的理念体现在很多方面，但其中最深远的一点是，如果我们能帮助的话，我们不喜欢运行数据库。为了看看是否有机会摆脱这一责任，我们在亚马逊的几个数据库中对用户存储进行了原型化。我们把极光和发电机视为可能的候选者。不幸的是，这两种方法都不是最佳的：Aurora可以很容易地处理我们需要对用户强制执行的唯一性约束，但是很明显，我们需要做大量的工作来让它支持我们需要的读写级别。DynamoDB可以非常容易地（并且经济地）处理R/W卷，但是作为一个相对简单的键值存储，它不能轻松地处理我们的唯一性约束。用户存储V2背后的理念然而，我们意识到有可能把这个难题分解成两个较小的问题，每一个问题都可以通过极光或发电机来解决。我们可以使用Aurora作为"标识"–只是需要对其进行唯一性约束的数据子集。这些数据很少变化，从总大小来看相对较小。然后，我们可以使用DynamoDB进行键/值"blob"存储。这些数据变化很大，而且变化很大——超过6TB，每秒写入5k，读取超过10k。这本书对DynamoDB来说很容易。一步一步地建造另一个内在的理念是，我们喜欢将大的变化作为一系列安全的小步骤来运送。在对对讲机的核心部分进行大的改动时，特别是要经过深思熟虑并加以控制，这是一项极其重要的任务。我们就是这样处理的：首先，我们引入了一个用户服务层，并确保对用户数据的所有访问都通过该层。这使我们对所有的访问模式有了一个清晰的理解，以及在服务层后面进行更改的能力，而不需要其他团队知道。然后我们在Aurora中引入了身份层，同时仍然使用MongoDB。这使得我们可以将MongoDB上的访问模式简化为key/value，就像迁移后需要在DynamoDB上一样。然后我们将访问者数据从Mongo迁移到DynamoDB，最后将用户数据迁移到DynamoDB。在这一过程中的每一步，我们都会同时写入两个数据存储。这意味着，当出现问题时（正如不可避免的那样），我们可以无缝地回到以前的版本，修复问题并再次向前推进。最终，我们能够停止在MongoDB中双重写入用户数据，并正式迁移到DynamoDB，这是多年来用户存储维护和迭代的结果。计算收益我们的基础架构团队在这一转变过程中所产生的影响是巨大的—我们的用户存储比以往任何时候都更好。更具可扩展性：我们可以将客户数量增加10倍，客户拥有的用户数量，以及每个用户的读写速率，DynamoDB会将其消化掉。它是自动缩放的，所以假设这些变化是逐渐发生的，我们就不必做任何事情。更安全：我们客户的客户数据是我们拥有的最宝贵的数据之一，这一变化使关键数据比以往任何时候都更加安全。低成本：这种创新解决方案每年可节省50万美元。更少的维护：不需要手动管理数据库是非常巨大的，因为这种设置比我们以前管理的分布式数据库的劳动密集度要低得多。值得注意的是，自从我们采取行动以来，我们从未经历过像过去那样的停机。更少的压力：团队现在可以去参加聚会，而不用担心他们可能需要为保持用户存储的正常运行而战斗。我们节省的时间是非常重要的，它使我们能够花费更多的精力和精力来迭代和改进用户存储模型，更重要的是，为我们的客户构建新的产品和功能。"我们管理了30亿用户和45亿访客的迁移，没有任何停机时间"最令人印象深刻的是，我们管理了30亿用户和45亿访客的迁移，没有任何停机时间。这在工程上相当于谚语所说的"边开车边换发动机"。我们非常兴奋地看到这台新引擎将把我们带到哪里。