软件架构的历史背景
软件架构真正流行是从20世纪90年代开始的，由于在Rational和Microsoft内部的相关活动，软件架构的概念开始越来越流行。
卡内基梅隆高校的玛丽肖(Mary Shaw)和戴维加兰 (David Garlan)对软件架构做了许多讨论,他们在 1994 年的一篇文章《软件架构介绍》(An Introduction to Software Architecture）中写到：
“When systems are constructed from many components，the organization of the overall system-the software architecture presents a new set of design problems.”
随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。
所以只有规模较大的软件系统才会面临软件架构相关的问题，例如：
- 1）系统规模庞大，内部耦合严重，开发效率低；
- 2）系统耦合严重，牵一发动全身，后续修改和扩展困难；
- 3）系统逻辑复杂，容易出问题，出问题后很难排查和修复。
架构设计的误区
关于架构设计的目的，常见的误区有：“因为架构很重要，所以要做架构设计”，这是一句正确的废话，架构是很重要，但架构为何重要呢？
不做架构设计系统就跑不起来么？
其实不然，很多创业公司可能就没有架构设计，简单的讨论一下用户诉求就开始编码实现，只要功能能正常使用就可以了，也不会有很多用户量。
做了架构设计就能提升开发效率么？
也不尽然，实际上有时候最简单的设计开发效率反而最高的，架构设计毕竟需要投入时间和人力，这部分投入如果用来今早编码，项目也许会更快。
设计良好的架构能促进业务发展么？
好像有一定的道理，例如设计高性能的架构能够让用户体验更好，但反过来想，我们照抄微信的架构，业务就能达到微信的量级么？肯定不可能。
不是每个系统都需要做架构设计。如果生搬硬套业界其他公司已有的架构，有可能造成架构水土不服，或者运行起来特别扭的情况，最后往往需要不断重构，甚至无奈推倒重来。目前所在的公司做的一个项目强行引入某框架导致的后续问题不断，早期我就提出过这个框架的问题，后续框架问题不断，且问题难以定位，框架和代码耦合严重也难以扩展，已经达到了需要重做的地步。所以框架架构选型一定要根据实际情况来做，否则适得其反。
架构设计的真正目的
整个软件技术发展的历史，其实就是一部与“复杂度”斗争的历史，架构的出现也不例外。简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案：架构设计的主要目的是为了解决软件系统复杂度带来的问题。
简单的复杂度分析案例
以学生管理系统，基本功能包括登陆、注册、成绩管理、课程管理等。首先需要识别复杂度在哪。
- 性能：一个学校的学生大约1～2万人，学生管理系统的访问频率并不高，平均每天每个学生的访问次数平均不到1次，因此性能这部分并不复杂，存储用MySQL完全能够胜任，缓存可不用，Web服务器用Nginx绰绰有余。
- 可扩展性：学生管理系统的功能比较稳定，可扩展的空间并不大，因此可扩展性也不复杂。
- 高可用：学生管理系统即使宕机2小时，对学生管理工作影响并不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案。但是，如果学生的数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，这个很难接受，因此需要考虑存储高可靠，这里就有点复杂了。我们需要考虑多种异常情况：机器故障、机房故障，针对机器故障，我们需要设计MySQL同机房主备方案；针对机房故障，我们需要设计MySQL跨机房同步方案。
- 安全性：学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，但并不是和金融相关的，也不包含强隐私，因此安全性方案只要：Nginx提供ACL（Access Control List）控制、用户账户密码管理、数据库访问权限控制。
- 成本：由于系统简单，基本上几台服务器就能搞定，成本不高。
整体架构如下，
学生管理系统虽然简单，但基本上能涵盖软件系统复杂度分析的各个方面，正所谓麻雀虽小但五脏俱全。