移动应用 API 扩展策略

Question

我们的 API 是为支持一百万用户而开发的。由于我们在 4 个月内达到了 50 万大关，我们现在正在扩展它以支持我们计划在一年内达到的 1000 万用户。目标是现实的，因为我们现在将核心数据处理/聚合逻辑作为 SDK 提供给其他应用。

当前的 API 是 HTTP post，其中正文是 JSON。当新用户注册时，他会从设备上传大约 200KB 的数据。以前我们用于处理数据服务器端，但现在我们在设备本身上处理它。

此后，该应用每天将上传大约 2KB 的数据并下载大约相同的数据。对于拥有多个移动设备的用户来说，这个数字会更多一些，但仅占总用户群的 1%。

目前，我们的 API 服务器使用 Jetty+Jersey，平均有大约 200 个并发连接。它可以处理大约 500-1000 个并发连接（取决于请求的类型）。

每个 API 服务器（共 4 个）有 120 个数据库连接。我们的工作量是 80% 的写入和 20% 的读取，更新可以忽略不计。

现在 API 是同步的，也就是说，对于每个请求，我们都会存储/检索数据并将确认/数据发送回客户端。

一种扩展方法是扩展（垂直和/或水平）我们的 API 服务器并在 userId 上对数据库进行分片。完成数据库分片是因为我们估计每百万用户需要 1TB 的数据存储。我们还计划迁移到 SSD，但是这需要一些时间，因为我们有自己的数据中心并且迁移正在进行中。

我预见到的主要挑战是在 sdk 推出流行应用程序时处理新用户的激增。我正在考虑一些方法：

1) 在写入请求期间，只需提取实体，推送到 KAFKA 并向客户端发送 ACK。消费者比提取实体从队列中持久化并分批插入它们。

2) 使用不同的读写服务器。对于读取使用现有的同步架构。对于写请求公开一个由 Netty 支持的不同 URL，它将提取实体以持久化并将它们推送到内存队列中，向客户端发送 ACK。异步传输到 kafka 队列，然后最终传输到数据库。

3) 对每个请求使用异步服务器 Quasar+Comsat 和轻量级线程，并让客户端等待确认（获取持久实体的自动增量 ID）。问题是数据库连接数是瓶颈，允许产生许多并发的轻量级线程可能并没有真正的帮助。

任何帮助指出这些方法的优点/缺点/改进或对新方法的建议都会有很大帮助。即使我们从 10M 扩展到 100M，关于这些方法中的哪一种是正确的观点也会有所帮助。我们没有网络界面，所以所有数据传输都是纯 json，在发展中国家，我们还必须支持 2G 设备和大量网络断开，因此也必须考虑到这一点。

Answer 1

通知：我是 Quasar/Comsat 团队的一员。

我不认为这些方法是相互排斥的，我只建议不要普遍使用异步 API，因为它们会损害代码库的可读性/可维护性（因此，未来），而这正是 Quasar/Comsat 可以提供帮助的地方他们的同步 API 很多（但光纤而不是线程阻塞，因此与异步一样高效）。

如果您非常关心耐用性，那么我也会尽可能少地将数据保留在易失性内存中。我不是 Kafka 专家，但我认为它可以处理大量负载，并且有一个 Comsat integration in 0.6.0-SNAPSHOT。

是的，启动大量等待数据库池的纤程对您的吞吐量没有帮助。您需要一些 Kafka（或类似的）+ 异步传输摊销层或更快的数据库。

请记住，由于光纤非常便宜，您可以阻止它们并允许向客户端提供同步模型（和同步响应），即使它们有很多，只要您使用 Quasar 集成的 API（或编写您的拥有，which is not difficult at all)。

最后我不确定你的 API 是单体的还是微服务的，尤其是在后一种情况下，你可能对 this post of ours about Comsat VS. regular HTTP client performance 感兴趣。