微服务架构提倡将单一应用程序划分成一组小的服务，服务之间通过RPC方式互相协调、互相配合，形成分布式调用，横向扩充服务的数量来提高整体的QPS量。然而在简单业务场景下并没有任何问题，当业务场景复杂的时候就会出现A->B->C->D->E->F->G->H->I->J…N,会导致服务整体不稳定，稍微修改下业务逻辑影响一整条链路。或者上游需要同时通知多个下游的时候微服务的架构就会显得单薄乏力，所以需要使用MQ来缩短整个调用链或者解耦同步通知多个下游的场景。例如用户注册流程，在未使用MQ的时候，下游需要关注用户注册信息的时候，只有通知上游去调用接口。但是使用MQ后，上游只需要发送MQ即可，下游订阅MQ消费消息并处理，同时上游并不会关注下游的个数，最终整体的调用链缩短了，性能也有较大的提升。
每逢大促活动的时候，如何快速触达用户？之前的做法是先查询用户注册表，然后批量写入待发消息中心，消息中心收到请求后快速写入DB中，然后通过定时任务来扫描并调用短信、PUSH接口。但是通过MQ可以大大提高系统的QPS。
三、MQ的选型
目前业内比较主流的 MQ 包括 RocketMQ、ActiveMQ、RabbitMQ、Kafka等，关于性能、存储、社区活跃度等各方面的技术对比都相差不大，但我们发现通过简单的选型对比，很难抉择到底选择哪款MQ产品。因为金融行业对于数据一致性以及服务可用性的要求非常高，所以任何关于技术的选项都显得尤为重要。在做技术选型的时候，我们重点关注如下：
另外，在微服务中分布式事务是一个经典话题，如何简单、高效的完成分布式事务对于架构者来说非常重要，在众多的MQ中我们最终选定了商用版的RocketMQ，对于分布式事务也能非常好的支持。
经过几次的重构后微服务中存在的问题也逐步消除，随着MQ的加入系统的TPS又有了较大的提升，同时通过本地缓存和远程缓存相结合的方式来高效实用缓存。对于非核心流程的RPC接口也梳理了降级和熔断的流程，目前稳定性提升的非常多。新版的微服务架构如下：
平台架构没有终点、优化没有终点，单体应用有单体应用的优势和亮点，分布式系统有分布式系统的不足，每一家互联网企业所面临的阶段不一样，所以做法也不一样。但是不要为了追求技术而使用技术，够用就好、解决问题就好。
四、总结
构建复杂的应用真的是非常困难，单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用，那真的会很糟糕。微服务架构模式可以用来构建复杂应用，当然，这种架构模型也有自己的缺点和挑战。微服务实施过程中由于会引入各种中间件，所以会出现各种各样异常信息，对于开发人员和架构师来说都是一种挑战。目前“云”是趋势所在，如果条件允许的话，建议所有的中间件全部使用“云”上的产品，稳定性有保障、降低了维护成本。最后如果能真正成功实施微服务，无非是合理的组织架构、对于项目的认可、工具的合理化、持续集成过程。
往期推荐
- DDD-没那么难！
- 薛兆丰道破996真相：我们每个人，都在为自己的简历打工
- 这一次，彻底弄懂“秒杀系统”
- 技术人成长，应该专注于哪些“不变”的底层知识？
- 中台战略与执行：如何构建复杂业务核心状态机组件
- DDD如何讲清楚，做出来？
