大架构观(11.28)

最近这几个月招人，发现一个很普遍的现象，就是你要是招聘开发人员或高级开发人员，收到的简历很少而且很难有合适的，但是你要是招架构师往往就能收到一堆的简历，即使薪酬待遇一样的情况下也是如此。对于软件开发这个行业，相信能够做架构师是很多人的职业规划和努力的目标，这不仅仅是待遇方面的能力，也和个人的职业成就有很大的关系。但是真正从业务，技术和管理各方面能力都能够胜任的架构师却少之又少。

对于架构和架构设计，在我博客上面也写过很多的文章，其中经常强调的一个重点就是架构本质上是解决从业务现实到技术实现之间的抽象问题，这个抽象的变现是各种形式化的模型。在很多时候，技术实现或最终的产品还没有做出来，但是你的模型已经拿出来了，你能够拍着胸脯说按照这个模型去实现肯定没有问题。要做到这点，那么需要的绝对不是简单的自信，而是真正的前期大量项目实践，设计和编码能力的积累，包括抽象等各种架构思维能力的锻炼，最终才能够水到渠成。

要成为架构师，大量的项目和设计编码积累是必须的，而且这种编码积累还不能是简单重复，还是必须得有抽象，复用等各种思维，不断重构的设计意识。走的路多了，各种业务到实现的匹配方式验证的多了，各种大型项目经历和解决复杂问题多了，你自然就有了这种能力。

一个架构，很多时候并不是说创新或学习能力就有多强，而是他们的实践经验积累的知识库很强大，见多才能够识广，大量的模式匹配库随时可以使用，而对于一般人你经常发出的感慨就是我怎么没有想到那里去？知识经验库很值钱，但是这个是长期大量的实践换来的，投入的是大量的时间和金钱成本。

经验库的积累一定是知识理论到实践，再到总结复盘，再到抽象形成在自己脑海里面的。这个过程本身就是循序渐进，反复迭代，并没有什么捷径可走。

而今天谈大架构观，那么首先还是说的架构思维，对于架构思维在前面有篇文章专门强调过，里面谈到的分解，集成，抽象，复用，组合，系统化等多方面的思维能力，这些思维能力都相当重要，但是本质都是我们看待和理解事物的方式。

大架构观本质就是我们如何看待和理解一个产品，那么最终这个产品的实现就是按照你理解或建模的方式进行开发和产出。所有产品后期可能出现的问题都可能是我们理解出现了问题。

架构首先要解决的是产品内部组件如何高效协同，产品和外围系统间如何高效协同并满足业务和用户需求的问题。这就是最基本的功能性需求，架构必须要搭建这种业务场景和需求和最终产品实现之间的桥梁。这么多年下来，我们还是发现，很多人对架构的理解有很大的偏差。

即我会用多层框架了就是J2EE架构师，会用SpringCloud了就是微服务架构师，会Hadoop了就是大数据架构师，这是对架构一个巨大的误解。能够基于开源项目或框架来搭建一个基础开发平台确实是一个架构师应该具备的基本能力，但是这个能力仅仅是架构能力很小的一部分，因为技术框架不是业务需求，而实现在技术框架上的业务功能组件才能够满足业务需求。在业务需求没有最终实现前，技术框架本身并没有得到充分的验证，也没有和最终的业务需求匹配，这种空框架搭建并没有很高的技术含量。

或者说大部分人将架构理解为技术架构，而忽视了业务抽象和建模能力，但是脱离业务的技术架构，连自己都无法验证最终架构原型对现实业务的支撑能力，即架构师最终设计的东西无法自己进行实证，这本身就是一个要命的事情。架构师变成了纸上谈兵，设计的模型变成了空中楼阁，这显然不是我们想要的。

一个好的架构师，一个是给出的当前业务场景和需求下，最合理的架构模型设计，而不是什么理想化的模型，什么网上顺手搬来的现成架构模型。架构师追求的不是理想化，而是当下最合理。

我们如何分析和理解产品，这里的大架构观的一个重点就是能够深入细节又能够跳出盒子的双重思维，既能够宏观全局又能够微观局部，既能够分解又能够集成回去。既追根究底又不求甚解，置身产品之中又能够跳出产品做用户视角的思考。要具备这种架构能力，需要的是业务建模，业务到技术分解转化能力，随时都是业务和需求导向，技术为需求服务。没有盲目的技术堆积，只有合理的技术采用。没有理想化的模型，只有验证过的技术。

一个好的架构一定是同时解决功能性架构和非功能性架构两方面的问题。

而非功能性架构包括了可靠性，性能，高可用性，高扩展性等多方面的内容。这些都需要架构师在搭建模型的时候进行考虑，好的架构就是稳如泰山，灵活扩展，具备弹性的以不变应万变的能力。好的架构就是充分考虑到各种异常边界，并发峰值，安全攻击等场景下，系统仍然能够平稳可靠运行。

不论出现任何的突发情况，产品都能够灵活应对，这往往就是靠的架构师设计产品时候的架构能力。就如建造一座高楼，外部上看上去都一模一样，但是有的高楼刮大风都能够吹倒，但是有些高楼却能够扛住10级地震，这要的就是内功积累，否则就是绣花枕头。

越是复杂的业务，往往构建的业务系统和架构设计也就越复杂，但是对于架构师而言一定要意识到，任何架构的复杂性都应该作为黑盒，屏蔽在架构设计内部。即架构的复杂性应该在架构设计的时候被隐藏掉，通过粗粒度的接口将这种复杂性屏蔽在内部。即对于最终的开发人员往往并不需要关心这些复杂性，而只是按照架构原则和开发指南进行开发即可。这本身也是架构设计的一个重要考虑点。

大架构观，本质就是我们分析和理解事物的思维观，而架构本身解决的是从业务需求到技术实现间的关键衔接，而这个衔接的呈现是模型，解决的关键问题是抽象。大架构观，既需要我们通过分解和集成来理解事物的组成和内部运作协同机制，更加重要的是需要我们跳出盒子来看待整个事物或产品的运行。