|
分层相对重要，架构在设计中要考虑分层，而核心仍然是资源+服务+应用的三大层 ，分为这三层仍然是SOA参考架构的核心思想。对于平台+应用更多只是上面分层模式的一个变形。分层的目的是通过分层既理清了整个应用的构建过程，又保证了各层之间的独立设计和松耦合。
模式匹配： 可以讲是所有思维模式里面的一个重点，而架构设计中的模式匹配就是要将最终的业务域问题匹配到对应的技术实现上面。即根据业务需求来挑选最适合的技术，而不是用主流和最先进的技术去反推业务。
抽象是架构思维里面的一个重点 ，这里面包括了两个层面的内容，一个是常说的归纳方法，即各种类似场景的实现见的太多了，自然就归纳了一个规则或方法出来供以后的设计用。但是抽象更加重要，即将非类似场景中的共性内容也总结出来，进一步抽象为类似的东西，以更加方便的适应变更和各种变化。
结构化思维是架构思维必须具备的 ，最常用的两种结构就是二维的表格和树模型，通过结构化思维引入了维度和XY概念后，可以帮助我们更好的分析和比对，结构化决策等。对于多维模型，我们也要有意识的将其转换为多个平面二维模型，方便我们进行分析。
迭代思维是架构思考中需要考虑的另外一个重要内容 ，没有最优的架构，只有不断进化的架构，只有最适合的架构。因此架构本身也在随着业务需求的变化不断的迭代和演化，而不是追求用最新的技术一步到位。
最后即我们常说的系统思维 ，系统思维是架构思维中最重要的思维模式，一个架构师必须要有充分的全局思考的能力，做好前面谈到各种平衡，追求整体的最优化而不是单个目标的最优。
从架构思维到大架构观培养
要成为架构师，大量的项目和设计编码积累是必须的，而且这种编码积累还不能是简单重复，还是必须得有抽象，复用等各种思维，不断重构的设计意识。走的路多了，各种业务到实现的匹配方式验证的多了，各种大型项目经历和解决复杂问题多了，你自然就有了这种能力。
一个架构，很多时候并不是说创新或学习能力就有多强，而是他们的实践经验积累的知识库很强大，见多才能够识广，大量的模式匹配库随时可以使用，而对于一般人你经常发出的感慨就是我怎么没有想到那里去？知识经验库很值钱，但是这个是长期大量的实践换来的，投入的是大量的时间和金钱成本。
经验库的积累一定是知识理论到实践，再到总结复盘，再到抽象形成在自己脑海里面的。这个过程本身就是循序渐进，反复迭代，并没有什么捷径可走。
而今天谈大架构观，那么首先还是说的架构思维，对于架构思维即前面谈到的 分解，集成，抽象，复用，组合，系统化等多方面的思维能力 ，这些思维能力都相当重要，但是本质都是我们看待和理解事物的方式。
大架构观本质就是我们如何看待和理解一个产品，那么最终这个产品的实现就是按照你理解或建模的方式进行开发和产出。所有产品后期可能出现的问题都可能是我们理解出现了问题。
架构首先要解决的是 产品内部组件如何高效协同，产品和外围系统间如何高效协同并满足业务和用户需求的问题 。这就是最基本的功能性需求，架构必须要搭建这种业务场景和需求和最终产品实现之间的桥梁。这么多年下来，我们还是发现，很多人对架构的理解有很大的偏差。
即我会用多层框架了就是J2EE架构师，会用SpringCloud了就是微服务架构师，会Hadoop了就是大数据架构师，这是对架构一个巨大的误解。能够基于开源项目或框架来搭建一个基础开发平台确实是一个架构师应该具备的基本能力，但是这个能力仅仅是架构能力很小的一部分，因为技术框架不是业务需求，而实现在技术框架上的业务功能组件才能够满足业务需求。
在业务需求没有最终实现前，技术框架本身并没有得到充分的验证，也没有和最终的业务需求匹配，这种空框架搭建并没有很高的技术含量。
或者说 大部分人将架构理解为技术架构，而忽视了业务抽象和建模能力 ，但是脱离业务的技术架构，连自己都无法验证最终架构原型对现实业务的支撑能力，即架构师最终设计的东西无法自己进行实证，这本身就是一个要命的事情。架构师变成了纸上谈兵，设计的模型变成了空中楼阁，这显然不是我们想要的。
一个好的架构师，应该是给出在当前业务场景和需求下，最合理的架构模型设计 ，而不是什么理想化的模型，什么网上顺手搬来的现成架构模型。架构师追求的不是理想化，而是当下最合理。
我们如何分析和理解产品，这里的大架构观的一个重点就是能够深入细节又能够跳出盒子的双重思维， 既能够宏观全局又能够微观局部，既能够分解又能够集成回去 。既追根究底又不求甚解，置身产品之中又能够跳出产品做用户视角的思考。要具备这种架构能力，需要的是业务建模，业务到技术分解转化能力，随时都是业务和需求导向，技术为需求服务。没有盲目的技术堆积，只有合理的技术采用。没有理想化的模型，只有验证过的技术。
一个好的架构一定是 同时解决功能性架构和非功能性架构两方面的问题 。
而非功能性架构包括了可靠性，性能，高可用性，高扩展性等多方面的内容。这些都需要架构师在搭建模型的时候进行考虑，好的架构就是稳如泰山，灵活扩展，具备弹性的以不变应万变的能力。好的架构就是充分考虑到各种异常边界，并发峰值，安全攻击等场景下，系统仍然能够平稳可靠运行。
不论出现任何的突发情况，产品都能够灵活应对，这往往就是靠的架构师设计产品时候的架构能力。就如建造一座高楼，外部上看上去都一模一样，但是有的高楼刮大风都能够吹倒，但是有些高楼却能够扛住10级地震，这要的就是内功积累，否则就是绣花枕头。
越是复杂的业务，往往构建的业务系统和架构设计也就越复杂，但是对于架构师而言一定要意识到， 任何架构的复杂性都应该作为黑盒，屏蔽在架构设计内部 。即架构的复杂性应该在架构设计的时候被隐藏掉，通过粗粒度的接口将这种复杂性屏蔽在内部。即对于最终的开发人员往往并不需要关心这些复杂性，而只是按照架构原则和开发指南进行开发即可。这本身也是架构设计的一个重要考虑点。
大架构观，本质就是我们分析和理解事物的思维观 。
而架构本身解决的是从业务需求到技术实现间的关键衔接，而这个衔接的呈现是模型，解决的关键问题是抽象。大架构观，既需要我们通过分解和集成来理解事物的组成和内部运作协同机制，更加重要的是需要我们跳出盒子来看待整个事物或产品的运行。
从开发和技术实践中可以借鉴哪些思维？
在前面我一直在强调思维中最重要的是模式匹配，今天接着这个话题展开谈下从开发和技术实践中类似SOA，面向对象等技术思想中可以借鉴的思维方式。
从紧耦合到松耦合(解耦的最终目的是灵活组装和匹配）
（编辑：盐城站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
