RocketMQ与SpringBoot整合进行生产级二次封装( 二 ) _RocketMQ

选哪种？个人而言：业务系统复杂的优先选择第二种，简单业务的选择第一种(尽量采用封装，后续维护方便) 。对于一个复杂的系统，本身业务级的代码就已经很多了，结果还要每个人处理全部一样的东西，消费者越多代码冗余越多。如果一个系统只是为了使用MQ来进行业务分离，消费者也不多，那么可以选择最快的方式，但是最终会选择第二种，如果业务随着时间增长越复杂，越晚改成第二种花费的代价越大！第一种就好比此时我们要直接操作内存，原生操作就好比C++或C，可以直接操作内存，但是同时用完后还要自己写各种异常处理和释放内存；代码封装就好比JAVA，我们只需要告诉Java我们要使用内存，然后用完就不用管

企业中，业务功能产出是一级优先级，在此之上才能有更高级的东西。技术服务于业务，而不是业务服务于技术！比如现在30个人的系统，我们要使用缓存加速访问，那么我们是选择内部缓存（直接用集合或者map存起来）还是用redis？内部缓存和Redis能不能达到目的？能哪个更方便更快？内部缓存！内部对象就很快实现如果业务发展迟早会转为Redis这种专业的缓存中间件，就好比业务发展前第一种，业务发展后选择第二种，但是对于大部分业务系统来说功能增加是很快的，特别是产品同事上一分钟提需求下一分钟就要上线这种（开个玩笑~），所以我们在引用一个技术需不需要进行二次封装时需要技术负责人对业务增长有一个预判。建议是都进行封装一下

1.2 封装的抽离点

对于二次封装，其中最主要的就是找出该框架在日常使用中所出现的大部分涉及到的操作，然后找出变化操作和不变化操作
RocketMQ日常使用主要场景为例：发送消息阶段：准备需要发送的消息、发送消息、记录原始消息日志、发送失败处理、可靠性处理消费消息阶段：记录接收消息日志、业务处理、业务日志记录、异常处理、异常重试、异常通知、死信处理
提取变化点和不变化点（可以抽取为公共处理的场景）发送消息阶段：变化点：准备需要发送的消息不变化点：发送消息、记录原始消息日志、发送失败处理、可靠性处理消费消息阶段变化点：业务处理、业务日志记录不变化点：记录接收消息日志、异常处理、异常重试、异常通知、死信处理
从上可以看到，对于RocketMQ的使用，大部分场景都是可以抽离成一个公共的方法处理，只有业务级的需要自己处理，所以如果我们把不变化场景抽取后，每个同事只需要写自己业务相关部分即可
抽取后的复杂度：对于新加一个消费者，只需要处理业务相关三个场景（准备需要发送的消息、业务处理、业务日志记录），剩下的九个场景，只需要封装一次就可以。需要现在就几十个消费者，可以想想一些减少了多少代码冗余

1.3 设计模式的应用