本文首发自 InfoQ《辞别传统金融音讯架构：Apache Pulsar 在安全证券的实际》。
作者：王东松，陈翔

在金融场景中，随同着业务的扩大，利用零碎也相应地减少更多的场景，这些新场景对音讯零碎提出更多样的需要，导致原有架构面临一系列挑战。在尝试应用 Apache Pulsar 后，安全证券决定在生产环境中进行实际。本文介绍了安全证券抉择 Apache Pulsar 的起因，应用 Apache Pulsar 的场景，Apache Pulsar 实际利用中遇到的问题，以及应用 Apache Pulsar 的将来布局。

背景介绍

传统金融公司或券商个别会应用对立接入服务或组件来解决对外业务。接管到用户申请后，依据相应的业务规定将申请转到对应业务零碎 / 模块。有些申请会转发给音讯队列，申请写入后，上游业务零碎从音讯队列中获取申请，并在解决后通过音讯队列原路返回给客户，整个申请过程关闭运行，性能无限。

音讯队列下传统架构带来的挑战

安全证券采纳的就是上述的传统架构，目前只反对音讯队列。尽管咱们有肯定的开发能力，但也难以获取到该音讯队列的细节信息。同时，因为是定制开发的零碎，反对的语言比拟无限。现有的音讯队列对业务倒退和业务翻新等有以下有余：

• 黑盒零碎，难以观测： 音讯队列是一个黑盒零碎，咱们难以观测到架构的细节；
• 间接替换（Direct Exchange），无奈路由： 因为架构目前只反对音讯队列，无奈反对须要路由的场景；
• 弱校验接入，平安危险高： 现有零碎的明码认证、校验等测验较弱，平安危险较高；
• 定制零碎，无限语言反对： 定制零碎接入语言的反对无限，导致咱们抉择范畴少，难以在原有零碎根底上进行改革。

随着业务扩大和架构改良，公司现有的音讯队列零碎 / 组件面临着一系列挑战，而零碎存在的许多问题如安全性等在金融场景中迫不及待。

金融场景的业务需要

咱们的业务需要次要分为三类：身份辨认 & 安全控制、路由散发、审计。

身份辨认 & 安全控制

身份辨认次要用于确定接入音讯队列的客户端和接入者的身份信息，指定相应的平安规定，回绝不非法接入者，进而实现预期的平安要求。从最根底的层面看，须要辨认管制接入的零碎、IP，依据业务场景及特定需要，进行权限限度。

路由散发

路由散发指音讯依据相应的规定由写入队列路由至对应的队列。现有的音讯队列反对的场景无限，若想要反对更多场景，须要投入大量的工夫和精力来进行开发（波及上下游零碎的革新），同时会引入其余问题。较好的解决方案是音讯队列零碎原生反对更多模式及个性，比方 TOPIC 模式、流式音讯解决。如果音讯队列零碎能够反对路由，那么零碎的接入复杂度就会大大降低，能够通过更优的形式对接入层进行操作，每个零碎只须要对接一组 topic，路由负责散发；也能够更有针对性地优化性能（路由、转发、协定转化都是耗费性能的操作）。

原有零碎架构通信机制是点对点，关闭运行，申请音讯无奈共享，只能间接采纳适配器或日志采集形式实现散发，此类做法难以无效满足实时性要求。

审计

音讯的发布者 / 接收者都属于整个零碎的参与者，并且是重中之重。零碎安全性的次要影响因素就是零碎的所有参与者；因而，从平安角度登程，对音讯的审计要求绝对较高。另一项比拟急切的需要是对音讯流向进行管制。如果能够进行身份辨认和安全控制，则能够在审计时欠缺和优化平安信息，进而保障在业务入口处回绝有效、非法申请，保障外部零碎强壮。此外，记录接入的音讯发布者 / 接收者的信息还能够用于异常情况监控、稽核审计。

新增业务的零碎需要

新增业务对音讯零碎提出了更高要求，次要包含可用性、音讯发送提早、扩缩容、音讯回溯等。

需要一：高可用、低提早

对于互联网行业而言，高可用低提早是零碎的根本要求。从单点到灾备，到同城跨机房，再到异城跨多核心，或者是先跨城、灾备，再跨城多核心（两地三核心）的模式都曾经越来越常态化，很多公司的业务零碎正在或将会往这方向倒退。这样的系统对高可用、低提早的要求比拟高。因而须要思考当零碎复杂度减少（如灾备、跨城等场景）时，如何将提早降到最低。

需要二：疾速扩容与复原

