架构设计流程

Posted 2021-01-24 youcong

今天我主要说说架构设计流程，围绕着这么几个方面来讲?

(1)识别复杂度;

(2)设计备选方案;

(3)评估和选择备选方案;

(4)详细方案设计;

一、识别复杂度

在如下两篇文章中，我阐述了六个复杂度来源。

文章分别为:架构设计之六个复杂度来源

                   架构设计之六个复杂度来源(续)

 

如果不了解架构设计的六个复杂度来源可以参考我的上述两篇文章看看。

 

从软件层面上来看，前面说过，架构设计的目的就是为了解决软件系统的复杂度。所以我们在设计这个软件的时候，首先需要做的就是分析系统的复杂性。只有正确分析出了系统的复杂性，后续的架构设计方案才不偏离方向，否则，如果对系统的复杂性判断错误，即使后续的架构设计方案再完美再先进，都是南辕北辙，做的越好，错的越多越离谱。

比如，如果一个系统的复杂度本来是业务逻辑太复杂，功能耦合严重，架构师却设计了一个TPS达到50000/秒的高性能架构，即使这个架构最终的性能再优秀也没有任何意义，因为架构没有解决正确的复杂性问题。

针对诸如这样的例子，我们正确的做法是:

将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要复杂度问题。

对于按照复杂度优先级排序解决的方式，存在一个普遍的担忧:如果按照优先级来解决复杂度，可能会出现解决了优先级排在前面的复杂度后，解决后续复杂度的方案需要将已经落地的方案推倒重来。这个担忧理论上是可能的，但现实中机会是不可能出现的，原因在于软件系统的可塑性和易变性。对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。

即使架构师决定要推到重来，这个新的方案也必须能够同时解决已经被解决的复杂度问题，一般来说，能够达到这种理想状态的方案基本都是依靠新技术的引入。例如，Hadoop能够将高可用、高性能、大容量三个大数据处理的复杂问题同时解决。

识别复杂度对架构师来说是一项挑战，因为原始的需要中并没有哪个地方会明确地说明复杂度在哪里，需要架构师在理解需求的基础上进行分析。有经验的架构师可能一看需求就知道复杂度大概在哪里;如果经验不足，那只能采用“排除法”，从不同的角度逐一进行分析。

 

二、设计备选方案

架构师在设计架构时，通常不能仅仅从一个角度上考虑，应该是从多个角度上看。从不同的角度可以衍生不同的备选方案。

目前业界有很多现成的解决方案，比如我们前面提到的OA方面，还有就是规则引擎，规则引擎除了Drools之外，还有OpenRules等。

虽然软件技术经过几十年的发展，新的技术层出不穷，经过时间考验，已经被各种场景验证过的成熟技术其实更多。例如，高可用的主备方案、集群方案、高性能的负载均衡、多路复用，可扩展的分层、插件化等技术，基本上只要我们有了明确的目标，基本上按图索骥就可以找到可选的解决方案。

 

解决方案太多，让人眼花缭乱，因为可选的实在是太多了，组合方案更多，往往一个问题的解决方案有很多个，如何设计最终的方案，并不是一件容易的事情，这个阶段也是很多架构师容易犯错的地方。

常见错误如下所示:

1.设计最优秀的解决方案

2.只做一个方案

3.备选方案过于详细

 

关于“设计最优秀的解决方案”，我在前几篇有关架构方面的文章中说过，任何架构都是由简单到复杂，一步一步扩展，一步一步演化过来的。

包括最普通的方案变为最优秀的方案也是如此，就好比一个屌丝逆袭，屌丝逆袭成为高富帅，也是需要一个过程的。

 

关于“只做一个方案”，就好比今天貌似阳光明媚是一个很适合出门的日子，借此机会出去玩耍，比如去欢乐谷玩，但是很多项目要排队，排队是不可避免的，总不可能打道回府不玩了吧。

这就需要你心中有好几个方案，比如路线方案、舍得方案。

路线方案是比如玩完激流勇进后可以顺便玩下一些不是很刺激的小项目来段放松的插曲。

舍得方案是欢乐谷那么多项目，休息日人肯定是非常多的，总不可能全部玩完吧(有的项目是有时间限制，比如极速飞车早上10点30到晚上6点之间这段时间才能玩，超过六点后就不能玩了)。

从出去玩这个大家都喜欢的生活方式考虑，只做一个方案是不行的，更何况软件这种复杂多变的玩意呢。

 

