标准 WhatsApp Business API 客户端解决方案在单个 Docker 容器上运行。如果您想要拆分负载,让多个服务器向 WhatsApp 发送消息和接收来自 WhatsApp 的消息,您可以在 WhatsApp 上使用我们的多连接解决方案。
多连接解决方案首先需要现有的高可用性设置。请按照高可用性文档设置高可用性,然后继续下方操作。
借助高可用性功能,只有一个 Docker 容器负责向 WhatsApp 服务器发送消息和接收来自 WhatsApp 服务器的消息。如果消息流量超过单个 Docker 容器的最大吞吐量,则消息发送会有积压,并且消息传递的延迟时间会增加。如要扩展 WhatsApp Business API 客户端,需要通过多连接支持分片,以便在多个 Docker 容器间分摊负载。目前,我们仅支持分片数量为1、2、4、8、16,或 32 的静态分片。高可用性是多连接的特殊情况,其分片数量为 1。
此集群有 2 个核心应用节点(CoreApp 1
和 CoreApp 3
)负责同时向 WhatsApp 服务器发送消息和接收来自 WhatsApp 服务器的消息。根据收件人编号,每个消息只属于一个分片。
WhatsApp Business API 客户端使用分片来实现多连接。根据您设置的分片数量不同,数据库将存储一个分片映射,由其根据收件人编号(或 WhatsApp 用户名)确定消息应该去往哪个分片。用于确定分片的函数如下:
shard_id = hash(recipient-id) % shard-number
每个分片都会映射到一个正在运行的 Docker 容器(核心应用)。根据此函数的返回信息,网页应用会知道要向哪个 Docker 容器发送消息请求。建议您设置(分片数量 + X)个机器,以便能够容忍 X 个机器的故障情况。
在上面的 2 个分片多连接图表中,系统会根据分片函数将消息路由到 CoreApp 1
和 CoreApp 3
。CoreApp 2
是辅助核心应用,处于备用状态,但与 WhatsApp 服务器之间没有活跃的连接。假设 CoreApp 1
获取 shard=0
的消息,CoreApp 3
获取 shard=1
的消息。如果 CoreApp 1
出现故障,则只会影响 shard=0
的消息。系统仍会使用 CoreApp 3
发送和接收属于 shard=1
的消息。与高可用性类似,Master 1
会检测 CoreApp 1
的故障,并将 shard=0
的流量通过故障转移流程转移至 CoreApp 2
。此故障转移流程约需要 35 秒的时间。
在您根据高可用性文档设置集群后,使用以下请求启用多连接。
请谨记,在继续操作之前,您需要运行(分片数量 + X)个核心应用 Docker 容器。
多连接并不能保证高可用性。如要获得高可用性,请使运行的核心应用数量多于分片数量。
POST /v1/account/shards { "cc": "country-code", "phone_number": "phone-number", "shards": 1 | 2 | 4 | 8 | 16 | 32, "pin": "pin", "cert": "verified-name-cert-in-base64" }
名称 | 描述 |
---|---|
| 必要。 注册 WhatsApp Business API 客户端时所用电话号码的国家/地区代码,应为字符串。例如: |
| 必要。 注册 WhatsApp Business API 客户端时使用的电话号码,不带国家/地区代码或加号 (+),应为字符串。例如: |
| 必要。 您所需的分片数量,应为整数。 选项: |
| 可选。 现有用于双重验证的 6 位 PIN 码,应为字符串。例如: |
| 必要。 v2.41.2 中引入了 填充此字段允许企业随时调用此端点。在此之前,企业只能在其电话号码注册后的 7 天内调用该端点。 与前面指定的电话号码相关联的 Base64 编码证书。 您可以使用商务管理平台获取此证书。查看复制以 Base64 方式编码的证书,获取相关信息。 注意:
如未提供 |
201 Created : You successfully changed shard number 403 Forbidden : You could hit this if server is temporarily unavailable, retry the request should fix it
GET /v1/account/shards
{ "account": { "shards": number-of-shards } }
请参阅参考文档 > 消息 > 表现。
该模板允许您配置要创建的活跃核心应用容器实例的数量。模板可创建一个额外的核心应用容器实例,以便在核心应用发生故障时帮助快速转移。
在您启用高可用性时,模板会根据环境类型默认为多连接创建以下数量的实例:
我们将模板配置为根据内存利用率自动调整 EC2 实例的数量。内存利用率会随“活跃”核心应用容器实例数量的增加(或减少)而增加(或减少)。因此,当您创建更多核心应用实例时,EC2 实例会自动调整数量。但是,可创建的 EC2 实例最大数量具有以下限制:
活跃的核心应用实例 | EC2 实例的最大数量 |
---|---|
2 | 3 |
4 | 4 |
8 | 5 |
16 | 8 |
32 | 15 |
API 请求率和活跃核心应用实例数量决定着数据库的连接数量。如果有 8 个活跃核心应用实例且 API 请求率达每秒 100 条消息,则需要大约 700 条数据库连接(禁用 SSL 时)和 1200 条数据库连接(启用 SSL 时)。但是,如果有 32 个活跃核心应用实例且 API 请求率达每秒 250 条消息,则需要大约 1700 条数据库连接。
在当前版本中,我们为 8 个活跃核心应用实例(禁用数据库连接加密时)使用 db.m4.2xlarge
,为 32 个活跃核心应用实例(启用数据库连接加密时)使用 db.m4.4x.large
。以下表格提供了有关指南,说明 RDS 实例类的选择及其能够支持的最大连接数量:
RDS 实例 | 数据库最大连接数 |
---|---|
| 318 |
| 636 |
| 1272 |
| 2543 |
| 1212 |
| 2424 |
| 4848 |
| 9696 |
| 19391 |
| 38783 |
| 636 |
| 1272 |
| 2543 |
| 5086 |
| 12716 |
| 20345 |
| 298 |
| 596 |
| 1192 |
| 2384 |