“为何要做架构设计？”或者“架构设计目的是什么？”类似的问题，大部分人可能从来没有思考过，或者即使有思考，也没有太明确可信的答案。

架构设计的误区

关于架构设计的目的，常见的误区有：

• 因为架构很重要，所以要做架构设计

  这是一句正确的废话，架构是很重要，但架构为何重要呢？

  • 不做架构设计系统就跑不起来么？
  • 做了架构设计就能提升开发效率么？
  • 设计良好的架构能促进业务发展么？
  • 不是每个系统都要做架构设计吗?
  • 公司流程要求系统开发过程中必须有架构设计
  • 为了高性能、高可用、可扩展，所以要做架构设计

架构设计的真正目的

那架构设计的真正目的究竟是什么？

从架构设计的历史背景可以看到，整个软件技术发展的历史，其实就是一部与“复杂度”斗争的历史，架构的出现也不例外。简而言之，架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案：架构设计的主要目的是为了解决软件系统复杂度带来的问题。

这个结论虽然很简洁，但却是架构设计过程中需要时刻铭记在心的一条准则。

首先，遵循这条准则能够让“新手”架构师心中有数，而不是一头雾水。

新手架构师开始做架构设计的时候，心情都很激动，希望大显身手，甚至恨不得一出手就设计出世界上最牛的 XX 架构，从此走上人生巅峰，但真的面对具体的需求时，往往都会陷入一头雾水的状态。

以下的问题，如果明确了“架构设计是为了解决软件复杂度”原则后，就很好回答。

• “这么多需求，从哪里开始下手进行架构设计呢？”
  —— 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
  
  
• “架构设计要考虑高性能、高可用、高扩展……这么多高 XX，全部设计完成估计要 1 个月，但老大只给了 1 周时间”。
  —— 架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
  
  
• “业界 A 公司的架构是 X，B 公司的方案是 Y，两个差别比较大，该参考哪一个呢？”
  —— 理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。

其次，遵循这条准则能够让“老鸟”架构师有的放矢，而不是贪大求全。

技术人员往往都希望自己能够做出最牛的东西，架构师也不例外，尤其是一些“老鸟”架构师，为了证明自己的技术牛，可能会陷入贪大求全的焦油坑而无法自拔。

以下这些想法，如果拿“架构设计是为了解决软件复杂度”这个原则来衡量，就很容易判断。

• “我们的系统一定要做到每秒 TPS 10 万”
  —— 如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用。
  
  
• “淘宝的架构是这么做的，我们也要这么做”
  —— 淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不就是我们的业务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。
  
  
• “Docker 现在很流行，我们的架构应该将 Docker 应用进来”
  —— Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂度根本不是在这方面，引入 Docker 没有什么意义。

总结

架构设计的主要目的是为了解决软件系统复杂度带来的问题。
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
架构设计的主要目的是为了解决软件系统复杂度带来的问题。

架构是为了应对软件系统复杂度而提出的一个解决方案。架构即（重要）决策，是在一个有约束的盒子里去求解或接近最合适的解。这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体(人、财、物、时间、事情等)。架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。

需求驱动架构。在分析设计阶段，需要考虑一定的人力与时间去“跳出代码，总揽全局”，为业务和 IT 技术之间搭建一座“桥梁”。

架构设计处于软件研制的前期。一方面，越是前期，如有问题，就能够越早发现，修改的代价也就越低；另外一方面，也意味着，软件实施后期若有架构上的修改，也需要付出更多的代价。

几点收获：

1. 架构是为了应对软件系统复杂度而提出的一个解决方案。
2. 架构即（重要）决策。
3. 需求驱动架构，架起分析与设计实现的桥梁。
4. 架构与开发成本的关系。

【附】简单的复杂度分析案例

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

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

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

3. 高可用：学生管理系统即使宕机 2 小时，对学生管理工作影响并不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案了。但是，如果学生的数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，这个很难接受，因此需要考虑存储高可靠，这里就有点复杂了。我们需要考虑多种异常情况：机器故障、机房故障，针对机器故障，我们需要设计 MySQL 同机房主备方案；针对机房故障，我们需要设计 MySQL 跨机房同步方案。

4. 安全性：学生管理系统存储的信息有一定的隐私性，例如学生的家庭情况，但并不是和金融相关的，也不包含强隐私（例如玉照、情感）的信息，因此安全性方面只要做 3 个事情就基本满足要求了：Nginx 提供 ACL 控制、用户账号密码管理、数据库访问权限控制。

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

学生管理系统架构图

通过上面的分析，可以看到这个方案的主要复杂性体现在存储可靠性上，需要保证异常的时候，不要丢失所有数据即可（丢失几个或者几十个学生的信息问题不大）。