Pulsar 在涂鸦智能的实践
🎙️ 阅读本文需 7 分钟
作者：张永红，开放平台组研发工程师（涂鸦智能）
>>> 关于涂鸦
涂鸦智能是一个全球化智能平台和“AI+IoT”开发者平台，也是世界排名前列的语音 AI 交互平台。连接消费者、制作品牌、OEM 厂商和零售连锁的智能化需求，为客户提供一站式人工智能物联网的解决方案，并且涵盖了硬件介入、云服务以及 APP 软件开发三方面，形成人工智能+制造业的服务闭环，为消费类 IoT 智能设备提供 B 端技术及商业模式升级服务，从而满足消费者对硬件产品更高的诉求。
上图体现了涂鸦目前的生态模式，包含涂鸦云、涂鸦 OS、涂鸦 APP，形成一个生态闭环。右半部分则为涂鸦涉及到的一些应用场景，例如，智能酒店、智能安防、全屋智能等。
>>> 涂鸦的消息系统架构
上图是涂鸦智能之前的消息架构图。上层是一些 IoT 的独立设备，包括智能开关、投影仪等。通过 MQTT 协议，将消息上报给消息系统。还有一部分设备是传感器等，通过 zigbee 网关和 MQTT 协议的传输，最后上报至消息系统。
上图是涂鸦消息系统具体的链路，从 MQTT 网关开始，接入服务连接到 Kafka，通过 Kafka 进行消息的分发。用户在接收到消息后，可以采取不同的处理方式。
以上的架构模式存在一些业务痛点。
1. HTTP 投递方式不灵活，这个是最明显的一个痛点。假如用户的服务挂掉，想在重启后重新进行消费。如果我们想要满足这个需求，就需要对消息的持久化进行额外的处理。
2. Kafka topic 数量与日俱增，运维成本高。用户使用 Kafka 订阅模式下，可以解决前文提到的持久化问题，但是随着用户和消息量的增加，Kafka 的运维层面压力会比较大，人力和时间等耗费比较高。
3. 租户之间会相互影响。通过架构图可以看出，从 Kafka 模式进行分发后，租户之间会受到很大影响。
>>> Pulsar 自身的优势
Apache Pulsar 是灵活的发布-订阅消息系统，采用分层分片架构。
1. 丰富的投递/订阅策略
2. 运维难度小（相比 Kafka），偏向自动化
Pulsar 存储是分片的，这种架构可以避免扩容时受限制，实现数据的独立扩展和快速恢复。
3. 多租户隔离优势
租户和命名空间（namespace）是 Pulsar 支持多租户的两个核心概念。
在租户级别，Pulsar 为特定的租户预留合适的存储空间、应用授权与认证机制。
在命名空间级别，Pulsar 有一系列的配置策略（policy），包括存储配额、流控、消息过期策略和命名空间之间的隔离策略。
在社区方面，Pulsar 的线上社区里，用户们都很活跃，不管是技术问题还是文档问题，响应都非常迅速。
>>> 与竞品相比，性能更出色
当然，在决定使用 Apache Pulsar 前，涂鸦也做足了充分的调研，并从性能、缩扩容、运维等角度对比了多个消息队列。
LeviMQ 是涂鸦自己研发的基于 MQTT 协议的消息队列。
NSQ 是 Go 语言里比较流行的开源消息中间件产品。
首先在扩容上 Kafka 稍显不足，尤其是在缩容时。从运维角度看，Kafka 也如上文提到的，运维过程对人力和时间的消耗较多。最后在生态方面，因为 LeviMQ 是涂鸦自研的系统并且没有开源，所以生态上具有一定的局限性。
在各性能对比后，也从单个产品角度分析了各个消息队列的优缺点，如下图所示。
从上图可以看出，Pulsar 在扩容和应用场景方面会更出色一些，相比较而言也比 Kafka 更灵活一点。
当然，关于参考资料少的情况，Pulsar 社区也在一直努力在填补这些缺失，最近新增了不少文档。
>>> 测试结果
使用 Apache Pulsar 后，涂鸦的消息系统架构发生了变化，如下图所示：
架构有以下变化：
1. 从 Kafka 到消息分发中，加了一层 Pulsar 结构。在这个架构下，最明显的提升就是解决了租户隔离的问题。在进行 Pulsar 部署时，为每个用户在 Pulsar 里新建了一个租户。
2. 投递给用户的方式中新加了 Pulsar 的传递方式，可以直接使用涂鸦的 SDK 去订阅 Pulsar 的消息。
在尝试使用 Pulsar 的这段时间里，涂鸦的消息系统运作效率比之前有了很大的提升。但是在使用过程中，也出现了一些 bug，比如消息堆积、消费重复等现象。当然涂鸦也对此采取了一些措施。以下为实践案例：
>>> 消息堆积
问题描述
原因描述
Kafka 是推拉模型结合，Client 去 flow 了多少条数据，Pulsar 会在消息到了的时候，往里推多少数据。如果这个时候，不去 flow 数据，Pulsar 不会再去 Client 推送数据。
Go client 的代码中有计数机制（红框）。计数机制会循环使用，并执行红框里的内容。
但是在使用时，不知是网络问题还是 Apache Pulsar 的 broker 问题，比如拉取了 10 条，却只反馈了 8 条。这会导致下一次的 flow 永远不会触发。这时生产者一直往上推送消息，消息就会一直堆在 Pulsar 里。
解决措施
解决措施是：定时发送 flow 指令，即每隔 30s，flow 一些数据过来。这样做的额外成本是会增加一些定时器。如果 topic 数量少，这个定时器成本还在承受范围内。但如果 topic 数量过多，大量的定时器会导致 CPU 的压力很大。
>>> 解析紊乱
问题描述
上图所示，上部分是 Java 发的，下部分是 Go 接收的。通过对比可以看出：下方多了一个回车、一些空格，以及制表符。
上图中 Java 发送了四遍 "hello pulsar"，下方在 "hello pulsar" 前边多了个 `3`。
最后我们发送 "hello"，输出正常。但仍然发现有部分字节码是有点问题的。
原因描述
P1 是 metadataSize，表示后边字节有几个。
P2 里的 24 和 5 是它的 meta 信息。
P3 中 5 表示后边的 5 位才是真实的 payload。
>>> 消息重复消费
问题描述
如图所示，从 M3 到 M6，左边的在消费，右边的也在消费。
解决措施
Pulsar 有一个接口，初始化 Consumer 时，有个 Consumer list，在消费者变化时，从活跃变成不活跃、不活跃变成活跃，都能收到消息。对这些消息做监听然后进行处理，虽然这种情况下也会出现消费重复的 bug，但是概率很小。
Apache Pulsar 现已应用在涂鸦智能的各应用层，总体表现不错。涂鸦也对 Pulsar 的使用有一些规划和期望。
持续引导客户使用 Pulsar 的消息推送模式，取代之前的 HTTP 和 Kafka。
结合 Pulsar 实现一套规则引擎，满足日益丰富的消息订阅需求。
除了上文提到的实践效果外，涂鸦也希望在未来的业务支撑中，Apache Pulsar 能有更多扩展的功能，提供更加丰富的使用场景，所以也对 Pulsar 提出了一些的期望。
在技术层面，希望添加更多运维 API，比如查看某个 topic 所属的 broker 和 bookie。
在文档层面，希望官方多发布一些 Pulsar 设计文档，帮助更多用户充分了解 Pulsar。
伴随着 5G 的到来，IoT 行业迎来了一系列挑战和机遇。涂鸦智能作为一个全球化智能平台，除了在链接各个销售平台厂商外，也与用户之间有着千丝万缕的联系功能。在主打「万物智能」主题的背后，涂鸦也在寻找极高的性能与稳定性的消息系统。
在经过对比诸多消息系统（例如 Kafka 和 LeviMQ）后，涂鸦选择了性能出色的 Apache Pulsar，也通过 Pulsar 的跨地域复制、多租户隔离等特性，解决了之前消息系统中的诸多痛点问题，例如，投递不灵活、topic 数量增加和租户互相影响等，进一步证明了 Apache Pulsar 在 IoT 行业的应用前景十分可观。