LeanCloud 提供了完整的数据存储和即时通讯服务,其中即时通讯服务中有一部分元数据(例如会话表)是托管在存储服务里面的,这导致两个服务的收费项目有一些交叉,给部分开发者带来了困扰,这里我们统一说明一下。
首先看看应用层的使用场景。终端应用如果使用了数据存储服务,自然会调用我们的存储 API,这部分请求会计入存储服务按使用量收费的项目里;如果仅仅使用即时通讯服务,则大部分的请求会走 WebSocket 通道发到即时通讯服务器,其中创建、更新、查找会话(Conversation)元数据的请求,则会由即时通讯服务器转发到存储服务器(当然,应用层也可以直接按照存储 API 的方式来访问会话元数据,这些请求就直接发送到了存储服务器)。完整的请求路径如下图所示:
对于会话元数据的请求如何进行计费,情况稍微复杂一点。
由于 Conversation 表本身可以存储应用层的任意扩展属性,我们也确实看到不少应用直接把该表当成一个小数据库来使用,给云端带来的成本压力并不小,所以这部分的请求原则上是都应该并入存储服务的 API 请求数进行收费的。但是即时通讯 SDK 内部为了保证数据同步,在需要展示会话的详细信息的时候,会自动发起 GET 请求,这并不由开发者主动控制,所以对于这一部分 GET 请求到目前为止我们都不收费。
也就是说,上图中通过路径 1(REST API)的请求都按照正常的存储 API 请求计费,而通过路径 2(WebSocket)发出的请求,则按照调用意图进行了区分:CREATE/UPDATE 这类开发者自主发起的请求,收费;GET 这种 SDK 内部出于数据同步目的发起的请求,不计费(这也就是部分开发者留有印象的「通过 WebSocket 发起的请求不计费」的原因所在)。
从 6 月份开始,即时通讯服务器端增加了 Conversation 表的内存缓存,同时各平台 SDK 也都完成了内部的 GET 请求数优化,现在即时通讯内部发起的、可以直接抵达存储服务的 Conversation GET 请求数量已经大幅减少。为了让价格体系保持简单清晰,同时也可以简化后端架构,我们计划从 8 月份开始不再区分 Conversation GET 请求的来源,统一按照存储服务的 API 请求数进行收费。
这里也提醒开发者尽快升级 SDK 的版本,这一方面可以优化自己的使用成本,另一方面也可以降低云端的压力,是我们希望看到的双赢结果。