关于“备选方案过于详细”，如果一个两个甚至三个还好，请问如果十几个的话，架构师岂不是会累死，十几个方案面面俱到，最后的结果可能是浪费了大量时间反而费力费时不讨好。

一般备选方案遵循简化话就好，当然了，也不能太简单，还是得有点篇幅，不过这个篇幅不是写作文那样动不动至少800字。

 

三、评估和选择备选方案

在完成备选方案设计后，如何挑选出最终的方案也是一个很大的挑战，主要原因为如下三个方面:

(1)每个方案都是可行的，如果方案不可行就不应该作为备选方案;

(2)没有哪个方案是完美的；

(3)评价标准主观性比较强;

 

正是因为选择备选方案存在这些困难，所以实践中很多设计师或者架构师就采取了下面几种指导思想：

(1)最简派(柿子还是挑软的捏);

(2)最牛派(一般倾向于使用非常牛逼的技术);

(3)最熟派(挑选自己以往设计方案最有经验的);

(4)领导派(自己把握不准，列出好几个方案，最后让领导去决策，好的话，说明领导有远见，自己设计也不错，把握的很好，不好的话，这个背锅任务就交给领导吧，反正当初是你挑的，不管我的事情，这种领导派显得比较圆滑);

 

前面列出了几种指导思想，真正应该选择哪种方法来评估和选择备选方案呢?李运华先生对此的观点是:360度环评。

具体的操作方式是:列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。

常见的方案质量属性点分别是:

(1)性能;

(2)可用性;

(3)硬件成本;

(4)项目投入;

(5)复杂度;

(6)安全性;

(7)可扩展性;

 

举例说明:

以智能酒店项目来说，首先对于上述七点都要求比较高，硬件成本，也很大，比如客控系统(客控系统主要是对酒店房间里面的电脑、电视、空调、洗衣机、灯光亮度等由客户自己在触摸屏上调制或者关注小程序来调控)，客控系统硬件成本投入是比较大的，对于性能方面要求也很高，假设你这个系统性能不是特别好的话，通常对于用户量少，造不成很大的影响，如果用户量十分大，造成的将会是毁灭性打击。智能酒店项目囊括比较广，上述七点都要求很高。我仅仅只是挑出两点来讲。剩下的读者可以自行结合自己的项目来比对。当然了，也可以去百度上找一些项目来研究研究，研究它的架构为什么要这样。以上面指导思想来看，并结合质量属性点，你一定会发现不一样的东西。

 

四、详细方案设计

以瀑布模式为例，从侧面反映出详细方案设计的重要作用。

瀑布模式是这样的:可行性方案分析->需求分析->概要设计->详细设计->编码->单元测试->测试->集成->运行维护。

其中详细方案设计的目的在于精确化准确化，在瀑布模式中你可以理解为只要详细设计做的好，程序员可以不过多的思考，就可以直接开始编码了。

从架构上看，架构的详细方案设计做不做的好，不仅仅对当下，还有对将来，如果你的架构详细设计方案让人家看的云里雾里，那么最后可能就像我前面说到过会造成毁灭性的打击，这个打击效果不是特别大的情况你可能需要重构一部分，如果很大的话，可能推到重来。这个推到重来，我在最初的pms的系统中就已经感触很深了。借此机会，希望给大家一个警惕。

 

小结:

本文围绕着识别复杂度、设计备选方案、评估和选择备选方案、详细方案设计等四个方面来讲述架构设计流程，希望能给大家有一定的启发并在实际开发或者设计中有一定的借鉴意义。

感谢李运华先生的专栏《从0开始学架构》，从中我还是学了不少东西。有一句我要阐述一下，旧书不厌百回读，熟读深思子自知。记得当初在校学编程的时候，我哥哥推荐了一本书叫《计算机文化》，书中涵盖很多计算机理论基础方面的知识，当时我没有看也看不怎么懂，后来有一天，我突然将其全部翻了一遍，感觉其实并不是那么难懂难看，还是很有意思的，很多基础方面的知识，你每抽点时间回头看看，一定会有不一样的启发。比如你干了五六年的Java回头再看看《Java编程思想》，你会觉得书虽然厚点但是其实很薄。这是当初参加美团的技术沙龙，一位IT朋友对我说的。当然了，以我现在的情况下，读读《Java编程思想》还是有些吃力的。

 

此文部分内容参考李运华先生的《从0开始学架构》