软件架构
随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题：当系统由许多部分组成时，整个系统的组织，也就是所说的“软甲架构”，导致了一系列新的设计问题。
只有规模较大的软件系统才会面临软件架构相关的问题，比如：
- 系统规模庞大，内部耦合严重，开发效率低;
- 系统耦合严重，牵一发动全身，后续修改和扩展困难;
- 系统逻辑复杂，容易出问题，出问题后很难排查和修复。
架构设计的目的
架构设计的误区
- 因为架构很重要，所以要做架构设计 （正确的废话）
- 例如：不做架构设计系统就跑不起来了吗？
- 例如：做了架构设计就能提示开发效率么？
- 例如：设计良好的架构能促进业务发展吗？
- 不是每个系统都要做架构设计吗
- 例如：强行架构
- 公司流程要求系统开发过程中必须有架构设计
- 为了高性能、高可用、可扩展，所以要做架构设计
- 根据业务或者系统，盲目就一定是有大问题的。
架构设计的真正目的
一条准则,也可以说是一个原则
架构设计的目的是为了解决软件系统复杂度带来的问题
明确了架构设计的目的是为了解决软件系统复杂度带来的问题，就能回答下述问题：
这么多需求，从哪里开始下手进行架构设计呢？
- 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计
架构设计要考虑高性能、高可用、高扩展…这么多高XX，全部设计完成估计要一个月，但老大只给了一周时间。
- 架构设计并不是面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后又针对性地解决问题
业界A公司的架构师X，B公司的方案是Y，两个差别比较大，该参考那一个呢?
- 理解每个架构方案背后所需要解决掉复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。
遵循这条准则。能够让架构师“有的方矢，而不是贪大求全”
我们的系统一定要做到每秒TPS 10万
- 如果系统的复杂度不是在性能这部分，TPS做到10万并没有什么用。
淘宝的架构师这么做的，我们也这么做
- 淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度而设计的，淘宝的业务复杂度并不就是我们的业务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。
Docker现在很流行，我们的架构应该将Docker应用进来
- Docker不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不是在这方面，引入Docker没有什么意义。
简单的复杂度分析案例
一起来看看如何将“架构设计的真正目的就是解决软件系统复杂度带来的问题”
简单的案列：设计一个大学的学生管理系统
- 基本功能
- 登录
- 注册
- 成绩管理
- 课程管理
- 等
当我们对这样一个系统进行架构设计的时候，首先应识别其复杂度到底体现在哪里
性能：
学生1-2万人，访问系统频率不高，平均每天单个学生访问量不到一次，存储使用MySQL完全足够，缓存都可以不用，Web服务器用Nginx完全足够
可扩展性：
学生管理系统的功能比较稳定，可扩展的空间并不大，因此可扩展性也不复杂
高可用：
学生管理系统即使宕机2小时，对学生管理系统工作影响并不大，因此可用不做负载均衡，更不用考虑异地多活这类复杂的方案了。但是，如果学生的数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，这个很难接受。
因此需要考虑存储高可靠，这里就有点复杂了。我们需要考虑多种异常情况：机器故障，机房故障，针对机器故障，我们需要设计MySQL同机房主备方案；针对机房故障，我们需要设计MySQL跨机房同步方案。
安全性
学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，但并不是和金融相关的，也不包含强隐私（例如玉照。。）的信息，因此安全信只要做三个事情就满足了，
Nginx提供的ACL控制、用户账号密码管理，数据库访问权限控制。
成本：
系统很简单，基本上几台服务器就能够搞定，无需过多关注。
还有其他方面，这个分析下来，这个方案的主要复杂性体现在存储可靠性上，需要保证异常的时候，不要丢失所有数据即可（丢失几个或几十个学生信息问题不大）