软件架构设计分层模型和构图思考 _软件架构

文章插图

今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑。
架构思维概述对于架构思维本身仍然是类似系统思维，结构化思维，编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁，因此架构思维最核心的就是要理解到业务驱动技术，技术为最终的业务服务。要真正通过架构设计来完成业务和技术，需求和实现，软件和硬件，静态和动态，成本和收益等多方面的平衡。

文章插图

在前面多篇文章已经提出，架构设计中有两个重点，一个是分解，一个是集成。
分解是最基础的，架构的重点就是要对复杂问题进行分而治之，同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。
集成是配合分解完成的动作，最终分解完成的各个组件或子系统，通过合适的接口设计，最终还能够集成为一个完整的整体，分解仅仅是加速开发和降低问题复杂度，如果分解后的内容无法集成在一起，那么分解就没有任何意义。
分解+集成可以理解为架构最核心的思考方式和方法。
在分解完成后，一个大的系统已经拆分为了诸多的小模块，或者一个小模块实现本身又分为了多个步骤阶段。那么零散的节点必须向上汇集和归纳，形成一个完整的架构。
而这个架构的形成要给关键就是要又分层思维。架构分层是谈架构绝对绕不开的一个点，通过架构分层可以更好地全面理解业务系统或功能实现。
云平台三层架构：资源-平台-应用在规划大架构的时候，常会参考云计算的标准三层架构，即IaaS层，PaaS层，SaaS层。对于IaaS层重点是IT基础设施和虚拟化；PaaS层重点是构建平台层服务能力；而对于SaaS层则是具体的应用。
对于资源层从物理资源，再到虚拟化逻辑资源，从虚拟机到现在更加轻量的容器资源。而对于平台层原来只谈技术平台，但是当前又进一步拆分出业务平台，也可以理解成当前说得比较多的中台层。
同时在平台层和应用层之间增加了服务层，实现资源和服务的解耦。

文章插图

如果涉及到物联网类应用，一般还会在底层增加网络层和感知层，比如一个智慧城市标准平台和应用的架构图类似如下：

文章插图

在平台+应用构建模式下，一般在平台和应用之间还会有一个单独的服务层来实现接口服务对外的能力开放。资源+服务+应用也是我们常说的SOA分层架构模式，因此对于服务层也可以单独拆分出来作为一个小分层。

文章插图

问题1：数据库和数据层
在构建一个完整的总体架构的时候，实际上没有数据层这个概念，数据层是在表达单个应用系统的分层架构实现的时候才会出现的内容。
在总架构图里面把类似结构化数据库，非结构化数据等全部列出单独一层这个也不对，这个应该是在技术架构里面体现。
还有一种是单独分出一个数据层，将大的公共基础数据列出，比如上面谈的智慧城市架构图。如果这些基础数据存在共性能力朝上提供，那么可以归纳到PaaS平台层，在PaaS平台层单独分出一个数据平台域来进行体现。
问题2：服务层和服务
在构建整体架构的时候可以单独出一个能力开放平台或服务层，但是不用体现具体有哪些业务服务能力。因为单独出业务服务能力本质已经属于应用层内容，即应用又细化拆分为了业务中台和前台应用，中间衔接的服务。
我们可以参考网上的另外一个构图，如下：

文章插图

这个构图既不像云平台中的分层架构，也不像应用功能实现中的分层架构。实际可以看到如果体现单独的支撑层，支撑层已经类似现在经常说到的业务中台和能力提供。
那么整个架构应该为技术平台+中台+应用方式来进行构图。
SOA分层：组件-服务-流程对于SOA架构分层，重点要体现的就是服务，对于组件本身是属于逻辑资源层的概念，而对于服务则是资源对外暴露的能力抽象。