myBuilder实现PC端与移动端的消息通知

核心知识与原理

模板消息

模板消息 是指服务提供方（开发者）在向用户发送重要的服务通知 时，必须使用的一种结构化、标准化消息格式。

其核心目的 是：

保证消息的规范性 ：避免服务商向用户发送随意、杂乱、营销性的垃圾信息。

提升消息的辨识度和可信度 ：用户看到统一格式的消息，能快速识别这是重要的服务状态变更通知。

提高 可维护性： 通过界面维护模板消息的文案，关键业务字段用占位符动态替换，在修改非关键字段时保存下模板就立即生效，不用改业务系统代码。

平衡用户体验与商业需求 ：在互联网平台的消息场景，允许服务商触达用户的同时，通过严格的格式和发送条件限制，平台审核，保护用户免遭骚扰。

以下是myBuilder开发平台的消息模板管理页面效果与设计效果

myBuilder采用****${业务字段}**** 的占位符格式定义外部字段。

在一些高阶的场景，还需要支持明细表的字段模板替换，可以动态发送一个表格数据，如下格式所示。

从服务器到浏览器的消息推送技术

这是BS架构下消息技术的核心挑战，目标是让服务器能主动、实时地向客户端（浏览器）发送数据。

1. 短轮询

原理：浏览器通过JavaScript定时器（如每隔2秒）向服务器发送HTTP请求，询问是否有新消息。无论服务器是否有数据，都立即返回响应（有数据则返回数据，无数据返回空）。

特点：

优点：实现非常简单，兼容性极好。

缺点：大量无效请求，浪费服务器和网络资源，实时性差（取决于轮询间隔）。

适用场景 ：对实时性要求不高的简单应用，如简单的邮件检查。

2. 长轮询

原理：浏览器发起一个请求到服务器。服务器会保持这个连接打开 ，直到有实际数据可发送、或超时发生。浏览器收到响应后，立即发起下一个新的长轮询请求。

特点：

优点：比短轮询实时性好，减少了大量无效请求。

缺点：服务器需要保持大量并发连接，有性能开销。连接建立/关闭仍有开销。

适用场景 ：早期的网页聊天室、简单通知系统。是Comet技术的一种实现。

3. 服务器发送事件

原理：基于HTTP协议，浏览器通过EventSource API与服务器建立单向持久连接 。连接建立后，服务器可以持续地以"事件流"的格式向浏览器推送文本消息。连接断开后，浏览器会自动尝试重连。

特点：

优点：是真正的"服务器推送"，协议轻量、自动重连、使用简单。

缺点：仅支持文本数据 ，且是单向的（服务器到客户端）。

适用场景 ：实时新闻推送、股票行情、监控日志流、社交网站动态更新等只需服务器单向推送的场景。

4. WebSocket

原理：在HTTP握手之后，升级为独立的、全双工的、基于TCP的WebSocket协议 。连接建立后，客户端和服务器可以随时、双向地发送数据（文本或二进制），没有请求-响应模式的限制。

特点：

优点：真正双向实时通信 ，延迟极低，头部开销小，连接持久。

缺点：协议相对复杂，需要服务器和客户端专门实现。对于代理和防火墙的兼容性需要处理。

适用场景 ：几乎所有需要高实时性、双向交互的场景 ，如在线游戏、协同编辑、实时聊天、股票交易终端、物联网仪表盘。

以下是这几种技术的对比：

|-------------------|-------------------|---------------|----------------|--------------------|
| 技术 | 通信方向 | 协议/模式 | 适用场景 | 特点 |
| 短轮询 | 客户端主动 | HTTP 请求-响应 | 低实时性检查 | 简单，浪费资源 |
| 长轮询 | 客户端主动（模拟推） | HTTP (Comet) | 中等实时性通知 | 比短轮询高效，连接有开销 |
| SSE | 服务器单向推 | HTTP 流 | 实时新闻、日志、单向通知 | 标准、轻量、自动重连 |
| WebSocket | 服务器与客户端双向 | WebSocket 全双工 | 聊天、游戏、协同、高实时交互 | 实时性最高，双向通信 |