因为公司业务需求，需要接入到消息中间件地使用，之前我是没有接触过这些技术的，于是学习一下，希望能尽快熟悉，到熟练应用的程度上，以下是我刚整理出来的东西，只能算是一个笼统地认知吧
作用
我在学习RocketMQ地同时，先去了解了一下消息中间件的概念，其实我对分布式都不了解，只能有一个比较模糊的画像吧，但这对于RocketMQ的认知来说也足够了，在我看来，传统的业务上升到分布式的情况下的时候，一些原本地业务就变成了一个个独立的系统，从以前的一台服务器到多台，我大致画一下图来解释我的认知吧。
一开始地小型项目基本就是这样，先不用考虑DAO地问题，所有的业务和服务都集成在一个项目里，整个类似于IEDA中的module，这时候模块即项目，然后模块中的业务都被封装在一个jar包或者war包里，对小型项目来说，很合理很足够，不浪费资源。
但是随着项目地发展，使用人数的增多，只在一台服务器上堆性能是不合理的，所以大佬们把原本的模块上升到了项目的级别module——>project，
原先我做小项目的时候，整个项目都在一个模块中整合，严谨地MVC分层模式，但是对于一些大型项目，每一个业务甚至功能被访问被使用的频率，可能会高到整个小项目都难以承载的情况，这时候就不应该是一个项目整合所有了，举个例子，原本公司规模小，只开发一个项目试试水，这时候只要招个全栈就够了，整个公司就一个开发，项目简单，需求也少，这时候他一个人开发前端，开发后端，设计架构，部署，运维还都可以搞定，时间充裕，需求也不紧张；
但是随着公司发展，第一个项目上线后备受欢迎，于是原本的需求就要改了，这个人又要做需求调研，又要改业务实现，又要扩张业务，前端页面，还要增强服务器性能。。。。。。那这个时候，就不是他一人之力能管得了的了，因为人的思维是线性的，得一件一件地去做，效率很低，这时候就要招更多的人了，更精细化地分工，前后端分离，架构，项目经理，产品经理，运维人员，测试人员等等，大家都更专业化，分工更明确，这时候公司就由一个人变成了一个团队。
可以把公司当成项目，每个人当成模块，一开始需求不大的时候，有一个模块就够了，但慢慢地一个模块承载不了压力了，就需要拆分，把每个业务都提取升级成一个单独的模块，原本的一个人做的时候，各个业务联调依靠思维跳跃（SpringMVC）现在拆分开了，就需要沟通（rest/dubbo协议）来联调，怎么样去高效率地协调管理成为问题的核心。
以上总结出来我们最核心的要解决的问题：解耦 和异步（目的：提升效率）
这个时候项目的架构就变成了这样：
这时候就需要整体解决方案（SpringCloud或其架构方案），中间又会有细分场景，沟通效率低下，公司运转艰难，那这时候就需要一个团队管理公司的交流和沟通效率（消息中间件），那这个团队我们怎么选择呢，市面上标榜自己牛逼的团队有好几种，他们分别是KafkaMQ、ActiveMQ、RabbitMQ，后来还出现了RocketMQ，那我们对场景适配，先面试这几家团队再做选择，经过比对，我们了解到：
KafakaMQ这个团队处理效率极高，是所有团队中最高的，但是他的准确度相比其他都比较差，适合处理公司一些准确性要求相对较低的工作，而且可用性很强，属于分布式架构；
而ActiveMQ呢？他非常严谨，不允许一丝差错，很优秀，但正因为他过于注重严谨，导致效率又比较低，金融人事方面的沟通很适合这个团队来做（很多银行项目用这个），
RabbitMQ，跟ActiveMQ一样属于主从架构，但他用了erlang开发，对并发支持效率很好，但在高可用上有一些欠缺；
RocketMQ则用JAVA开发，阿里大公司用的也是这一套，且经历过所有团队中最严苛地考验，但是如果阿里放弃了那不好维护，但综合能力最强，分布式架构，同时保证了很大的数据吞吐量和很好地准确性。
经过各项比对，我们决定通过RocketMQ的面试，团队的沟通交流由RocketMQ代理，先处于试用期（我才刚开始学习）那这时候，我们需要对RocketMQ的工作有一个完善的认知才行，先看看RocketMQ这个团队内部的工作模式和流程吧，下一篇讲。
