透過多點連線擴展 API 用戶端

標準 WhatsApp Business API 用戶端解決方案是在單一 Docker 容器上執行。如果您想要將負載量分流，並且有多部伺服器可傳送和接收訊息至 WhatsApp，可以利用我們的多點連線解決方案來強化效能。

總覽

透過高可用性，只有單一 Docker 容器負責從 WhatsApp 伺服器傳送和接收訊息。如果訊息傳送流量超過單一 Docker 容器的最大傳送量，將會導致訊息傳送積壓，且將增加訊息傳遞延遲。為了擴展 WhatsApp Business API 用戶端，多點連線支援分片，以將負載量分散到多個 Docker 容器。目前，我們只支援分片數為 1、2、4、8、16 或 32 的靜態分片。高可用性是多點連線的一個特例，其分片數為 1。

A 2 分片多點連線叢集

叢集中有兩個 Coreapp 節點（CoreApp 1 和 CoreApp 3）同時負責從 WhatsApp 伺服器傳送和接收訊息。每個訊息只屬於一個基於收件者編號的分片。

分片

WhatsApp Business API 用戶端使用分片來實現多點連線。根據您設定的分片數，資料庫會儲存分片映射，以根據收件者編號（或 WhatsApp 用戶名稱）來決定訊息應前往哪個分片。用來決定此動作的函式為：

shard_id = hash(recipient-id) % shard-number

每個分片都映射到執行中的 Docker 容器（Coreapp）。根據此函式傳回的內容，網路應用程式可知道要將訊息要求傳送給哪個 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 秒。

設定多點連線

根據「高可用性」文件設定叢集後，請使用以下要求來開啟多點連線。

要求

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"
}

參數

回應

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 
  }
}

訊息傳送速率

請參閱參考資料：訊息：效能。

AWS 部署詳細資料

範本網址：

• Enterprise：https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent.yml?versionId=Tvb.Sa6uTwmvj1rSbbpKCmEKz2pyxcLG
• DB：https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_db.yml?versionId=3.vthzENa7qUOuZrozcX9hDk9n8.kdTg
• Lambda：https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_lambda.yml?versionId=gqIhZaXkX_NylKaPJMDBlQNk9.Pl_34b
• Network：https://wa-biz-cfn.s3-us-west-2.amazonaws.com/wa_ent_net.yml?versionId=Y_NczQaJ.4QTAlyedZPir2XF_IAPDpsh

範本可讓您配置所要建立的作用中 Coreapp 容器執行個體數量。範本會建立一個額外的 Coreapp 容器執行個體，以在 Coreapp 故障時協助快速切換。

根據預設，「高可用性」啟用時，範本會依照環境類型建立下列數量的執行個體，以進行多點連線：

• 生產環境：EC2 執行個體：3、Web 容器：3、Coreapp 容器：3、Master 容器：3
• 暫存環境：EC2 執行個體：2、Web 容器：2、Coreapp 容器：2、Master 容器：2

範本配置為根據記憶體使用率自動擴展 EC2 執行個體。記憶體使用率會隨著「作用中」的 Coreapp 容器執行個體數量增加（或減少）而增加（或減少）。因此，當建立更多 Coreapp 執行個體時，EC2 執行個體會隨之自動擴展。不過，可建立的 EC2 執行個體有最大數量限制，如下所示：

RDS 執行個體大小調整

API 要求速率和作用中 Coreapp 執行個體的數量決定了資料庫的連線數量。如果有 8 個作用中 Coreapp 執行個體，而 API 速率為每秒 100 則訊息，則需要大約 700 個資料庫連線（SSL 停用時）和 1200 個資料庫連線（SSL 啟用時）。不過，如果有 32 個作用中 Coreapp 執行個體，而 API 速率為每秒 250 則訊息，則需要大約 1,700 個資料庫連線。

在目前版本中，我們為 8 個作用中 Coreapp 執行個體使用 db.m4.2xlarge（停用資料庫連線加密），並為 32 個作用中 Coreapp 執行個體使用 db.m4.4x.large（啟用資料庫連線加密）。下表針對 RDS 執行個體類別的選擇及其可支援的連線數上限提供相關指引：

配置

• 範本中設定的作用中 Coreapp 執行個體僅控制所建立的 Coreapp 執行個體數量。然而，若要啟用相同的數量，則必須使用設定分片（說明請見設定多點連線章節）。分片的預設值為 1。
• 請務必確保 Coreapp 執行個體的數量一律大於或等於 API 中設定的分片數量。
• 若要增加分片數量：

  • 以所需的作用中 Coreapp 執行個體數量來建立或更新堆疊。
  • 成功後，使用設定分片來啟用相同數量的作用中 Coreapp 執行個體／分片。
  • 注意：設定分片會導致所有 Coreapp 容器執行個體停止並自動重新啟動。執行設定分片時，會有大約 45 秒到 1 分鐘的停機時間。
• 若要減少分片數量：

  • 使用設定分片來減少相同數量的作用中 Coreapp 執行個體／分片。
  • 所有 Coreapp 執行個體都成功重新啟動後，以相同數量的作用中 Coreapp 執行個體來更新堆疊。
  • 注意：更新堆疊可能會終止目前正在服務分片的作用中 Coreapp 執行個體。不過，很快就會指派其他有效的 Coreapp 執行個體。換句話說，在此過程中可能會有額外的停機時間（約 35 秒）。