架构实战营 - 作业 01
微信业务架构图
红色为核心业务
蓝色为非核心业务

学生管理系统 架构设计
方案一

优点
极简方案,单实例,成本低,冷数据可使用缓存解决,提高响应效率
缺点
过于简单,答辩无逼可吹。
宕机无法提供服务
方案二

优点
做了 upstream 可拓展设计,除非是搞活动,抢课等并发的情况基本上不用再加机器(1000 个学生概率非常低了)。
server 间用内网访问,两个 redis 做主从,开 AOF 基本满足需求,并发业务场景可以通过 redis 合理拒绝一些请求。无需考虑共享用户态问题。
Mysql 使用做主从,故障时自动切换主从。
缺点
花点钱,nginx 使用云产品 ELB,SLB 的话,不贵但也是成本。
资源有点浪费,因为项目是非高可用项目,多了三台实例。
方案三

优点
同样还是做 uptream,但这里使用权重,Server B 服权重较低,主流量从 Server A 进。
数据层,包括 Mysql,Redis 都做主从,防止数据丢失。
数据层【主】都在 Server B 上,有效利用资源,避免资源闲置,浪费。
保证服务可用性前提下,进一步降低成本
缺点
由于某一个服务使用不当都会影响整台机的性能,如程序写了死循环,CPU 一路飙升,OOM,数据层被迫发生主从切换。
最终选择方案 - 方案三
参考以上三个方案, 及根据原题目的假定前提,选取了方案三
使用两个实例做高可用,但避免过度浪费资源
可拓展型,后续加机器可直接拉起一个 docker 后端服务即可,配置用同一套配置,方便维护
不至于说太简单,主从同步知识,redis 主从同步知识,加 nginx upstram 负载均衡等,可以再加上 docker 容器化后端服务,或者 ABtest,滚动发版,想怎么吹怎么吹。
评论