软件架构：为什么要做软件架构设计？
上⼀篇我们聊了软件架构的概念以及历史背景(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台服务器就能够搞定，对于客户来说完全不是问题，可以⽆需太多关注。
当然还有其他⽅⾯的复杂度分析⾓度，就不做细说了。
⼩结
架构设计的主要⽬的是为了解决软件系统复杂度带来的问题。
在做架构设计时⼀定要时刻铭记设计的⽬的，避免陷⼊误区。
思考题
结合上⾯的案例，尝试使⽤“解决软件系统复杂度带来的问题”指导思想来分析您现在正在做的项⽬或产品。
欢迎您把答案写到留⾔区，和我⼀起讨论。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。