bl商业地产管理系统是专门面向bl集团的，一个集团再大又能有多少人呢？其实在我看来很多架构都是多余的，但这也是没办法的事情，老旧的技术适应不了当今的市场，技术的迭代速度太快

当然，客户也很精明，这个系统后续能不能进行升级？一下子把路堵死了。只有把这些数据服务提供出去，作为一个能力、一种资产，客户才会去接受这个东西，这就是当今的市场

为什么要使用RabbitMQ

刚进入公司的时候，公司项目的架构还比较单一，采用的是单体式架构。单体式架构是把所有的业务都堆积在一个项目里面，但是随着我们公司业务的不断发展和推进，CTO的目标是把项目架构进行拆分，变成分布式架构

项目架构的拆分就涉及到一个问题，比如员工出差申请报销，申请报销后需要给员工发送短信和邮件，三者需要进行沟通和协同，因此我们公司采用了消息队列

常见的消息队列有以下几种

  • ActiveMQ

    老牌的消息中间件，遵循JMS规范、AMQP协议，基于Java开发，虽然跨平台是个好处，但我们更倾向于高性能

    相对于业界其它MQ而言，它的复杂程度较高

  • RabbitMQ

    跟Spring师出同门，因此Spring对它的支持很完善。它支持的协议、消息的分发策略、消息持久化等等也很完善

  • Kafka

    它的吞吐量太高了，因为它底层是基于TCP/IP这种二进制协议开发的，我们用不到这么高的性能

  • RocketMQ

    RocketMQ挺牛逼的，双十一都能抗住，它由阿里和滴滴联合开发，但我担心的是，如果他们后续不对RocketMQ进行维护了怎么办？就比如Eureka和Ribbon，它们都已经停止维护了，但是据我的了解，目前仍然有不少企业依然在使用它们，我们又要保证现有服务的可用，同时又要进行架构的升级和转型，这就很难搞

经过一番权衡，最终我们选择了使用RabbitMQ，我个人使用RabbitMQ的感受，最核心的一点就是它是异步的，因为它起了多个线程，是一个异步分发消息的机制，程序处理数据的能力变得更加高效和稳健，达到了我们进行流量削峰的目的

RabbitMQ的使用场景

解耦、异步、削峰

之前我们聊到消息中间件存在的意义，它对于我们的分布式架构天然进行了解耦，它就是为此而生的。那异步又是怎么回事呢？

串行执行

假设我们的系统中存在订单服务，用户下订单后，我们不光要收费，还要通过短信和邮件的方式告知用户您的订单已经下好了

如果我们选择串行执行的话，假设发短信需要100ms，发邮件需要100ms，由于串行执行是阻塞的，因此整个程序执行完毕需要200ms

如果我们按照图中的异步来做，也就是非阻塞的，那么我们的程序只需要100ms就可以执行完毕，性能提升了50%

线程池？

的确，线程池可以实现上述操作，通讯方面我们可以使用Socket来做，不一定非要使用MQ，但是这种做法有如下几种问题

  • 消息的可靠性（订单服务突然挂掉，消息是否会丢失？）

    针对这种情况，我们需要做消息的持久化，也就是消息存盘，需要NIO、BIO、AIO相关的知识

  • 高可用（一个线程池的能力终究是有限的，能否做集群？）

    不光是集群，还有线程池的调优，这也是个头疼的问题

  • 解耦（线程池和订单服务的代码是耦合的，如何保证Java虚拟机内存不被过多占用、以及项目的可维护性？）

针对上面这些问题，其实如果系统的流量比较低倒也没啥，流量一上来，问题就来了。数据服务作为一种资产，什么叫资产，资产是可以保值的。所以直接上MQ，一步到位，省的后续又要升级架构，客户难道会为我们的架构升级买单吗？不可能的