![](https://i-blog.csdnimg.cn/blog_migrate/41c4434adbd813d32950143ee03b3cea.png)
这节我们来说说在构建软件架构的过程中,我们需要的几种思维方式。我们生活和学习中常常有思维方式的转换,构建软件架构时也同样需要不同的思维方式。
对于构建一个软件架构来说,从思维方式上入手有很多值得我们学习的地方,这涉及到如何抽象构建架构的思维方式。这篇我们就来讲讲,软件系统架构思维方式有哪些。
架构既承载了我们对这个项目的抽象思维构建,也同时帮助了我们理清业务体系的方向。如果要说软件研发、系统架构中最重要的能力是什么,我会毫不犹豫回答是抽象能力。
在系统架构和设计中,抽象能力是个比较重要的能力,其实抽象能力在生活也很重要,只是在软件设计架构中尤其的重要。一个项目在最初的设计时是没有可见目标的,也就是说我们需要凭空创造出一个我们能看到或想象的到的构建目标,这个目标大概率指向软件形成的最终形态不会偏离很多。抽象能力在这个特殊时期发挥了重要作用,它可以帮助我们在没有形成任何可见可幻想的实际目标之前,描绘出一个大致的轮廓,以至于我们在实现架构途中能有个可见的标准和目标。因此实际工作中抽象能力的强弱,直接决定我们所能解决问题的复杂度和规模大小。
软件系统架构设计和小朋友搭积木无本质差异,只是解决的问题域和规模不同罢了。架构师先要在大脑中形成抽象概念,然后是子模块分解,以及子模块之间的沟通方式,然后是依次实现子模块,最后将子模块拼装组合起来,形成最后系统。我们常说编程和架构设计就是搭积木,优秀的架构师受职业习惯影响,眼睛里看到的世界都是模块化拼装组合式的。
抽象能力不仅对软件系统架构设计重要,对建筑、商业、管理等人类其它领域活动也同样非常重要。可以这样认为,我们生存的世界都是在抽象的基础上构建起来的,离开抽象人类将对事物的构建寸步难行。
我在一篇名为《优秀架构师必须掌握的架构思维》的文章中看到关于抽象能力分析很好的分析,以下部分内容引申了他的文章。
第一种,分层思维
分层是我们应对和管理复杂性的基本思维武器.
面对一个复杂的系统,我们一开始总是无从下手,就好比一下子在我们面前摆了有很多很多的问题,杂乱无章。这很大程度都会导致我们慌张,焦急,惶恐等心理波动。分层思维,就能很好的帮助我们抽象一个复杂的系统的架构层次,从而清晰的描述了我们有多少层面的事务需要我们解决,以及解决层级的先后次序。
构建一套复杂系统,我们把整个系统划分成若干个层次,每一层专注解决某个领域的问题,并向上提供服务。这样的抽象做法,让复杂的事务变得更加清晰有序。有些层次并不一定是横向的,也可以是纵向的,纵向的层次贯穿其他横向层次,称为共享层。如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/41fcd4565ceb3a487df01353a4e7babf.png)
下面我们来介绍几个用分层思维作为抽象方法的架构案例:
一个中小型的Spring Web应用程序,我们一般会设计成三层架构:
![](https://i-blog.csdnimg.cn/blog_migrate/6e5c6c846b4991c0133dcef87ac7775f.png)
Linux操作系统是经典的分层架构,如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/595ac3e75424fa7ef84e0ca55c72d3ee.png)
TCP/IP协议栈也是经典的分层架构,如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/c2dce94fcbbbcbf49d5b25f900d03e08.gif)
如果你关注人类文明演化史,你会发现今天的人类世界也是以分层方式一层层搭建和演化出来的。今天的互联网系统可以认为是现代文明的一个层次,其上是基于互联网的现代商业,其下是现代电子工业基础设施,诸如此类。
第二种,分治思维
分而治之也是应对和管理复杂性的一般性方法,下图展示一个分治的思维流程:
![](https://i-blog.csdnimg.cn/blog_migrate/650ca2b52022f4658e7fbffc30437b9d.png)
这是我2015年在思考Unity3D手游项目开发整体流程时,用分治法抽象出来的对整个问题的分解。我首先把code编码作为主中心,再把除了code的以外的事拆分成打包发布,资源部署到外网与检测,版本控制,项目管理平台。再对拆分出来的大块问题,进行细化,分解到具体的某个小问题。
![](https://i-blog.csdnimg.cn/blog_migrate/25fcea124ad3238178dff22f26ddc3dc.jpeg)
对于一个无法一次解决的大问题,我们会先把大问题分解成若干个子问题,如果子问题还无法直接解决,则继续分解成子子问题,直到可以直接解决的程度,这个是分解(divide)的过程;然后将子子问题的解组合拼装成子问题的解,再将子问题的解组合拼装成原问题的解,这个是组合(combine)的过程。
在生活中分治思维,解决大问题,复杂问题,是很好手段。特别是当遇到那些你从未处理过的问题时,或者特别复杂超出你能力范围的问题时,把它分解、拆分、解刨、撕裂。把大问题先分成几大块的问题,再从这几大块问题入手,对每个大块问题再分解,拆分成小块问题。倘若小块问题仍然无法进行,或者还是没有思路,再拆分,再解刨,再分解,直到分解到你能开始着手解决了为止。这样一步步,一点点,把小的问题解决了,就是把大块问题解决了。随着时间的推移,不断解决细分的小问题,大块问题被迎刃而解,最后大块问题解决完后,更大块问题迎刃而解。
第三种,演化思维
经常有人在讨论:架构是设计出来的?还是演化出来的?我个人基于多年的经验认为,架构既是设计出来的,同时也是演化出来的,对于互联网系统,基本上可以说是三分设计,七分演化,而且是在设计中演化,在演化中设计,一个不断迭代的过程。
在互联网软件系统的整个生命周期过程中,前期的设计和开发大致只占三分,在后面的七分时间里,架构师需要根据用户的反馈对架构进行不断的调整。我认为架构师除了要利用自身的架构设计能力,同时也要学会借助用户反馈和进化的力量,推动架构的持续演进,这个就是演化式架构思维。
当然一开始的架构设计非常重要,架构定系统基本就成型了,不容马虎。同时,优秀的架构师深知,能够不断应对环境变化的系统,才是有生命力的系统,架构的好坏,很大部分取决于它应对变化的灵活性。所以具有演化式思维的架构师,能够在一开始设计时就考虑到后续架构的演化特性,并且将灵活应对变化的能力作为架构设计的主要考量。
从单块架构开始,随着架构师对业务域理解的不断深入,也随着业务和团队规模的不断扩大,渐进式地把单块架构拆分成微服务架构的思路,这就是演化式架构的思维。如果你观察现实世界中一些互联网公司(例如eBay,阿里,Netflix等等)的系统架构,大部分走得都是演化式架构的路线。
下图是建筑的演化史,在每个阶段,你可以看到设计的影子,但如果时间线拉得足够长,演化的特性就出来了。
![](https://i-blog.csdnimg.cn/blog_migrate/8bc471fac5f7fa26530687a70bc46069.png)
总结下,我们上文中我们强调了抽象思维在架构设计中的重要性,以及抽象思维的几种用法,包括分层思维,分治思维,以及演化思维,他们帮助我们在抽象的架构设计中起到了很好的作用。