5.2软件架构的历史背景和目的

软件架构的历史

软件架构的出现有其历史必然性，计算机最开始使用的是机器指令进行编程，由于全是0和1组成的数字串，对编程人员十分的不友好，然后汇编语言就应运而生。汇编语言只是简单的用注意词替换机器指令，虽然只是简单的替换，很简陋但至少汇编的指令看起来比一长串的0和1好很多。而且可以有望文生义的功能，基本上可以看到指令，就知道是要做什么操作。但是随着软件的流行软件的规模开始变得越来越大，汇编指令写出来的程序，其弊端就显露出来了。最典型的就是IBM开发的操作系统360。这是一个失败的项目，项目负责人还因此写了一本书，叫做《人月神话》。

这个时期，软件开发难度太大造成了所谓的第1次软件危机。为了解决这次危机，就有人提出了结构化编程的概念，也就是我们常说的面向过程编程。可到了20世纪80年代的时候，由于计算机的快速发展，软件功能越来越强大，软件的复杂度也越来越高，导致面向过程的编程方法已经不再适用软件的更大规模的扩展，这时候就引出了面向对象的编程思想。

到了20世纪90年代，软件架构这个说法开始流行，而且创造了组件这个概念。我们可以看到从模块到面向对象到组件，本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的力度越来越粗，拆分的层次越来越高。

卡内基梅隆大学的马立肖和戴维嘉兰对软件架构做了很多研究，他们在1994年的一篇文章软件架构介绍里面写道，随着软件系统规模的增加，计算相关的算法数据结构不再构成主要的设计问题，但系统有许多部分组成时，整个系统的组织也就是所说的软件架构导致了一系列新的设计问题。

比如说系统规模庞大，内部耦合严重，开发效率极低。

系统耦合严重，牵一发动全身后续修改和扩展困难。

系统逻辑复杂，容易出问题，出问题后很难排查和修复。

所以软件架构的出现是势在必然的，是软件技术发展的内在需求。

软件架构的目的

由此我们也可以清楚地知道，软件架构的目的就是为了解决软件系统复杂度带来的一系列问题。

这个结论虽然很简洁，但是却是架构设计过程中需要时刻铭记在心的第1条准则，首先遵循这条准则的新手架构师能够心中有数，而不是一头的雾水。其次，遵循这条准则也能够让老鸟架构师有的放矢，而不是贪大求全。

简单的复杂度分析案例

假如我们需要设立一个大学的学生管理系统，其基本功能包括登录注册，成绩管理，课程管理等。

当我们对这样一个系统进行架构设计的时候，

首先应该识别其复杂度的复杂到底体现在哪里，性能方面，一个学校的学生大约1~2万人，学生管理系统的访问频率并不高，平均每天单个学生的访问次数平均不到一次，因此性能这部分并不复杂，存储用Mexico完全能够胜任，缓存都可以不用那个服务器用nginx绰绰有余。

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

另外在高可用方面，学生管理系统及时档期两个小时，对学生管理工作影响也不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案了。但是如果学生的数据全部丢失，修复的过程是非常麻烦的，只能靠人工逐条修复，这个是不能接受的，因此需要考虑存储的高可靠性，这里就有点复杂了，我们需要考虑多种异常情况，比如说机器故障，机房故障，针对机器故障，我们需要设计马赛克同机，房主备方案，针对机房故障，我们需要设计跨机房同步方案。

在一个安全性方面，学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，学生的成绩等，但并不是说和金融类信息那样的，也不包含强隐私性的信息，因此安全性方面只要做到三个事情就基本可以了，即nginx提供ACL控制,用户账号密码管理，数据库访问权限。

在成本方面由于系统很简单，基本上几台服务器就能够搞定，对一所大学来说完全不是问题，可以无需太多关注。

通过上面的分析，我们可以清楚的明白这个方案的复杂性主要体现在存储的可靠性上，就是说保证系统异常的时候，不要丢失所有的数据即可。

学生管理系统非常简单，但麻雀虽小，五脏俱全，基本上能涵盖软件系统复杂度分析的各个方面，而且绝大部分技术人员都曾经自己设计或者接触过类似的系统，结合自己的编程经验，分析之后能切实感觉到有不小的收获。