微信的业务架构图

1. 总体业务

2. 一些前台重点子业务

学生管理系统-毕设架构设计

方案一

方案描述:

1.因为涉及到公网访问, 最好是接入公网 DNS

2.考虑到有 1000 学生, 以及配套老师的情况下, 抢课等极限场景下, 峰值 QPS / TPS 会达到 1000+, 所以用 3 台服务器(或容器)做集群, 每台服务器起 3 个实例, 单实例平均峰值约 100 左右, 相对来说优化成本相对较低, 遇到瓶颈可以通过水平扩展 SERVER 提高能力

3.考虑到应用内可以使用连接池进行管理, 可以采用 SHARDING-JDBC 等类库进行读写分离, 减少系统的压力, 但是因为是正式使用, 数据备份等实际需求需要考虑, 所以需要至少 2 台数据库

优势: 每个实例内的代码一致, 容易扩展, 且技术栈一致, 团队协作比较容易

劣势: 机器成本相对比较高, 且 Java 实现界面部分改动成本较高

方案二

方案描述:

1.因为涉及到公网访问, 最好是接入公网 DNS

2.考虑到团队中有 PHP 高手, 考虑到 PHP 的资源占用较低, 所以将前台界面部分和查询功能都由 PHP 实现, 最大化的利用服务器资源

3.由于会有抢课, 课表排期, 考试排期, 试题拼装等复杂计算场景, 以及一些定时调度功能, 这部分 JAVA 更擅长, 同时由于上层有 PHP 的过滤和聚合, 流量到 JAVA 系统已经比较可控, 单实例或单机双实例即可

4.数据库还是使用读写分库, PHP 系统直接读取从库, JAVA 系统主要写主库, 有些查询场景可以使用从库进行负载

优势: 成本相对较低, 可以最大限度发挥团队成员的优势, PHP 修改发布比较方便

劣势: 异构系统在后期维护存在门槛, 掌握 PHP 技能的团队成员成为单点, 且 JAVA-SERVER 后期扩展多实例的时候, 需要增加调度器

最终选择

个人最终选择方案二, 该方案综合成本低(机器资源低, 开发成本低), 扩展方便, 且读写物理隔离, 异常场景下影响比较小

一般在学校中, 指标场景猛增的概率比较低, 有比较充足的预留资源去扩展, 后期如果真的有大规模的扩展需求, 可以将 PHP 替换成 JAVASCRIPT+NODE 为主的前端工程, 无缝过度到前后端分离场景