从0开始学架构之架构的目的

前言

本文介绍架构的目的是什么，架构是解决什么问题。

目的

架构的目的不是为了架构而架构，不是别人做了所以自己要做，不是为了技术自嗨。。。

架构的真正目的在于解决软件系统复杂度带来的问题。这条准则可以让新手架构心里有数，不会一头雾水，让老手架构有的放矢，不要贪大求全。

有了指导思想，让我们来举个例子，看如何将“解决软件系统复杂度带来的问题”应用到实践。

简单复杂度分析案例

假设我们需要设计一个大学的学生管理系统，其基本功能包括登录、注册、成绩管理、课程管理等。当我们对这样一个系统进行架构设计的时候，首先应识别其复杂度到底体现在哪里，从下面几个角度全方位考虑。

1、性能
学校大约1 ~ 2万人，平均每个学生访问系统不超过一次，所以性能上不复杂，存储用MySQL，服务器用Nginx，缓存是不需要的。

2、扩展性
学校系统功能稳定，可扩展的空间并不大，因此可扩展性也不复杂。

3、可用性
学校管理系统没有太高的可用性要求，即使服务器发生宕机1 ~ 2个小时也是没有问题的。不过，数据存储可靠性上有要求，不能容忍丢失大量数据。所以要考虑多种异常情况，比如机器故障，机房故障等。对于机器故障，可以考虑MySQL同机房主备；对于机房故障，可以做MySQL跨机房备份。

4、安全性
学生的信息还是有一定的隐私性的，但没有不要求像银行、金融那样的高安全性。只需要采用密码登录、HTTPS通信、数据库访问权限控制等方案就行。

5、成本
由于系统简单，访问量和存储数据量都不大，所以基本几台服务器就可以搞定。

复杂度来源

架构设计中，常见的几个考虑点：

1、性能
（1）访问量或并发量。确认日平均访问量，并判断是否存在高并发，短时间大流量（高峰期）情况，高峰期流量多少。
（3）响应速率。是否有低延迟要求，延迟要求是秒级还是分钟级。

2、可用性
（1）服务可用。可以容忍服务器宕机多长时间，1分钟还是1小时。
（2）存储可用。可以容忍多少数据丢失，一部分还是大量。

3、扩展性
（1）功能扩展。是否方便支持新的功能加入。
（2）水平或垂直扩展。是否支持增加相同功能的服务器（水平）或增加提供不同功能的服务器（垂直）。

4、安全性
看业务场景提供多高级别的安全性。

5、成本
在可行的方案中选择成本较低的。当然，如果资金足够且业务重要，可以选择成本高些的更可靠的方案。

参考

• [1] 从0开始学架构