说说消息中间件

最近跟团队一直在讨论近期项目里面涉及到的消息中间件选型的问题，发现对不少问题的认知还是有点含含糊糊，干脆趁机梳理一下。

一、消息中间件的作用

1、系统解耦：

一般的系统设计都会不同程度存在耦合的情况，不同系统和模块之间存在各种调用和依赖关系，耦合不是洪水猛兽，如果系统不复杂是可以有一定容忍度的，但是如果系统复杂度提高了，那么这种网状的依赖关系就是成为灾难，严重影响开发和运维效率。消息中间件这样一个中间层的引入，比较好的解决了这个问题，生产者把数据丢到队列里面消费者就可以按需使用，避免了过度耦合带来的系统架构性的问题。

2、异步调用：

我们的系统中存在多个环节和模块，如果顺序执行一般过程会很繁琐很漫长，而且容易失败。用消息中间件可以把中间耗时较长的环节，从同步改成异步，可以极大的提高成功率和响应速度。 异步处理的时候，消息中间件简化耦合消息发送者和消费者消费者的耦合关系。

3、流量削峰：

这个很容易理解，就想蓄洪工程，洪水一下子用过来大坝肯定溃坝，如果有一个大的蓄水池，就可以缓冲一下。 这种流控主要采用消息中间件做缓存，以减少后端的压力。

二、需求与选型

消息中间件近些年发展很快，这也有赖于算力和数据的猛增导致的系统架构复杂度的飙升。总的来说消息中间件可以分成商业版和开源两种。过去商业版本被国外垄断，后来出现了东方通金蝶一类的国产商业版本也有一些应用的场景，更多的时候开源版本还是更受大家欢迎。

如何选型就成了一个非常关键的问题，首先要对中间件的核心需求进行归纳，然后是一些选型要考虑的要素：

1、核心需求：

1） 高可靠需求：需要提供完备的生产者、消费者、消息中间件集群方案；

2）持久化：要避免消息丢失，需要支持消息进行保存，持久化到到磁盘或存储；消息重试：消息处理失败后的支持失败转存或重试，不能是一锤子买卖；

3）有序消费：在有些场景下，需要消息的消费能够按照发送的同样顺序进行处理从而保证顺序执行；

4）消息堆积和回溯功能：在消息中间件持久化保存大量消息时不会对性能有大的影响，支持消息查询、重发，或者按照时间点来重新消费消息，以应对某一段时间消息的重新消费场景

2、其他需要考虑的因素：

1）技术栈的匹配度：因为开源软件，技术代价还是有的，需要考虑该产品是否与当年的技术栈匹配，技术代价高不高；

2）同业认同度：在本行业内的认可度和认同度，是你必须考虑的问题；3） 产品的稳定性和高可用性，这个就更不用说了；

4）最后还有，社区活跃度，你设想一下，如果社区里面没几个人在维护，你敢用吗？

3、选型原则：

1）首先你得清楚自己的核心需求框架，需求要分成功能性和非功能性，明确了需求就成功了一半；2）另外你可以量化考虑，比如可以用决策链分析法，来定量比较。3）有人也说过一个比较有意思的方法，看看哪个东西经常被拿来做比较，你选它一般都没错。东西好，用的多，所以才被拿去做对比，哈哈哈。4）理性，一定要理性，不要有个人好恶，尤其是，设计者和规划者，将来又不是你用，你的个人好恶，是成功最大的敌人。5）适合的才是最好的，不能攀比。

三、主流消息中间件的对比

打开X度，搜索“主流消息中间件对比”。

其实技术选型这种东西，在规划设计的时候很难讲对与错，说对错的都是事后诸葛亮。天使说，我们得为客户负责，得倾听客户一线的需求和痛点，了解使用习惯和技术栈，作出理性选择；魔鬼说，我们不懂，我们做不了，对不起！