上一篇我们聊了软件架构的概念以及历史背景(WHAT)，在这篇我们一起来聊聊为什么要做软件架构设计（WHY）。
架构设计的真正目的
我们在日常生活和工作中都很经常性发生，因为重要而去做的情况，而很少会去寻找“为什么去做”的动因，在架构设计上也是一样，每个技术人员都知道要做架构设计，但为何要做架构设计呢？
先用几个问题来解析一下：
- 不做架构设计系统就跑不起来么？
这让我想起笔者做的第一个项目，设计过程只是几个人一起简单的讨论一下就直接动手撸码，也没有正规的去做设计过程，最终项目也正常上线，效果也还行，而且开发效率还比较快。当然这个也只是表明这个说法并不是一定的，但是笔者认为如果项目前期完成没有一点设计，去及时的识别出风险，可能会导致系统中存在一些未被发现的重要陷阱，后期被发现后，修改成本过大，从而加剧项目风险。
- 做了架构设计会提高开发效率嘛？
其实看上面的案例可以体现到，架构设计并不一定会对开发效率有所提升，毕竟架构设计需要投入时间和人力，对于一些简单的项目，这部分投入如果用来尽早编码，项目也许会更快。当然在项目前期没有投入精力来做好设计，如果频繁出现变更，也会因为架构设计不好，导致越来越糟，可能到处都是重复的代码，项目的进度会越来越慢。
- 设计良好的架构能促进业务发展么？
这点好像挺有道理，不可否认，良好的架构肯定对业务发展有利，但是要明确对“良好”做好定义，比如我们现在想做一个社交软件，面向的人员可能就是某公司内部100号人，但是我们却去照抄微信的架构，这很明显不符合业务需求。
通过这几个问题的分析，好像这些不都是架构设计的真正目的。如果有仔细看上一篇分享的架构设计的历史背景文件，可以体会到，整个软件技术发展的历史，其实就是一部与“复杂度”斗争的历史。架构的出现也不例外，而架构本来就是为了应对软件系统复杂度而提出的一个解决方案，所以架构设计的主要目的是为了解决软件系统复杂度带来的问题。
虽然目的的描述话语很简洁，但却是架构设计过程中需要时刻铭记在心的一条准则。举个我们在项目中遇到的例子：
项目经理小A：小B，这里面是XX项目的需求，你开展下面的架构设计工作吧，一周要完成。
设计师小B：好的。
然后小B打开需求文档，一看WC这么多需求，我该从哪里开始进行架构设计啊？我还要考虑高性能、高可用、高扩展……这么多高 XX，我最少要1个月才完成啊，唉，一周怎么可能完成呀，【脑补】要不然我在业界找个差不多的架构套进来？好像行不通，我还是找C老大问问怎么搞。
设计师小B走到架构师大C旁边，并且阐述了现状，进行请教。
架构师大C闻后：小B啊，做设计先要铭记一条准则，架构设计的目的是“解决软件系统复杂度带来的问题”的，你要先熟悉和理解需求，然后去识别哪些地方会比较复杂(复杂性)，在重点来对这些复杂点进行设计，这也是你设计的入口点，其次对于这些高XX，我们要有针对性的去考虑，架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，比如你看你现在负责的这个项目，用户只有100人不到，而且没有其他高并发需求，所有可以把高性能的权重调低，优先去考虑其他方面。
设计师小B：噢，看来我思考的方向错了，完全没有想到这个准则，就想着一展身手，我开始还想拿业界某公司的架构套用进来，这么一想，好像这项目根本就用不着，套用进来还大大增加了项目的复杂度了，学习了。
所以我们在做设计时，心里面要明确自己的目的，是为了解决复杂度的问题。而复杂度有很多不同的来源，比如人（不同的代码风格，不同的编程习惯），比如业务，比如技术。那么架构不可能面面俱到的解决所有问题，必须要分析出所面对的一个或几个关键的问题，这样架构的设计就能有落脚点，而且问题解决也不会有大的冲突。
任何系统最开始都是非常简单的，类似敏捷开发一样，需求不断迭代，而架构也一样，会随着需求的变化而不断演进，就比如以前我负责的一个产品一样，最开始仅仅只有底层框架，在加上常用的功能集(组织结构、权限体系、系统参数、字典等)，到后来集成更多功能：表单定义、列表定义、流程、任务调度、报表等，系统就慢慢变的开始复杂起来，这也很明却的表明架构设计也是随发展的不同阶段而面临不同的问题。
而我们设计时只要在不同阶段集中解决几个最主要的问题即可，我们在解决问题的时候其实也是一个决策的过程，在一个有约束的盒子里去求解或接近最合适的解，这个有约束的盒子是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体(人，财，物，时间，事情等)，架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。
架构设计的误区
关于架构设计的目的，常见的误区有：
- 因为架构很重要，所以要做架构设计
架构是很重要，但架构为何重要呢？我们做架构设计时一定要知其然，知所以然。
- 不是每个系统都要做架构设计吗?
这也是典型的知其然不知其所以然，系统确实要做架构设计，但还是不知道为何要做架构设计，反正大家都要做架构设计，所以做架构设计肯定没错。这样很容易走入生搬硬套的歧路，但实际上在自己的公司或项目上出现“水土不服”。
- 公司流程要求系统开发过程中必须有架构设计
流程一定要进行架构设计，就会出现事实上不需要架构设计但形式上却继续去做架构设计，不但浪费时间和人力，还会拖慢整体的开发进度。
- 为了高性能、高可用、可扩展，所以要做架构设计
高XX要根据项目的实际(复杂性)需要去设计，并不能一概而论，如果不管什么系统，也不管什么业务，上来就要求“高性能、高可用、高扩展”，结果就会出现架构设计复杂无比，项目落地遥遥无期，团队天天吵翻天……等各种让人抓狂的现象，费尽九牛二虎之力将系统整上线，却发现运行不够稳定，经常出问题，出了问题很难解决，加个功能要改 1 个月……等各种继续让人抓狂的事件。
复杂度分析案例
我们利用“架构设计的真正目的是为了解决软件系统复杂度带来的问题”这个指导思想来做一个实践。
我现在正在做一个客户保护的项目，基本功能有登陆、客户报备管理、品牌、政策、统计等，我们先识别其复杂度到底体现在哪里。
性能： 系统主要面向的用户是业务员和内审员，业务员大概有50人，内审员1人，业务员整体访问率不高，平均每天单个业务员的访问次数不到10次，因此性能这部分并不复杂，存储用 MySQL 完全能够胜任，可以不用缓存。
可扩展性： 客户保护系统的功能虽然比较稳定，但是因为在需求采集侧没有跟客户很好的达到一致，所以要考虑需求变更的风险，可扩展性的复杂度也需要考虑，当然我们不能对所有功能都做可扩展性的复杂分析，我这里主要是对核心逻辑业务：报备做变化的应对，报备分了几个流程，但是其核心的逻辑是相差不大的，所以进行封装设计，另外将核心逻辑分为稳定层和变化层，主要避免大改设计。
高可用： 客户保护系统即使宕机1小时，对客户的管理工作影响并不大，因此可以不做负载均衡，更不用考虑异地多活这类复杂的方案了。但是，如果客户保护数据全部丢失，修复是非常麻烦的，只能靠人工逐条修复，基本难以接受，因此需要考虑存储高可靠。我储存的异常情况主要分为：机器故障、机房故障，因为服务器采用阿里云，所以这块风险相对比较低，故而这里采用异地服务器mysql同步来进行备份。
安全性： 客户保护管理系统存储的信息有一定的隐私性，主要在于客户的信息，但并不是和金融相关的，也不包含强隐私（例如玉照、情感）的信息，因此安全性方面只要做：用户账号密码管理、数据库访问权限控制就基本满足要求。
成本： 由于系统很简单，基本上1台服务器就能够搞定，对于客户来说完全不是问题，可以无需太多关注。
当然还有其他方面的复杂度分析角度，就不做细说了。
小结
- 架构设计的主要目的是为了解决软件系统复杂度带来的问题。
- 在做架构设计时一定要时刻铭记设计的目的，避免陷入误区。
思考题
结合上面的案例，尝试使用“解决软件系统复杂度带来的问题”指导思想来分析您现在正在做的项目或产品。
欢迎您把答案写到留言区，和我一起讨论。
