本文在介绍一个中台系统——通知中心的设计。上一篇文章《一个广告资源运营管理中台系统简介》其实已经讲了一些,关于中台这里就不在赘述了。把通知中心做成中台系统,优点显而易见,任何部门涉及发送消息相关业务时,都可以接入进来。业务部门负责发送内容的填充,通知中心负责把消息发送出去。因为要发送的消息类型很多:短信、push消息、app站内信、微信公众号推送、企业微信通知推送、邮件等等,显然这是一个挺复杂的事。
基本概念:
应用:就是接入通知中心的工程。接入时需要填写应用名,然后管理后台会生成相应的app key及app secret。发送时需要传入这些参数,以验证接入方的合法性。
节点:也可以理解为发送事件,一个工程可能做好几件事,那么不同业务发送的消息就需要建不同发送节点。所以一个应用下面可以建很多节点。
规则:根据不同入参选择不同模板。为了做的尽可能灵活可配置,规则实际上就是把本来接入方的if…else…逻辑移到了通知中心后台,比如:根据新老用户发送不同消息,有了规则配置,接入方只需要定义一个变量,并赋值即可,然后在后台配置规则。如果是新用户,使用A模板,如果是老用户,使用B模板,点点鼠标就完成了。
模板:主要包含公众号模板、站内信模板、Push消息模板、短信模板等等,这些都是发送量比较多的消息了。定义模板时可以放占位符,接入方只需做做占位符填空题就可以了。发送时通知中心会自动完成信息组装。
下面是一些页面截图。
1. 新建节点
2. 新建模板
3. 新建规则
那么怎么使用呢?比如有一个业务场景是给用户发push通知,告诉用户系统送他一张100元代金券。针对这个场景,就可以建一个发送节点,然后新建模板:“尊敬的用户,系统送您一张${amount}元代金券,请及时使用”,然后新建规则并关联模板。作为业务方,接入成本比较低,代码量比较少,因为大部分工作通知中心已经做了,业务方只需要做一些参数的填充即可,比如上面模板,代码里面设置amount为100,就是发100元的代金券;amount为50,就是发50元的代金券。如果运营人员觉得文案不妥,可以在管理后台随时修改。下面是代码示例:
private McRequest genMcRequest(MessageBody msg) {
McRequest mcRequest = new McRequest();
mcRequest.setAppKey(msg.getAppKey());
mcRequest.setAppSecret(msg.getAppSecret());
// 配置事件
mcRequest.setEventKey(msg.getAppEventKey());
Map<String, String> eventParamMap = Maps.newHashMap();
List<MessageParam> eventParams = msg.getEventParams();
for (MessageParam param : eventParams) {
eventParamMap.put(param.getParamKey(), param.getParamValue());
}
mcRequest.setEventParams(eventParamMap);
// 配置模板
Map<String, String> contentParamMap = Maps.newHashMap();
List<MessageParam> contentParams = msg.getContentParams();
for (MessageParam param : contentParams) {
contentParamMap.put(param.getParamKey(), param.getParamValue());
}
mcRequest.setContentParams(contentParamMap);
mcRequest.setUid(msg.getReceiverId());
mcRequest.setCreator(MSG_CREATOR);
return mcRequest;
}
@Override
public void sendMessage(MessageBody msg) throws ServiceException {
McRequest mcRequest = genMcRequest(msg);
RequestResult requestResult = mcService.postEvent(mcRequest);
LOGGER.info("result is : " + JSONObject.toJSONString(requestResult));
}
引用上篇文章结尾那句话,这样的系统复杂归复杂,但是要相信自己能做的更好。