架构师思维

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

架构的本质

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

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

架构思想

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

系统思考

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

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

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

分层分治

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

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

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

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

简约至上

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

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

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

现实主义

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

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

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

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

总结

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