对于金融业而言，业务的次要个性之一是申请可能会在某个时间段或某个周期激增，过了这个工夫窗口后，流量逐步恢复正常。这一个性要求零碎能够疾速横向扩缩容，出于老本思考，依照最高流量部署整个零碎架构显然不合理。最好的解决方案是零碎能够依据单层流量合理安排零碎架构或零碎部署形式，在流量忽然减少时，零碎能够疾速扩容，撑持业务。最现实的状况是零碎的所有组件都有疾速扩缩容、恢复能力。

需要三：音讯有序、音讯防重

在一些非凡业务场景中，须要保障音讯有序或防重。咱们常常对一些接口进行幂等操作，如果能够保障上游音讯不反复，就能够减小上游的压力。

需要四：可回溯、序列化

如果业务零碎呈现问题，但在测试环境中难以复现这一问题，就须要引入音讯回溯。音讯回溯指重放一遍呈现问题的工夫窗口中的所有申请，验证是否能复现问题，并排查问题，这样能够大大加重排查问题的工作量。此外，咱们还能够借助这一性能进行灰度验证和并行验证。

抉择 Apache Pulsar

基于上述业务需要和零碎需要，发现 Apache Pulsar 的诸多个性完满符合了咱们的需要。

1. 集群模式，反对跨集群同步。建设零碎双活，跨集群的地区复制在客户端无感的状况下实现音讯同步。
2. 计算存储拆散。依据应用状况横向扩大存储 / 计算，客户端对此操作无感知。基于二级存储的性能，扩大音讯的应用场景，为数据分析、音讯审计提供可能。
3. 客户端接入认证模块插件化，反对自定义开发。因业务需要，在客户端接入时，要求鉴权、认证，无效保障音讯的起源牢靠、可控。
4. 欠缺的 Rest API，可查看队列状况。之前应用的音讯零碎有很好的性能，但在可观测性方面有所欠缺，给零碎排障造成艰难，同时音讯零碎的治理形式较为原始，难以适配大规模系统管理的要求。而 Apache Pulsar 欠缺的 Rest API 不仅能够获取零碎运行指标，且有助于集群的高效治理。
5. 基于 Functions 可实现音讯的路由开发、过滤和统计等。
6. 可设置音讯的长久化模式和过期工夫，容许音讯重放。
7. 多语言反对，疾速便捷接入。

Apache Pulsar 在安全证券的业务场景

安全证券应用 Apache Pulsar 构建对立音讯平台，冀望整合客户、交易、行情、资金四大数据流，利用于行情散发、实时风控等。本文次要介绍如何将 Apache Pulsar 利用于三个业务场景：申请路由、数据播送和音讯告诉，新架构的劣势和有余，以及其对开发、运维团队的影响。

场景一：申请路由——简化零碎

咱们的音讯路由流程如下图。从 A 组件收回的申请写入到 Topic A，而后由路由模块将 topic 中的信息进行路由，散发到多个对应的 topic，订阅了这些 topic 的上游组件就能够解决相干的音讯。组件 A 只须要向固定的队列写入音讯，不须要关注 Topic B、C、D 的信息，上游零碎只须要理解接管音讯的队列，不须要关注 Topic A，从而简化整个网络的构造。

这种音讯路由模式简化了零碎的整体架构，目前咱们的路由零碎仍待优化：

1. 尽管路由散发的工作量得以加重，但排查问题的步骤有所增加。比方在组件 A 发送音讯后，组件 B 没有收到音讯时，须要先查看组件 A 是否写入音讯到 Topic A、路由模块是否胜利路由这一音讯，再看组件 B 是否正确订阅了这条音讯。
2. 从目前的测试成果看，因为音讯链路变长，时延减少。
3. 因为每个队列的音讯都会长久化，导致存储和队列中都呈现数据冗余。
4. 路由模块是新增模块，运维的学习老本较高。

场景二：数据播送——升高时延

数据播送是咱们应用 Apache Pulsar 的另一个业务场景。数据播送采纳发送 / 订阅模式，次要用于同步音讯。很久之前，咱们不须要同步行情到业务零碎，或是通过其余形式（如同步数据库）实现。但随着业务的增长，同步时效和用户体验的竞争度越来越强烈。如何能够让用户更快地看到信息？以同步行情的场景为例，先同步数据库再查阅的形式，时延绝对较长；而在播送模式中，业务零碎只需订阅所有须要的 Topic，查阅时即可间接读取数据，无效升高时延。

场景三：音讯告诉——平安管控

咱们应用到 Apache Pulsar 的第三个场景是音讯告诉。尽管音讯告诉波及到的业务绝对较少，但这一业务场景非常重要。整体业务流程图如下。因为信号源不惟一，因而在音讯公布到计算引擎后，计算引擎须要依据信号源的信息进行逻辑、平安等方面的计算。计算实现后调起 Task，再由激活的 Task 向相干业务零碎发送业务申请，执行后将后果返回给发动信号源的服务，该服务依据返回的后果触发下一个信号源。

