09-架构设计流程:识别复杂度
架构设计第一步:识别复杂度
前文讲过,架构设计的本质目的是为了解决软件系统的复杂性,所以我们在设计架构时首先要的就是识别系统的复杂性。只有正确分析出软件系统的复杂性,后续的架构才不会偏离方向。如果一个系统的复杂性是功能耦合严重,逻辑复杂,而架构师设计出一个TPS达到50000/s的系统也没有任务意思,因为没有解决系统的问题。
架构的复杂性主要来源于"高性能","高可用","可扩展"等几个方面,但是架构师u判断架构复杂性时不能生搬硬套,认为任务架构都必需满足这三个方面。实际上大部分系统只要满足其中一个或者二个就可以了。如果真要同时满足这三个方面,要么就是之前的设计有问题,要么就是架构师判断失误。就算真要同时满足这三个方面,也要有优先级顺序。
如果运气不好接手了一个每个复杂度都有问题的系统,也是应该一个一个的去解决问题,而不是幻想一次架构重构解决所有的问题。如果同时要解决这么多问题,可能会面临以下问题。
- 要做的事情大多,反而无从下手
- 设计方案太复杂,落地时间太长
- 同一个方案要解决不同的复杂性,有的设计点是矛盾的。如要提高系统的高可用性,就要及时把数据及时写到硬盘上,而把写硬盘又会影响系统的高性能。
因为,正确的作法是把主要的复杂度问题都列出来,然后根据业务、技术和团队对问题进行优先级排序,优先解决最主要的复杂度问题。
对于按照复杂度优先级解决问题的方式,可能会存在这样一个担忧,解决了优先级靠前的复杂度问题后,解决后续复杂度的方案需要将之前已经落地的方案推倒重来。这个担忧只是存在理论上的可能性,因为由于软件系统的可塑性和易用性,对于同一个复杂度问题,软件系统设计方案可以有很多个,总是可以挑选一个性价比最高的方案。
即使真的要推倒重来,那么新的方案也必须同时解决之前已经解决的复杂度问题,一般来说要达到这种情况,都是依靠引进新的技术。例如,引入Hadoop可以同时解决高性能、高可用、大容量三个大数据处理的复杂度问题。
识别复杂度对架构师来说是一个挑战,因为复杂度并不是写在需求上面,需要架构师自己去判断。有经验的架构师能够一眼就看出来系统的复杂度在哪。但如果经验不足的话,那么就只能通过排除法了,从不同的角度进行逐一的进行分析了。