一个每秒超过3万请求的微服务开发经历

导读：本文介绍的是一个国外的外卖平台 ifood 的微服务案例。

ifood 是一家巴西外卖平台公司，平均每天送出 100 多万份订单，每年增长 110% 左右。作为一家外卖平台，访问峰值大多出现在午餐和晚餐前后，周末的时候会更高一些。

在一些特殊的日子里（比如由于营销活动），访问量曾打破记录，平台获得了历史最高峰值，去年 6 月 12 日。我们一个微服务达到了每分钟 20 0万请求的峰值。

故事背景

我在公司平台部门的账号与身份团队工作了大约一年半的时间，这是一个相当长的旅程，由于公司的快速发展，我们时常会面临很多挑战。在设计新的解决方案时，我们总是要牢记这样一个想法：在几个月后，系统的使用量会增长 2 - 3 倍。

今天要讲的故事就是上面案例的一种情况，这个系统是在 2018 年左右开发的，当时公司每个月的订单量是 1300 万。如今已经超过 3000 万了。在这个案例中，系统的使用量是随着公司用户的增长比例而增长的，当然后来增长速度更加迅猛。

在内部，我们把这个微服务称为账号元数据。尽管这是一个通用的名字，但它也解释了这个服务的目的：它处理账号的元数据。什么是账号元数据？主要是指那些非关键的用户信息。举个例子：如果用户喜欢通过短信或邮件收到通知，喜欢的食物类型（比如汉堡、意大利面、日本料理等），一些功能标志，为该用户做的订单数量等等。它就像一个通用的存储，把不同地方的数据汇总起来，方便地服务于客户端调用，同时也服务于其他微服务，这样他们只需要调用一个微服务，而不是 10 个微服务。

最早在 2018 年时，账号元数据的建立主要是为了放一些杂乱的（并不怎么用的）信息，说实话，没有其他地方可以放。我们需要一点结构和查询能力，而且很容易扩展，所以我们选择了 AWS 提供的 DynamoDB。在这里要说明一下，我们明白系统可能会增长，当时公司也已经相当大了，平均负载是有挑战的。但是，我们还是没有预估到，我们会从每分钟 1 万个请求增长到 20 万，然后最终达到了 200万。

这个微服务刚发布后，并没有多少人使用（与账号团队的其他微服务相比）。然而，几周后做出的一些新的架构调整，让这个系统变得非常重要，