.NET Core下使用消息队列组件Solace经验总结

开源的消息队列组件很多，比如RabbitMQ就很流行，而本篇要说的是一款付费的消息队列组件Solace。

由于soalce不是开源免费的，所以可能有些开发者对其并不了解，包括我本人工作了多年也没有接触了解过，更不用提使用了。刚巧最近所在的公司在使用solace，所以在经过了一段时间的使用后，想总结记录下一些使用solace的心得体会。一是为了记录，二是分享出来，或许可以帮助一些有需要的朋友。solace除了官网的资料，包括文档和代码，网络上有关它的介绍并不多，比如在GitHub上搜solace的个人项目真的很少，这应该是由于其是收费的缘故。

 

对于之前完全没有了解和使用过solace的人来说，怎样快速搭建出可以为团队使用的公用组件是一件不简单的事情。考虑到组件的可用性和拓展性，组件是会被用于新项目的多个微服务的，所以组件的设计需要得简单易用，还的符合公司大框架。公司的大框架是微服务，应用事件驱动框架EDA，所以设计之初，组件就得兼容Request/Reply模式，Pub/Sub模式，以满足各微服务的使用场景，因为使用场景可能复杂多变。为此，我先是查阅的solace官网开发文档，以及SDK API各种功能使用方法，对solace的使用总算了初步的认识，零散的知识点还不能为我所用，我需要把这些东西根据组件的设计把他实现出来，这是个消化吸收再到创作的过程。加上参考GitHub上的两个项目，借鉴别人是怎么使用solace的，不过这些都只是简单的应用，并不能完全适用了具体的项目要求，实践项目的应用场景要复杂得多，要求也严苛些，后面会叙述该部分。

 

好的组件对使用者来说应该是简单，不过对于设计和实现这个组件则是复杂的，因为你需要考虑到各种情况，把复杂性封装到底层了。对于使用的简单性，这方面可以多看看优秀的开源组件是怎么设计的，而我则从开源组件CAP以及RabbitMQ学到了很多，大到模块的划分设计，小到接口的定义，技术难点的处理等等。

可用性：

所有定义的接口，暴露出来的方法和参数经过封装，隐藏solace原生API。

消息队列的使用场景是简单的，我总结为两种模式：Pub/Sub，Request/Reply。

Pub/Sub：就是Publish/subscribe，Producer publish message，Consumer consume message，这是一种异步模式，Async API的设计思路。

Request/Reply: Requester send message, Replier reply message，这是一种同步模式，会阻塞。

那组件要完成的就是设计出这两个场景的接口API，组件可以划分为：Publisher，Subscriber。Publisher实现Publish message的功能，Subscriber实现Consume message的功能。Publisher同时还实现Request的功能，Subscriber实现Reply的功能。

 

扩展性：

Publish: 所有的行为有message定义，需要扩展的在message进行定义。

Consume：由统一的入口进行消费，比如实现ISubscribe接口。

结合配置文件，实现功能的定义配置。

 

实现：

基于.NET Core实现，实现组件以模块的方式注入服务，代码侵入性低，各微服务只需要写业务代码即可。需要注意的发送消息和消费消息都不能阻塞主线程，这里面需要实现solace session池化，soalce原生并没有实现session pool，需要开发者自己实现。实现session池，可以提高发送和消费效率，也提高了可用性。消费消息同时也要注意并发效率，好比同时来了成百上千条消息，如何提高吞吐量或者控制并发量，防止数据太大冲垮应用，这里需要用到多线程/Task/Async等技术，.NET core本身也有多种类库可用，比如DataFlow，ReactiveX，Channel等，可以根据项目具体情况在具体的场景选择合适的类库。

总结使用solace，比较建议的是进行抽象封装，实现session池化，Queue的订阅要session隔离，对消息的消费要考虑吞吐量。