1.2.2　架构师的思维模式

通过前面的讲解我们可以看到，架构师与需求人员、设计人员、开发人员有相当大的不同。很多人往往因为技术好而被公司任命为架构师，但是如果不能按照架构师的思维模式去思考问题，就无法成为一个合格的架构师。从另一个角度来说，架构师要掌握那么多知识，需要很长的修炼之路，但是只要掌握了架构师的思维模式，有意识地按照架构师的思维模式去思考问题，就会慢慢得到公司的认可，从职务上成为一个真正的架构师。

那么，架构师都应当具备哪些思维模式呢？

（1）宏观思维

前面已经反复论述了宏观思维对于一个架构师的重要作用。宏观思维是对架构师最基本的要求，它是区别架构师与普通开发人员的重要标志。所以，那些要从开发人员成长为架构师的人，除了要努力提高自己的业务与技术能力外，还要努力培养自己的宏观思维能力。遇到问题时，不要直接就落实到设计实现的细节，而应该努力先从宏观、整体上去思考问题，培养自己的大局观。在从整体上进行分析、思考、规划的基础上，一步一步去细化落实，最终解决问题。只有按照这样的套路去思考和分析问题，才能做出高质量的架构设计，才能向着顶级架构师不断前进。

（2）抽象思维

与宏观思维息息相关的另外一个思维能力是抽象思维，这也是架构师必须具备的一项基本能力。我们在对复杂系统进行宏观的、整体的分析时，思考的应当是什么问题呢？实质上就是在复杂系统各个个体的基础上抽象出共性，然后再思考这些共性的问题应当采用什么方法去统一解决，而这就是架构设计真正要做的事情。架构设计就是将各个模块中共性的问题按照统一的方法规范化地解决，从而达到降低系统维护成本、提高系统可维护性的目的。由此可见抽象思维在架构设计中的重要性。

很多人都有一个疑问，架构师还要不要写代码？我的答案是肯定的，但架构师要编写的代码与普通开发人员编写的代码是完全不同的。普通开发人员编写的是那些非常具体的代码，比如这里需要编写一段业务处理程序，那里需要增加一段分布式缓存，等等；而架构师编写的是技术框架与平台功能，他需要分析各个模块业务代码的共性，将这些共性抽象为平台框架，让其他开发人员在这样的框架下按照统一的模式进行编码，如支持ORM的框架、支持领域驱动的框架、支持微服务的框架以及支持大数据的框架等。这种框架的目的是降低维护成本，提高开发速度。

除此之外，架构师还要解决各个模块共性的技术问题，以统一的方案设计实现，比如各个模块都需要解决安全性、可靠性、高并发等问题，架构师抽象出这些问题，制作成技术平台，并为各业务模块提供API接口。各业务模块只需要按照统一的规范调用这些API接口，就可以解决这些技术问题，从而让业务开发的技术门槛降低，开发速度加快，进而实现快速交付。

抽象思维是架构师的基本要求，却是对架构师思维能力的极限考验。很多时候架构师对问题抽象得不够，架构能解决的问题就有限；抽象得太多，又会让架构师迷失方向，想不清楚，最后没有办法完成设计，或者设计质量大打折扣。因此，架构师修炼之路，实际上也是架构师修炼自身心智模式与思维能力的过程。本书后面会有很多案例讲解架构设计的思维过程，帮助大家打开心智。其中有两个非常重要的心智模式，分别是“实例化需求”与“分而治之”。

实例化需求：我们在设计架构的过程中经常会遇到这种情况，就是要做的设计太抽象了，自己绕进去出不来了。遇到这种情况的时候，首先应当思考我们要解决的是什么问题，然后找到它们要应用的场景，这些场景就是这个问题的实例化。先分析在这个场景中应当怎么解决，再分析在下一个场景中应当怎么解决。当你分析了几个场景后，抽象出它们的共性，思路就会越来越清晰。每分析一个场景，就将当前的设计代入进去，像代入数学公式一样，看我们的设计能不能适应这个场景，如果不能，哪里有问题就调整哪里。分析的场景多了之后，设计就开始收敛，设计思路也越来越清晰。

架构师还会经常设计开发平台去支撑其他的业务系统。但是，开发平台应当提供哪些功能，能否为业务系统提供支撑，这些都是架构师最头痛的问题。往往架构师按照自己的想法凭空做出一些功能以后，才发现其和业务系统的需求相差甚远，因而不得不返工。因此，最好的解决思路是在进行平台建设之前，首先思考这个平台要为哪些业务系统服务，然后具体去分析这些业务系统的哪些功能需要平台支撑，怎样支撑。这些功能就是平台需求的实例。平台按照这些功能去设计实现以后，反过来就可以立刻在这些系统中去应用，发挥平台应有的价值。注意，很多架构师不能成为顶级架构师，最重要的原因就是缺乏这种“价值”的意识，不能通过架构设计为企业带来价值。

分而治之：架构设计是一个充满了各种抽象的过程，这对人的思维能力是一种极大的考验。然而，如果要设计的系统过于复杂，规模过于庞大，就有可能超越了人所能承担的抽象能力，对这种状况最直接的反应就是千头万绪，不知从何开始。当我们在架构设计中遇到这种状况时，最有效的心智模式就是“分而治之”。首先将要设计的系统分为不同的角度、不同的模块、不同的问题，然后针对这些不同的角度、模块、问题，逐个击破，问题就迎刃而解了。采用这种模式的关键就在于如何划分出各个部分，并尽量让各个部分互不影响、相互独立。