概述
三年前，我们开始将 Azure Service Bus（ASB）作为企业消息传递解决方案投入使用。它目前被用于在组织内的众多应用程序之间发布和消费数据。 由于数据流较为复杂，且一个应用程序的数据通常需要被多个应用程序使用，因此“发布者”→“多个订阅者”的模式非常适合。本组织中ASB的日消息量达数千万条，而IRIS平台的日消息量则约为200万至300万条。
ASB 存在的问题
在开始进行 ASB 集成时，我们发现 AMQP 协议并非 IRIS 部署的“开箱即用”选项，因此我们一直在寻找一种替代方案，以便与 ASB 进行通信。
解决方案
我们开发了一个本地 Windows 服务（基于 .NET 和 Swagger），由其负责与 ASB 进行实际通信。该服务安装在与 IRIS 相同的机器上。我们将消息发送到 ASB 时，会先发送给这个本地 Windows 服务（通过 localhost 并调用 REST API），随后由该服务完成后续处理。 该方案运行了几年，效果良好，但监控流量、调试“丢失”的消息以及衡量整体性能却非常困难。事实上，将这个本地 Windows 服务作为“中间人”始终不是最佳架构。
IRIS 嵌入式 Python 早期访问计划 (EAP)
我受邀（或者是我自告奋勇的，记不清了）参与了嵌入式 Python 的早期发布计划（ERP）。
