Shaw)和戴维加兰

软件架构真正流行是从20世纪90年代开始的由于在Rational和Microsoft内部的相关活动软件架构的概念开始越来越流行。

Shaw)和戴维加兰

随着软件系统规模的增加计算相关的算法和数据结构不再构成主要的设计问题当系统由许多部分组成时整个系统的组织也就是所说的“软件架构”导致了一系列新的设计问题。

1系统规模庞大内部耦合严重开发效率低2系统耦合严重牵一发动全身后续修改和扩展困难3系统逻辑复杂容易出问题出问题后很难排查和修复。

关于架构设计的目的常见的误区有“因为架构很重要所以要做架构设计”这是一句正确的废话架构是很重要但架构为何重要呢

不做架构设计系统就跑不起来么

其实不然很多创业公司可能就没有架构设计简单的讨论一下用户诉求就开始编码实现只要功能能正常使用就可以了也不会有很多用户量。

也不尽然实际上有时候最简单的设计开发效率反而最高的架构设计毕竟需要投入时间和人力这部分投入如果用来今早编码项目也许会更快。

好像有一定的道理例如设计高性能的架构能够让用户体验更好但反过来想我们照抄微信的架构业务就能达到微信的量级么肯定不可能。

不是每个系统都需要做架构设计。

如果生搬硬套业界其他公司已有的架构有可能造成架构水土不服或者运行起来特别扭的情况最后往往需要不断重构甚至无奈推倒重来。

目前所在的公司做的一个项目强行引入某框架导致的后续问题不断早期我就提出过这个框架的问题后续框架问题不断且问题难以定位框架和代码耦合严重也难以扩展已经达到了需要重做的地步。

所以框架架构选型一定要根据实际情况来做否则适得其反。

整个软件技术发展的历史其实就是一部与“复杂度”斗争的历史架构的出现也不例外。

简而言之架构也是为了应对软件系统复杂度而提出的一个解决方案通过回顾架构产生的历史背景和原因我们可以基本推导出答案架构设计的主要目的是为了解决软件系统复杂度带来的问题。

以学生管理系统基本功能包括登陆、注册、成绩管理、课程管理等。

首先需要识别复杂度在哪。

性能一个学校的学生大约12万人学生管理系统的访问频率并不高平均每天每个学生的访问次数平均不到1次因此性能这部分并不复杂存储用MySQL完全能够胜任缓存可不用Web服务器用Nginx绰绰有余。

可扩展性学生管理系统的功能比较稳定可扩展的空间并不大因此可扩展性也不复杂。

高可用学生管理系统即使宕机2小时对学生管理工作影响并不大因此可以不做负载均衡更不用考虑异地多活这类复杂的方案。

但是如果学生的数据全部丢失修复是非常麻烦的只能靠人工逐条修复这个很难接受因此需要考虑存储高可靠这里就有点复杂了。

我们需要考虑多种异常情况机器故障、机房故障针对机器故障我们需要设计MySQL同机房主备方案针对机房故障我们需要设计MySQL跨机房同步方案。

安全性学生管理系统存储的信息有一定的隐私性例如学生的家庭情况但并不是和金融相关的也不包含强隐私因此安全性方案只要Nginx提供ACLAccess

Control

List控制、用户账户密码管理、数据库访问权限控制。

成本由于系统简单基本上几台服务器就能搞定成本不高。

整体架构如下

学生管理系统虽然简单但基本上能涵盖软件系统复杂度分析的各个方面正所谓麻雀虽小但五脏俱全。