zls

MQ rules

1 +## 阿里MNS中Topic发布和订阅规范 v0.1
2 +
3 +
4 +
5 +本规范基于阿里云的消息服务,所有的Qingger/Runsa应用如果需要在MNS上面建立Topic, 在Topic中发布消息,订阅Topic都需要遵循此规范。
6 +
7 +
8 +
9 +### 1. 各应用的定义
10 +
11 +为了能够让各应用在一个Topic中发布或订阅消息,就需要对各个应用作一个规范的定义。以下是针对现有的产品作出英文名称的定义:
12 +
13 +> 因为在Topic中,发布的消息标签最多只能16位字符,而标签的内容包含了应用和业务,所以各应用的英文名称统一的规定在MNS中最多有三位字符。
14 +
15 +| 索引 | 产品英文名称 | 产品中文名称 |
16 +| ---- | ------ | ----------------- |
17 +| 1 | SC | Qingger 服务中心 |
18 +| 2 | DZ | Qingger店助产品 |
19 +| 3 | YZ | Qingger云助产品 |
20 +| 4 | ESH | Qingger云商城 |
21 +| 5 | PSH | Qingger积分商城 |
22 +| 6 | B2B | Qingger B2B产品 |
23 +| 7 | POR | Runsa门户 |
24 +| 8 | CRM | Runsa CRM |
25 +| 9 | DRP | Runsa DRP |
26 +| 10 | O2O | Runsa 电商管理平台O2O产品 |
27 +
28 +
29 +
30 +### 2. 建立和删除Topic
31 +
32 +#### 2.1 建立Topic
33 +
34 +- Topic 命名方法:{客户编号}-{环境编号},表示不同的客户在不同的环境所使用的Topic;
35 +
36 +- 客户编号:取客户官方英文名并去掉除英文字母外的其他字符,然后转成大写;
37 +
38 + 例如:星期六的官方英文名是st-sat,因此星期六的客户编号为STSAT;
39 +
40 + ​ 兴记的官方英文名是stellafashion,因此兴记的官方编号是STELLAFASHION。
41 +
42 +- 环境编号:使用TEST代表测试环境,DEMO代表演示环境,PRODUCTION代表正式环境,DEV代表开发环境。
43 +
44 +- 以下为Topic 名称的几个例子:
45 +
46 + STSAT-TEST:星期六测试用Topic;
47 +
48 + STELLAFASHION-PRODUCTION:兴记生产用Topic
49 +
50 +#### 2.2 删除Topic
51 +
52 +- 遵循谁建立谁删除的原则;
53 +
54 +### 3. 在Topic上发布消息
55 +
56 +- 在Topic上发布消息时,除了消息体外,一定要设置一个标签,以便其他应用能够过滤和识别消息类型;
57 +
58 +- 标签命名方法:{应用名称}-{业务名称};
59 +
60 +- 应用名称:即 **1** 中所列出的产品英文名称;
61 +
62 +- 业务名称:根据各应用自己的业务来定义,使用做多12为的大写英文字母;
63 +
64 + 例如: 雇员相关的消息,业务名称可以定义为EMPLOYEE
65 +
66 + ​ 账户相关的消息,业务名称可以定义为USER
67 +
68 +- 以下为标签的几个例子:
69 +
70 + POR-EMPLOYEE:门户发布的雇员信息
71 +
72 + CRM-POINT:CRM发布的积分信息
73 +
74 +### 4. 在Topic上订阅消息
75 +
76 +#### 4.1 订阅名称
77 +
78 +- 订阅名称命名方法:{环境编号}-{订阅者应用名称}-{客户编号}-{发布者应用名称}-{业务名称};
79 +
80 +- 环境编号:订阅者环境编号,其值与 **2.1** 中的环境编号一致;
81 +
82 +- 订阅者应用名称:即 **1** 中所列出的产品英文名称;
83 +
84 +- 客户编号:与 **2.1** 中的客户编号一致;
85 +
86 +- 发布者应用名称:即 **1** 中所列出的产品英文名称;
87 +
88 +- 业务名称:与 **3** 中的业务名称一致;
89 +
90 +- 以下为订阅名称的几个例子:
91 +
92 + DEV-YZ-STSAT-POR-EMPLOYEE:云助开发环境订阅了星期六门户发布的雇员消息
93 +
94 + PRODUCTION-DZ-STELLAFASHION-CRM-SITE:店助生产环境订阅了兴记CRM发布的网点消息
95 +
96 +#### 4.2 接收端地址
97 +
98 +- 推送类型为http
99 +
100 +
101 +- 可以理解为收到推送消息的回调地址,需要个应用自己开发API接口;
102 +
103 +- 为了让回调地址可以最大程度重用,可以在创建订阅时在url上带上自己需要的参数;
104 +
105 + 例如:http://emp.api.dev.qingger.com/mns/topic/stsat/por/employee 中,
106 +
107 + http://emp.api.dev.qingger.com为接口域名,/mns/topic为接口路径,/stsat/por/employee为自定义参数,分别可以帮助各应用确定公司客户,发布者以及业务类型。
108 +
109 +#### 4.3 重试策略、消息推送格式
110 +
111 +- 重试策略:使用退避重试
112 +- 消息推送格式:统一使用JSON格式
113 +
114 +
115 +
116 +## 版本更新
117 +
118 +v0.1 : 2017/04/01 发布此规范
...\ No newline at end of file ...\ No newline at end of file
......