事件驱动的订单处理程序

每天‬分享‬最新‬软件‬开发‬,Devops,敏捷‬,测试‬以及‬项目‬管理‬最新‬,最热门‬的‬文章‬,每天‬花‬3分钟‬学习‬何乐而不为‬,希望‬大家‬点赞‬,加‬关注‬,你的‬支持‬是我‬最大‬的‬动力‬。



遵循一个简单的、可独立部署的实时事件驱动微服务的 Hello World 示例,本文将研究一个更现实的订单处理器示例,其中有一个 New Order Single in 和一个 Execution Report out。

新订单是 FIX 协议中一种资产订单的标准消息类型,被银行等金融机构广泛使用。答复通常是一个或多个更新该订单状态的执行报告。

金融科技背景知识

在金融科技领域,当一家机构希望从另一家机构购买某种资产或商品时,它们会发出订单。

另一个组织发回一条消息,通知订单是否成功; 这条消息称为执行报告。你可以把它想象成一张交易收据。这些订单和执行报告以电子方式传输,使用由 FIX 标准化的数据格式。有许多不同类型的订单,但是 FIX 标准提供的最流行的订单之一是 NewOrderSingle。

我们使用与 FIX 协议相同的术语来简化从一个协议到另一个协议的转换。这个例子也可以在 GitHub 上找到。

同样,我们在 YAML 中建模一个输入事件。首先,我们将拒绝所有新订单,因为这很容易演示。

事件驱动的订单处理程序

测试此服务

我们可以通过 YAML 配置使用前面捕获的数据来测试这个服务。我们重写了系统时钟,每次都得到相同的结果。

Java

public static void runTest(String path) {
   try {
       SystemTimeProvider.CLOCK = new SetTimeProvider("2019-12-03T09:54:37.345678")
               .advanceMicros(1);
       YamlTester yt = YamlTester.runTest(OMSImpl.class, path);
       assertEquals(yt.expected(), yt.actual());
   } finally {
       SystemTimeProvider.CLOCK = SystemTimeProvider.INSTANCE;
   }
}

@Test

与前面的示例一样,如果输出不正确,我们可以很快在数据中看到这一点。

当测试失败时我们看到了什么?

假设我们不重写时间,而是使用挂钟,我们可能会看到类似的东西。

事件驱动的订单处理程序

如果我们“单击查看差异”,则可以看到 orderID,其中包含已更改的时间戳。有许多方法可以处理这个问题,但是我们覆盖了系统时钟,以确保我们在这个示例中获得相同的时间。

事件驱动的订单处理程序

组件不需要记录任何内容,因为所有结果(包括错误)都写入到输出队列中。

性能测试


在这个基准测试中,将100k 个订单/s 注入到一个队列中。然后对这些进行处理,并将结果写入第二个队列并读取,以获得端到端延迟。每次运行时间为30秒。这次有两个序列化、两个写入、两个读取、两个反序列化和两个线程之间的跳转。

在安装了 AMD Ryzen 95950X 和 Ubuntu 21.10的桌面上运行,为内存消息传递提供了非常稳定的性能,并为同步写入内存映射文件提供了一致的延迟。在异步模式下使用队列可以实现类似于内存中写入的延迟,同时尽可能快地保存到磁盘上。

比较在 M.2 NVMe 驱动器上使用 tmpfs 作为内存和 ext4。

事件驱动的订单处理程序

结论

将高性能和易用性结合起来可能具有挑战性。但是,如果保持简单,使用事件源作为输入和输出的微服务可以具有一致的微秒延迟并支持可维护的测试。

Information Exchange 信息交流Open Source 开源Clock (Cryptography) 时钟(密码学)Event 事件Execution (Computing) 执行(计算)Memory (Storage Engine) 内存(存储引擎)Microservice 微服务Processing 正在处理Systems 系统Testing 测试

发表评论
留言与评论(共有 0 条评论) “”
   
验证码:

相关文章

推荐文章