【通用消息通知服务】0x1 - 前期设计

【通用消息通知服务】0x1 - 前期设计

本专栏皆是本人经验总结，并非正经方法论。请自我甄别借鉴。

整体架构设计

1. 思考整个服务应该提供什么接口协议提供服务?

GraphQL, RPC, RESTful或者其他协议。

2. 思考整个服务会有哪几个部分组成?

   • 消息终端
   • 消息渠道
   • 消息模板
   • 计划调度
   • 消息回执

3. 思考哪些数据需要存储?

   • 消息终端: 存储消息送达方的对应渠道的ID, 比如邮件渠道就会是邮箱地址, 微信渠道就会是微信ID
   • 消息渠道配置
   • 消息模板
   • 消息计划
   • 消息计划执行记录
   • 消息发送记录
   • 消息回执

4. 思考这些数据需要什么存储能力?

   0x1. 从数据结构思考

   • 消息终端: 随着消息渠道变动，终端数据项会变动，适合NoSQL或者以JSON存储
   • 消息渠道配置: 配置格式随着渠道会有不同，适合NoSQL或者以JSON存储
   • 消息模板: 模板随着渠道变化, 适合NoSQL或者以JSON存储
   • 后者都是结构化数据，随意。

   0x2. 从未来数据量思考

   • 消息终端: 具备持续增长可能
   • 消息渠道配置: 渠道有限，配置可持续增长，但整体不会增长过快过大
   • 消息模板: 有限数量
   • 消息计划: 持续增长
   • 消息计划执行记录: 持续快速增长
   • 消息发送记录: 持续快速增长, 无论是计划触发或单独触发，基于单进程1k每秒，那一天可增长86400k条记录,一个月259亿条记录。适合NoSQL
   • 消息回执: 持续快速增长, 无论是计划触发或单独触发，基于单进程1k每秒，那一天可增长86400k条记录,一个月259亿条记录。适合NoSQL

   0x3. 从数据使用场景思考

   • 消息终端: 被其他服务或者手工导入添加，在发送阶段被查询，大屏可视化被展示整体数量，分布，分类等等。
   • 消息渠道配置: 被其他服务或者手工导入添加修改删除, 简单展示
   • 消息模板: 被其他服务或者手工导入添加修改删除, 简单展示
   • 消息计划: 被其他服务或者手工导入添加修改删除, 简单展示
   • 后者都是只能被查询，不能被外界更改删除，简单展示，可视化实时发送数量等

   0x4. 结合开发人员技术栈和后期维护可能展开结论

   Postgres,MySQL的JSON和Mongodb, Dynamodb都能很好解决第一点思考, 第二点的话，可以分别使用Pg,MySQL存储前三个，其余用Mongodb,Dynamodb存储。第三点提示我们要考虑是否需要数据强一致性还是数据最终一致性。由于后者都只需要查询，所以我们考虑前者，前者如果使用Pg,Mysql也没有问题。Pg, Mongo都是比较成熟的技术栈了，文档齐全，更新速度稳定。所以分开使用Pg存储前者, Mongo存储后者即可。

5. 思考采用什么架构?

   由于消息系统需要的是快和可靠， 考虑到除了发送以外的必要数据库和网络io等操作都可以延后，只要最终一致即可。同时要支持水平扩展，我觉得微服务+事件驱动的组合会比较适合。

   因为整个服务可以分为配置+发送(执行)+计划调度三个，这三个作为微服务去设计，可以在部署的时候更加灵活。(比如计划太多无法在短时间内处理完毕则可以通过只增加计划调度的机器或计算资源即可)