本文介绍了云片如何利用RocketMQ进行业务解耦，并阐述了云片开发的Stargate组件的由来、设计目标及其实现。Stargate旨在提供简单易用、扩展性强且兼容老项目的RocketMQ使用方式，通过注解简化服务间的异步调用，形成内部通信的统一规范。文章详细讲解了Stargate的初始化、编解码器、扩展接口和上下文管理等功能，以及其在服务隔离和故障切换场景的应用。
RocketMQ消息队列，专业消息中间件，既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性，是应对企业业务峰值时刻必备的技术。
云片由于业务特点，对消息队列的使用十分频繁，由此云片服务号从本期推文开始将发布“云片RocketMQ实战”系列文章，讲述云片根据短信业务的特点，运用RocketMQ消息队列实战经验。
本期推文《Stargate的前世今生》，由云片资深Java开发工程师周凯帆提供。
本文字数3025，预计需要阅读20分钟
云片由于其业务特点对应消息队列的使用十分频繁，这里以云片短信业务为例，短信业务的逻辑十分简单，我们只看主流程，本质就是接受用户请求，寻找合适的通道，使用cmpp/smpp协议提交给运营商。
我们可以发现，用户的每次请求要一直等待运营商的响应，这样主要的问题是：
-
云片的服务器再运营商返回时需要一直维护http连接
-
运营商的处理速率直接限制了云片的处理速率
-
云片的最大并发为所有供应商并发之和
这种情况下我们无法提供稳定的服务。
实际上对于用户来说并不关心具体流程他们只需将短信提交给云片即可，所以我们可以异步的处理这些发送过程，确认收到短信后就可以给用户返回结果以提高响应速度。
日常情况我们的系统流量会是一个比较平稳的值X，所以我们提供能满足的当前流量的消费能力，这样消息就不会积压。
不过随着流量的增加最终实践流量会超过我们的消费能力，这样就会出现短信送达延迟，图中虚线右边是我们不希望看到的。
所以我们在流量到达虚线前提高系统的消费能力。
我们可以看到云片对应消息队列的重度依赖，使得在微服务化的时候没有找到一个适合云片的好用的annotation组件，当时SpringCloud框架并没有对RocketMQ支持的相关组件，而RocketMQ官方github上仅有一个不成熟的项目。
对于目前重度依赖RocketMQ的短信业务我们需要一个简单易用并且能够与我们老项目中代码兼容的注解，同时还要满足各团队
扫一扫
352
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
