im 业务架构

如上为单 idc 的架构. 大体划分为三层, 接入层, 业务逻辑层和存储层. 右侧为业务支撑系统.

接入: 接入层有长短连接, 长连接用于聊天, 推送, 基础功能的 rpc 等, 短连接可用于 http 接口访问. 当长连接不可用时, 部分 rpc 可走短连接. 对于不同重要程度业务/不同量级/不同安全要求业务 需要有不同的接入集群, 比如支付需要单独接入.

在接入层之前还有一层接入调度层, 用于最优接入.

逻辑: im 为整个体系基础, 提供在线状态, 资料, 关系链, 消息, 推送等最基础功能. 区分好业务之间的界限, 其他功能均可以看成 im 之上的应用.

存储: 存储很重要, 每个服务可能都有专门的存储, 减少相互影响, 针对不同的服务选择不同的存储. 同时海量数据, 需要考虑成本, 做冷热数据分离.

多 idc: 用户会划分多 idc, 这样需要有跨 idc 的机制, 比如跨 idc rpc 调用, 用户信息修改同步, 消息分发. 跨 idc 操作分为同步和异步, 同步需要有专门的专线代理, 减少跨 idc, 甚至跨洲的网络引起的问题, 异步由消息队列进行数据分发.

不同的服务有不同的多 idc 部署要求.

学生管理系统

对于简单/量级要求不高的应用, 快速开发, 可维护性高于模块复用性, 尽量部署简单, 语言一致, 可预见未来, 单体服务都没啥问题.

不过服务里尽量做到拆分好模块和 package, 逻辑层和存储层拆分一下包, 前后端分离.

阿里云的服务不太了解, 一般选择弹性接入层+cvm+可加备机(根据需求选择异步/半同步)的 mysql 即可.

一般学生管理系统基本不存在性能问题. 主要在抢课时对性能会高一些, 如果有性能问题, 可以根据业务功能对相关代码做一些优化.

比如对课程列表及详细数据做 1min 级别的内存缓存, 抢完的课程因为数据不再变, 可以设置长一点的 5min 的缓存.

对于课程限制总人数, 报名人数, 可以单独搞一张表, 字段简单, 性能高. 做秒级别的内存缓存.

在一致性, 性能, 用户体验之间做到权衡.

或者更简单点, 报名+后台摇号的方式进行抢课.