阿里云技术研究周报——消息服务

1. 阿里云的消息服务，整合了短信服务。

在支持基于队列，主题堆积收发消息的基础上，可以短信形式消费消息。

消息服务API采用HTTP RESTful标准，接入方便，跨网络能力强（标准API方便多语言调用）；

已全面接入资源访问控制服务（RAM）、专有网络（VPC），支持各种安全访问控制；

接入云监控，提供完善的监控及报警机制。

（监控和报警如何设计好才有最大的意义？！）

消息服务提供丰富的SDK、解决方案、最佳实践和7x24小时的技术支持，帮助应用开发者在应用组件之间自由地传递数据和构建松耦合、分布式、高可用系统。

2. 支持：普通队列、延迟队列、优先级队列等多种队列模式。

我们在用的支持普通队列而已。

实现消息的延时机制有成功案例，但是我们未在项目中使用过。

3. topic的特点 ： 服务端主动将消息发送给用户指定的回调地址（Endpoint），消除用户端程序不必要的轮询和资源消耗。

这一点我们的应用也可以做到。

一条通知消息可以同时被多个订阅者订阅和消费。

但是阿里云支持多种投递方式：

支持 http/https, 邮件，SMS，移动端等多种推送方式

我们要做到的话，需要将消息发送到上述接口。

比如我们做的消息发送到邮箱的程序，没有问题。但是http，短信这些方式我们没有尝试过。

http优点在于内容显示格式，短信优点在于及时预警！

后期我们可能调用阿里云的短信接口自己做实时预警，防止服务器故障导致重大损失。同时也应该好好做好容灾设计！

4. 异步通知

可以后端服务处理完成任务时，回调通知用户。进而减少用户，Web前端和后端服务之间大量不必要的轮询请求。

（阿里云可以做到http或者邮件的异步回调通知，这一点在他们的任务系统架构示例中体现出来了价值。我们的订单服务也可以使用topic的这样的功能来设计得更好！）

阿里云的消息服务优点在于可以走http回调（我们需要先走jms最后再转http）

感觉这是我们开放接订单服务所需要的呢！

5. 我们当前的追踪系统也使用了消息服务分成了两级：

http项目负责接收数据和回复

中间以消息服务为媒介

后端消费消息，计数和保存mongodb日志

使用消息服务作为媒介，可以解耦，方便了生产环境上应对多类故障的应急和调试！这也是目前消息服务对我们来说最重要的一个功能！

需要优化的是，提高我们的消息服务的允许消息的数量，亦表示服务的稳定性。因为我们采取的是默认配置，消息服务占用内存如果不断增长，可能导致服务稳定性出问题。

6. 消息服务可以起到对整个项目的请求压力的消化——削峰填谷。

7. 还可以作为跨网络，甚至是夸局域网的数据交换媒介。

8. topic模式等还可以起到异步通知的作用。

延时消息可以起到定时器的作用（我们还未这样做过）。

9. 阿里云提供了下述系统架构示例：

任务系统架构示例，抽奖系统架构示例，视频网站架构示例，短信发送之用户注册，短信发送之物流通知，短信发送之活动确认

架构示例图在如下地址：

https://www.aliyun.com/product/mns?spm=5176.2020520115.0.0.9cd1fffXzkxUg

10. 另外阿里云消息服务可以后接日志服务，最后接入OSS,MaxCompute,Table Store(阿里云自己的NoSql).

消息服务有定量的免费额度，但不与包年包月优惠同享。

11. 总体来说，我们后期会用到的有：

阿里云的短信，消息存储服务（如果为了稳定和日志服务的话——我们自己的消息服务需要做容灾FT和允许更大量的消息堆积），借鉴阿里云消息服务设计系各类统的架构。