从消息队列中间件的比较说开去

我们公司项目做微服务化框架升级，需要升级消息队列中间件。这个任务就派到我身上了。

由于项目的并发量不是很大，对消息队列中间件的要求不高，加上客户给的钱少，于是项目开始之初我就设计了一个非常简单的实现——用memcacheq就OK。没有集群，没有高可用、也没有考虑高性能。

老大最近发话了：我们不能放纵。项目是可以质量差一点，但我们对自己的要求不能差。加上以后我们会承接更多更重要，安全可靠性要求更高的项目，最好在消息队列中间件的高可用，高可靠性上做一些文章，命令我一定要写一个好一点的中间件选择方案文档。万一以后需要了，也好应付自如，不至于手足无措。

经过三天的学习，我对比了目前开源产品中比较流行的三套中间件产品：RabbitMQ,Kafka和RocketMQ。其他像ZeroMQ,ActiveMQ这些估计也是差不多的，不会有更好的表现。按照网上的大多数人的对比，得出了最好使用RocketMQ的建议。

然而今天早上醒来，我发现我错了，离开项目实际的一切比较都是耍流氓。我之所以得出这样的结论，是认为RocketMQ的吞吐能力强，安全可靠，水平扩展能力强等等。但是别忘了，RabbitMQ和Kafka也一样可以。网上有人说rabbitMQ消息堆积会影响性能，但刚刚才看到可以用惰性队列解决这个问题的。就像我那个项目而言，消息量不大的情况下何必用消息队列中间件呢？用一个ArrayBlockingQuene不就解决了吗？

在我们IT领域，比较不同产品之间的差异似乎成为了非常流行的做法。如果你上百度查询“XX与XX的对比”或者“XX与XX的区别”就可以得出一大堆结果。这些文章有些似乎说得很有道理，其实不然。

就使“主流MVC框架的对比”做说明吧。很多人说Struct2比Struct1更方便更好用，因此推荐用Struct2。前几年出现了SpringMVC，他们又开始推荐SpringMVC了，说它开发更方便，更容易，更强大等。突然之间，SpringMVC似乎也有点落后了，现在又有很多人开始写大量的Spring Boot的介绍文章，说用它会如何如何。

这几年我一路走过来，从Struct1一路升级框架，到现在，并没有发现我们的开发工作量减少了多少。总是有人谈论说：哟，这个框架这么神奇呀，居然可以这样。是啊，挺神奇的，真的可以这样。可是又能怎么样呢？用了它你就可以不用加班了？用了它你的代码就不烂？用了它你就成了高级开发、架构师、技术总监？简单地一句：你太于关注这些框架不会使你的技术真正进步。

你过于关注它们哪个好，其实归根到底只是想用框架代替你少干活，这真的现实吗？我们追求的东西到底是不是本末倒置？我想，我们应该将精力回归到程序员基本功上面：加强学习设计能力，需求分析能力，代码整洁之道。框架只不过是一个工具，中间件要使用也非常方便，这些都不是根本。

程序员应该更关注基本功，更加关注“解决了什么样的问题，是如何解决的”，而不是框架啊这些东西。从struct升级到spring mvc，你的业务代码一句都不会少写，倒不如多重构一下代码，多画UML图，养成良好的编程习惯。基本功扎实时，你会发现一切东西都似曾相识，原理就在我们打基本功的过程中使用过了，只不过现在用同样一种模式解决同样类似的问题而已。