架构师思维

从业至今有九载,从事架构方向也有三年时间了。前段时间,有一个校招同学问起我:如何做一个架构师。我略加思索,回答到:你得拥有架构师的思维。听上去挺敷衍,但其中蕴含着我对这几年架构工作的思考。且听我慢慢道来。

架构的本质

在讨论架构师是如何思考问题之前,我们先想想这样一个问题:为什么要做架构设计?每个人对这个问题,都可能有自己的想法,我比较喜欢极客时间里李运华老师的阐述: 架构设计本质就是在管理复杂度

要理解复杂度的概念,可以试想这样一个场景。假如我写了一个程序,部署在机器上运行,它只为我服务,它运行的很好,我需要一个架构师负责为我的软件设计架构吗?答案当然是否定的。假如我写了很多程序,部署在很多机器上运行,它们协同一起为很多人提供服务,那我很可能就需要一个架构师为我的软件设计架构。这两者的区别在于,后者的复杂度远高于前者。架构设计让这些程序能够有序的工作,并且保持可以维护和扩展的状态。

架构思想

那些指导我们管理复杂度的思想,就是我所说的架构师思维。我总结了以下几点,抛个砖。

系统思考

系统思考一词来源于《第五项修炼》,即站在系统的层面思考具体的问题。通过系统思考看到的,不是一个点,而是点之上的一个面。任何问题,都不会孤立存在,通常会存在于某一个系统之中。比如最近很火的996加班问题,如果我们只是基于自身价值观评价,而没有看到这个行业,乃至当今社会的价值体系,就很难有更深刻的结论。

想要做到系统思考,应该先建立系统地图。常见的系统地图的形式有思维导图、架构图、流程图等等。下面是我总结的后端软件开发领域的系统地图。

理论上,所有软件开发领域的问题,都应该在系统地图上能找到他的位置。(如果不能,请补充你的系统地图)通过系统地图,我们可以看到问题所在的位置、影响面、同类的相关问题,甚至是成熟的解决方案。系统地图帮助我们免于陷入一叶障目,以偏概全的误区中。不断扩充自己的系统地图,就是在不断扩展自己的知识体系,提高自己的问题解决能力。

分层分治

我们说过架构设计就是管理复杂度,拆分是管理复杂度的最有力手段之一。和切蛋糕的出发点一样,拆分就是把大问题,拆解成多个小问题,在局部控制复杂度。

拆分的手段通常有横向分层和纵向分治。当系统存在单向依赖关系时,分层就是一个很好的拆分方式。我们常见的金字塔模型,就是一种典型的分层思想。

当系统存在互相独立的子系统时,分治就成为了解决系统复杂度的有力手段。我们常见的软件系统架构图,往往存在许多互相独立又共同协作的子系统。

下面是一个推荐系统的架构设计,可以看到复杂系统的架构设计,往往同时应用分层分治的思想。

简约至上

在理解简约这个思想之前,我们需要理解代价。代价是我们达成目标所要支付的实际成本。简约意味着,我们付出最小的代价达成我们的目标。听上去,这似乎是每个人所向往的处事之道,但现实却往往事与愿违。这其中的原因,在于很多人对目标并没有清晰的把握。

现在先停下来,想象我们需要实现一个即时通讯的软件,我们应该如何设计他的功能。除了基础的收发消息,我们是不是很快就想到我们需要朋友圈、红包这样的功能。这些功能实用有价值,似乎没有理由不加入到我们的软件中。如果这样考虑,那支付、AA似乎也没有理由不进入到我们的软件里。我们现在已经走在模仿微信的道路上了。而实际上,我们也许只是需要消息通讯,有多少人第一时间考虑的是我们的目标是什么呢?

目标是评判架构设计的最好标准,而架构的本质决定了简约是最佳实践路径。

现实主义

软件开发中,最常见的误区之一,就是对不确定性过于乐观。我们总有一种幻觉,认为软件开发是确定性的。这种误区很大程度是由于我们所写的程序,总能按照我们预期的返回结果。既然程序是确定性的,那由程序构成的系统理所当然是确定的。

然而,现实却不是这样的。系统会莫名其妙崩溃,硬件会无缘无故故障,在你完全没有预期的情况下,你的网站被人攻击了。当系统运行在不确定性的现实时,你对系统做的任何改变,结果同样也是不确定的。

不确定性让我们失去了创造理想系统的能力,而现实主义指导我们着眼于效能。这里的效能不是狭义的生产效率,而是整个系统的投入产出比。我们不会对任何一个系统报有100%可用的预期,虽然对系统使用者来说,这是效率最高的状态。但系统生产者为了追求100%可用性,在有限的资源下,必然要牺牲创造更优秀的功能的可能性。所以站在整个系统的角度,这样的效能却是十分低下的。

抛弃理想主义思想,拥抱现实,效能优先,才有可能创造更高价值的系统。

总结

架构设计是一门学问,站在系统的角度思考,拆解问题,着眼于设计简约高效的系统。本篇分享主要是引出并阐述架构思想,这些思想背后凝聚了我很多架构实践的经验,我会在未来的分享中继续深入探讨。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章