大架构观的养成(22.3.1）

今天接着前面谈到的架构思维谈一下大架构观的养成。要成为一名合格的架构师，大量的编码和设计这个积累是必须的。而且这种编码积累还不能是简单的重复，必须要有抽象和复用的各种思维，不断重构的设计意识。自己走的路多了，各种业务到实现的匹配方式验证得多了，各种大型项目得经历，解决得复杂问题多了，我们就自然具备了这些能力。

一个架构师并不是说具备多强的创新和学习能力，而是通过实践经验积累，让知识库足够强大，见多才能够识广。大量的模式匹配库，自己形成的经验库。能够随时可以使用。而对于一般人经常发出的感慨就是。我怎么没有想到那里去，我怎么没有想到这个方法。这里面主要的原因就是自己的知识经验库积累太弱了。知识经验库的积累很值钱。但是这个本身是经过大量长期实践换来的，投入的是大量的实践和金钱的成本。经验库的积累一定是要经过知识理论到实践，再通过总结复盘和抽象，形成属于自己脑海里面固化的东西。这是一个循序渐进、反复迭代的过程，并没有什么捷径可以走。所以今天谈大架构观，首先说的还是架构思维。对于架构思维就是前面说的分解，集成，抽象，复用，匹配、结构化、系统化等多方面的思维能力。这些思维能力都相当重要，本质就是我们看待和理解事物的不同方式。大架构观的本质就是我们如何看待和理解一个产品。那么这个产品最终的实现就是i按照我们理解和建模的方式进行开发和产出。所有的产品后期可能出现的问题可能都是前期我们对与产品的理解出现了问题。所以架构首先要解决的是产品内部组件如何高效协同，产品和外围系统间如何高效协同并满足业务和用户需求的问题，这就是我们常说的基本的功能性需求。架构工作的关键在于搭建这种业务场景需求和最终产品实现实现之间的桥梁。过去我们对架构的理解有很多的偏差，很多人认为架构就是我们学会了使用多层框架就是J2EE架构师，会用SpringCloud就是微服务架构师，会用Hadoop就是大数据的架构师，这是对架构的巨大误解。能够基于开源项目或者框架搭建一个基础的开发平台确实是一个架构师应该具备的一个基本能力，但这仅仅是架构设计里面很小的部分。因为技术框架本身部包含业务需求，而实现再技术框架上业务功能组件才能满足业务需求。再业务功能没有实现前，技术框架业务得到充分验证，也没有和业务需求完成匹配过程。这种空的框架的搭建并没有技术含量。很多人将架构理解成技术架构，而忽视业务抽象和建模的能力。但是脱离了业务的技术架构无法验证最终架构对显示业务的支撑能力。即架构师最后设计的东西无法自己进行实证，这就是一个纸上谈兵，空中楼阁设计的过程。好的架构师我的理解应该时给出当前业务场景和需求下最合理的架构模型设计，而非最理想的设计模型或者移植过来的线程模型。架构师最求的不应该时理想化，而是当下的最合理化。对我们如何分析和理解产品，这里面大架构的一个重点就是要既能够深入细节，又能够跳出盒子的双重思维。既能够宏观全局，又能够围观局部；既能够把大的复杂的问题分解，又能够最终集成回去；既能够刨根究底，又能够做到不求甚解；既能够置身产品其中，又能够跳出产品，站在用户的角度进行思考。具备这种架构能力，需要的是业务建模，业务到技术的分解转化能力。随时都是业务和需求导向，技术是为业务和需求服务，没有盲目的技术积累，只有合理的技术采用，没有理想化的模型，只有验证过的技术。所以好的架构一定是同时解决功能性架构和非功能性架构两个问题。非功能性架构就是我们常说的他包括了可靠性、性能、高可用、高扩展多方面的内容，这些都是架构师考虑模型搭建的时候必须要考虑的点。好的架构既可以做到稳如泰山，灵活扩展，具备弹性，以不变应万变的能力。同时，好的架构要考虑到各种异常边界，并发峰值，安全攻击等场景，能够确保系统平稳高效运行。

所以越是复杂的业务，往往构建的业务系统和架构设计越复杂。但是对于架构是而言一定要意识到，任何做架构的复杂性应该作为黑盒，屏蔽在架构设计内部。即架构的复杂性应该在架构设计的时候隐藏调，通过粗粒度的接口将架构复杂度屏蔽在接口内部。所以对于最终的开发人员，往往并不需要知道架构设计内部的复杂性，只需要按照架构原则和开发指南进行开发就可以了。大的架构观，本身就是理解和分解事物的四围观，这就是从架构思维到大的架构观点养成的理解。