【感悟】一篇文章入门rocketmq？ 如何写好一篇技术博文？

 

不废话先说结论：要先抛出问题！

 

为什么抛出问题如此重要？我来说一下我的感悟

有开发经验的同学都知道，每一个优秀的开源项目或者商业性框架。都不是一蹴而就的。迭代升级一直是每个优秀系统的自我修养。反过来说，在项目启动之初，就考虑的大而全。往往会把问题复杂化。考虑不全不说，反而会大幅增加问题拆解和项目落地的难度，而且大部分问题，都会在系统的使用中陆续暴露，所以这又给迭代升级添加了一定的宿命感。

别说系统怎么怎么好，怎么优秀。 了解系统面对的问题，和其解决的方案，就是了解这个系统的历史背景和迭代过程，最好的方式。

 

现在举个优秀的栗子：大家先来看看淘宝关于RocketMq的一篇介绍文章。

http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/

本文首先引出消息中间件通常需要解决哪些问题，在解决这些问题当中会遇到什么困难，Apache RocketMQ作为阿里开源的一款高性能、高吞吐量的分布式消息中间件否可以解决，规范中如何定义这些问题。然后本文将介绍RocketMQ的架构设计，以期让读者快速了解RocketMQ。

为什么我会喜欢这篇文章呢？或者说他和其他文章有什么优势呢？

对比其他文章，作者会大量的着墨于系统的特性，比如灵活可拓展，可以处理海量消息堆集，可以主从双写等。读着看到，觉得牛逼啊，然后没有什么共鸣，除了有个模糊的记忆和觉得自己很菜外，可以说是食之无味。

 

而其实上述的种种优秀的系统的特性，真是都来源于用户遇到的实际问题，经过开发的设计实现，才有rocketmq现在的模样。

我罗列了文中提到12个问题。

了解了这12问题，其实就大致了解了整个MQ，回头再看项目，能更好的理解这些特性，看到物理集群配置方式。才会大呼妙哉。

我之后如果有机会推动消息中间件的迭代升级，大可以按rocketedMq遇到的12个问题，来进行分析，这可以大大的提高效率。

总而言之，所有工具架构的出现，都是有自己的历史背景，都有特定的业务场景，了解他们面对的问题，结合自己沉淀的认知，才能最全面的去理解他们。

所以之后如果自己编写介绍某些系统的文章，也希望能以解释系统遇到的问题，作为主要的切入点。