README.md 4.89 KB

阿里MNS中Topic发布和订阅规范 v0.1

本规范基于阿里云的消息服务,所有的Qingger/Runsa应用如果需要在MNS上面建立Topic, 在Topic中发布消息,订阅Topic都需要遵循此规范。


1. 各应用的定义

为了能够让各应用在一个Topic中发布或订阅消息,就需要对各个应用作一个规范的定义。以下是针对现有的产品作出英文名称的定义:

因为在Topic中,发布的消息标签最多只能16位字符,而标签的内容包含了应用和业务,所以各应用的英文名称统一的规定在MNS中最多有三位字符。

索引 产品英文名称 产品中文名称
1 SC Qingger 服务中心
2 DZ Qingger店助产品
3 YZ Qingger云助产品
4 ESH Qingger云商城
5 PSH Qingger积分商城
6 B2B Qingger B2B产品
7 POR Runsa门户
8 CRM Runsa CRM
9 DRP Runsa DRP
10 O2O Runsa 电商管理平台O2O产品

2. 建立和删除Topic

2.1 建立Topic

  • 任何应用如果需要向Topic上发布消息,必须负责建立此Topic的责任(注:多个应用如果需要向一个Topic发布消息,则第一个发布的建立此Topic)

  • 任务应用建立Topic并使用其发布消息时,必须编写相关文档并说明消息的业务类型、消息体的结构说明和示例。

  • Topic 命名方法:{企业编号}-{环境编号},表示不同的客户在不同的环境所使用的Topic;

  • 企业编号:取企业官方英文名并去掉除英文字母外的其他字符,然后转成大写;

例如:星期六的官方英文名是st-sat,因此星期六的企业编号为STSAT

兴记的官方英文名是stellafashion,因此兴记的企业编号是STELLAFASHION。

  • 环境编号:

使用TEST代表测试环境,DEMO代表演示环境,PRODUCTION代表正式环境,DEV代表开发环境。

  • 以下为Topic 名称的几个例子:
  STSAT-TEST:星期六测试用Topic;
  STELLAFASHION-PRODUCTION:兴记生产用Topic 

2.2 删除Topic

  • 遵循谁发布谁删除的原则.

3. 在Topic上发布消息

  • 在Topic上发布消息时,消息必须标注标签,以便其他应用在收到消息时能够过滤和识别消息类型;

  • 标签命名方法:{应用名称}-{业务名称}

    • 应用名称:即 1 中所列出的产品英文名称;
    • 业务名称:根据各应用自己的业务来定义,最多12个字符的大写英文字母;
    示例:
    雇员相关的消息,业务名称可以定义为EMPLOYEE
    账户相关的消息,业务名称可以定义为USER
    
  • 以下为标签的几个例子:

  POR-EMPLOYEE :门户发布的雇员信息
  CRM-POINT    :CRM发布的积分信息
  • 发布消息的消息结构体,各个应用自定义,但是结构体必须发布出gitbook形式,以MD文档进行说明。


4. 在Topic上订阅消息

4.1 订阅名称

  • 订阅名称建议命名方法:{环境编号}-{订阅者应用名称}-{企业编号}-{发布者应用名称}-{业务名称}

  • 环境编号:订阅者环境编号,其值与 2.1 中的环境编号一致;

  • 订阅者应用或服务名称: 1 中所列出的产品英文名称,或应用中的各服务模块名称。长度控制在20字符以内。

  • 企业编号:与 2.1 中的客户编号一致;

  • 发布者应用名称:即 1 中所列出的产品英文名称;

  • 业务名称:与 3 中的业务名称一致;

  • 以下为订阅名称的几个例子:

  DEV-YZ-STSAT-POR-EMPLOYEE:云助开发环境订阅了星期六门户发布的雇员消息
  PRODUCTION-DZ-STELLAFASHION-CRM-SITE:店助生产环境订阅了兴记CRM发布的网点消息

4.2 接收端地址

  • 推送类型为http或https

  • 可以理解为收到推送消息的回调地址,需要各个应用自己开发API接口;

  • 为了让回调地址可以最大程度重用,建议在创建订阅时在url上带上自己需要的参数;

http://emp.api.dev.qingger.com/mns/topic/stsat/por/employee

以上,http://emp.api.dev.qingger.com 为接口域名,/mns/topic为接口路径,/stsat/por/employee为自定义参数,分别可以帮助各应用确定公司客户,发布者以及业务类型。

4.3 重试策略、消息推送格式

  • 重试策略:按照需求定义即可
  • 消息推送格式:建议使用JSON格式,但是如果为其它格式,则需要应用文档进行说明。

版本更新

v0.1 : 2017/04/01 发布此规范