这一场景波及到的业务对平安和管控的要求十分严格，不仅须要限度信号源发送的音讯或信号，截断 / 过滤某些信号，还须要对返回的后果进行解决：哪些能够返回，哪些须要过滤掉或转换成其余内容。如果不应用音讯队列形式，音讯源会间接发送音讯给计算引擎，在计算引擎执行平安或管控策略后，将音讯发送到 Task; 在 Task 执行实现后，其后果须要再进行一轮平安管控解决。这一部分的反复操作对性能影响较大，同时策略更新、信号状态查看的时效性没有那么实时。

引入 Apache Pulsar 后，咱们将管控审计模块剥离进去，专门针对信号队列和后果队列进行过滤、审计、统计等操作，并实时输入后果到治理端。运维或审计人员在看到这些信息后，能够管制、更新相应策略。这一模式不仅能够精简数据流，还能够减少数据补充渠道，也更清晰地定义了各服务模块的边界。

问题发现与解决方案

目前咱们次要在上述三个场景中探索了 Apache Pulsar 的应用，并逐渐上线生产。在应用过程中，咱们发现了几个问题，并在此分享咱们的解决方案以供参考。

1. 实现 REQ-REP 模式

咱们遇到的第一个问题是如何实现申请 – 响应（REQ-REP）模式，咱们的解决方案是通过总线模式进行兼容。

目前常见的调用形式是客户端发动调用申请，服务端解决实现后返回响应即可。但引入总线当前（同步转异步），在多节点的部署场景中，节点 1 发出请求，服务端收到申请后返回处理结果，所有节点都须要监听这条处理结果，节点 2 收到归属节点 1 的响应音讯时应该如何解决？节点 2 须要先订阅并获取回包的音讯，判断是不是本身节点发动申请的响应，如果不是，则抛弃此音讯。如果依照这种模式进行实现，则在发送音讯时，每个节点都须要缓存本身发送的音讯 ID；服务端解决完当前，依照协定回包数据须要带上申请的音讯 ID，每个节点都订阅获取所有回包，并校验缓存中是否有该音讯 ID，若不存在，则抛弃音讯。

该实现形式下存在一个十分严厉的问题亟待解决：节点发动一个查问大量数据的申请时，假设 Apache Pulsar 设置一个音讯 的大小为 8M，TPS 为 1000，那是不是每个节点都要收到这么多申请的回包流量呢？如果有 5 个节点，每个节点本应该只接管 200 个申请的回包流量就够了，但当初的模式须要每个节点接受 1000 个申请的回包流量，而其目标仅仅是为了过滤操作。如果节点负载性能达到下限，须要扩容节点，将导致网络带宽成倍增加。因为 Apache Pulsar 能够反对大量 Topic，尽管通过给每个节点配置一个回包队列等形式能够解决这一问题，但咱们想尝试通过 broker 的 FILTER 性能，来解决该问题。

2. 实现读写拆散

音讯播送场景会波及到读写拆散。如果减少大量订阅节点，最好防止将所有节点的链接集中在 Topic 的 owner broker 上。针对这个问题，可行的解决方案是正当调配应用的 Topic 和 Partition。咱们目前应用的 Apache Pulsar 2.7.2 还不反对读写拆散，打算把 Apache Pulsar 降级到 2.8，就能够轻松实现读写拆散，满足音讯播送场景的需要。

3. 解决多网卡问题

基于公司网络安全思考，外部存在多种网络分区及网段，不同的网络分区 / 网段应用不同的 IP，服务器存在多个网卡，供跨分区零碎间通信。目前如果应用 IP 注册 broker，只能注册某个网段的 IP；如果应用域名注册 broker，则不同网络区域的 DNS 解析又须要进行不同的配置。如果 broker 能够反对多网卡通信，这些问题就不存在了。目前咱们的解决方案是用 proxy 代理客户端的申请，内部零碎也只连贯到 proxy，咱们也会为 proxy 减少一些高可用的配置。

将来布局

目前，咱们在单机房、单集群线上小规模运行 Apache Pulsar，在上线初期未思考建设双活。作为业务零碎的基础设施，Apache Pulsar 本身可用性极为重要。因而，咱们打算基于同城双核心单集群建设进行双活布局，如图如示：

在测试和应用 Apache Pulsar 的过程中，咱们遇到了一些问题，感激 Apache Pulsar 社区的积极响应。咱们期待更多地参加到 Apache Pulsar 的研发中，也期待为 Apache Pulsar 和 Apache Pulsar 社区做出奉献。

作者简介：

• 王东松，安全证券经纪业务事业部研发工程师。
• 陈翔，安全证券经纪事业部架构师。

退出 Apache Pulsar 中文交换群 👇🏻