兼容性
一个兼容 Pusher 的实时后端
PushCaster 在线上说的是 Pusher Channels 协议第 7 版。搬过来是改配置，不是重写——而这一页就是会变的东西的确切清单。
不需要重写应用。只需修改连接配置。 每个应用三到六行；如果是 Laravel，改一处 .env 就完了。既不是 drop-in 也不是 zero-config：主机必须设，凭据也是新的。
哪些保持不变
线上协议、库，以及认证握手
这里说的兼容指的是协议本身，而不是相像——兼容的请求/响应格式、事件语义和认证方案。
| 方面 | 不会变的 |
|---|---|
| 协议 | 线上的 Pusher Channels 协议第 7 版。 |
| 客户端库 | pusher-js、Laravel Echo 和官方移动端库，均未修改。 |
| 服务端库 | pusher-php-server、pusher-http-node，以及 Python、Go、Ruby 和 Java 的库。 |
| 签名 | 兼容的签名与规范化方案。 |
| 频道的种类 | public、private、presence 和 private-encrypted，前缀也一样。 |
| 订阅鉴权 | POST /pusher/auth 的请求和响应形状原样保留。 |
| client event | 在 private 和 presence 频道上的订阅者之间，一如从前。 |
| Webhook | 字段名和头都一样，包括 channel_occupied、member_added 和 cache_miss。 |
已测试的 SDK 版本
与所列 Pusher SDK 版本兼容，无需修改这些 SDK。
| SDK | 测试版本 |
|---|---|
| pusher-js (browser) | 8.6.0 |
| pusher/pusher-php-server | 7.3.0 |
| pusher (Node.js) | 5.3.4 |
| pusher (Python) | 3.3.4 |
| pusher-http-go | v5.1.1 |
| pusher (Ruby) | 2.1.1 |
| laravel/framework (Echo) | ^13.0 |
哪些会变
主机，以及凭据
pusher-js 在没给 wsHost 时会写死 ws-<集群>.pusher.com，服务端库在没给主机时默认走 api-<集群>.pusher.com。把这两处改掉，就是整个迁移。
const pusher = new Pusher(APP_KEY, {- cluster: 'eu',+ wsHost: 'ws-eu1.pushcaster.io',+ wsPort: 443,+ forceTLS: true, })按语言列出的完整改动
// before — talking to Pushernew Pusher(KEY, { cluster: 'eu' })// after — talking to PushCaster (the key & secret are new)new Pusher(KEY, { wsHost: 'ws-eu1.pushcaster.io', wsPort: 443, forceTLS: true,})设主机这一步最容易漏。 如果留着默认值，库就会去和 Pusher 的服务器说话，而报出来的错会指向 key 不对，而不是目的地不对。
app id、key 和密钥都是新的。 原有凭据不会沿用。顺手把集群也选了——它是主机的一部分。
已知差异
三处并不相同的地方
兼容性的说法，只有连着它的例外一起看才有用。这三处足以改变一个设计决定。
一个集群，没有联邦
集群是隔离边界，不是地理提示：它有自己的节点、NATS 和 Redis，集群之间不会互相投递。一个应用只属于一个集群，所以需要互相通信的两个应用应放在同一个集群里。
host 不是集群名
只写 cluster: "eu" 到不了 PushCaster。你需要在客户端设置 wsHost，在服务端库设置 host。这是三个选项的改动，每次迁移都要做。
没有统计 API
Pusher 控制台的统计接口在这里没有对应物。用量来自我们自己的 API，运维指标来自 Prometheus。没有任何官方服务端 SDK 会调用那个接口，所以受影响的是你的工具链，而不是你的应用。
迁移
先测 private 和 presence 频道
就算有什么不对，public 频道照样能通过——它们什么也不问你的服务器。过期的主机或者对不上的密钥，只会在 private 和 presence 的订阅上现形。
- 01创建应用你选的集群是接下来每一个主机的组成部分。
- 02两处都要设主机客户端需要 wsHost，服务端需要主机。漏掉任何一处，你应用的一半仍然在和 Pusher 说话。
- 03换掉凭据三样是一起换的。新 key 配旧密钥只会在带签名的订阅上失败——所以它能从一次草草的冒烟测试里活下来。
- 04subscribe 一个 private 频道这会真正跑一遍 POST /pusher/auth，并证明 secret 与 app id 是配对的。
- 05加入一个 presence 频道这会确认成员列表以及加入和离开的事件。
- 06从服务器 publish 一次这会端到端确认 publish 的主机和签名。