Design Concept

为什么这个 puppet 叫 “Engine” ？这就要谈到我们 puppet 的整体设计，以及相比其他 puppet 有什么不同之处。Engine 最大的特点是：

• 适配多个客户端，一个ts客户端失效，可以直接无缝切换另一个
• 用户可以自行设计符合模版规则的客户端来使用wechaty

在设计 puppet 的时候，我们首先调查了社区内其他 puppet , 并研究了他们的实现原理。我们发现，其他 puppet 设计思路大多是这样：由 puppet server 进行管理和维持托管账号的状态。所有的请求都是通过 puppet -> puppet server -> WServer 这样一条链路完成。消息推送部分，puppet 和 puppet server 之间建立长连接，同时 puppet server 和 WServer 也建立对应的长连接。当有新消息推送的时候，是通过 WServer -> puppet server -> puppet 这样的链路到达 puppet 端。这样的设计中 puppet server 就充当了一种有状态的代理角色，所有流量都是由服务器完成转发。在我们看来这样的设计可能有几个潜在的劣势：

1. 因为最终和 WServer 通信的都是 puppet server。如果一个 puppet server 上托管了多个账号，且没有对各个账号配置对应的代理策略，那么这些账号将共享 puppet server 的 IP。从风控角度来看，容易产生风险。而且一旦其中某些账号风险等级比较高，容易对同一个 IP 池的其他账号造成污染，伤及无辜。
2. 所有流量都是通过 puppet server 转发，对其带宽产生了不小压力，特别是当托管账号中产生了大量图片、视频等多媒体资源时。
3. 由于 puppet server 维护了托管账号状态，所以 puppet server 是有状态的。从系统架构角度来看，有状态的服务器在系统稳定性、可用性、容量规划等方面都存在不小挑战。如果集群中某些服务器宕机，而备机切换机制设计不够完善的话，容易出现部分账号处于不可用的状态。
4. 为了保证 puppet 有更好的可用性和体验，通常 puppet server 会缓存（不一定永久保存）某些数据（比如聊天数据）。也就是说，服务端无可避免地需要触碰托管账号的业务数据。这就需要 puppet 的提供者保持极高的行业自律，而且通过充分的机制保证客户数据的安全性。
5. 大部分puppet数据都需要经过sever端，可能存在数据安全问题
6. 价格比较高，免费的web协议功能比较少

基于对以上这些问题的思考，我们调查了市面上大部分免费的协议，大部分都是基于web和hook方式实现的，web协议wechaty已经实现，hook协议只有xp，但是功能还不够完善。所以我们考虑加入一些功能完善的hook协议来丰富wechaty的生态。

初期考虑的是直接针对一个hook协议进行封装，但是后来实现下来，发现如果只针对一种hook协议来进行封装，此puppet可能会存在较大的废弃风险或者不够通用。 所以又进行了一轮讨论后，决定写一个puppet engine 去适配所有的hook协议，因为大部分的hook通信方式都是基于websocket或者http协议进行的，所以很具有通用性，只要设定好规则模版后就可以快速的复制出多个client去适配puppet engine.这种设计模式具有以下有点：

1. hook方式都是基于用户本地，所以无需担心数据安全问题
2. 目前选入的hook方式都是开源的，所有操作都是透明的，无需担心有后门
3. 可以适配多种hook方案，例如市面上的 DaenWxhook ，可爱猫，鲲鹏，VLW等
4. 用户可以自行按照模版去写自己的客户端。模版简单，文档清晰，基本一天就可以实现一个客户端
5. 免费协议，不收取任何费用，功能相对比较多。

整体架构的拓扑图就如下所示：

欢迎大家一起交流学习。