今天再讲下如何画架构图。

架构图素材和软件架构构图逻辑概述

我在前面有篇文章专门分享了我制作的一些架构图的素材ppt材料，如果没有下载到，可以先关注我私信获取下载地址。

具体素材的内容可以参考：

个人实践中PPT常用构图案例分享

而对于软件架构设计分层逻辑在前面我也专门分享了一篇文章进行说明，这篇文章给出了核心的架构图制作思路，可以参考。

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

要完成一个完整的架构图构图，可以先拆分为两边+中间。两边一般是放具体的标准，规范等，比如安全管理，质量管理，技术标准规范，开发运维规范等。

中间即是重点需要考虑进行分层构建的地方。

在前面也谈到了中间部分重点参考云计算和SOA的架构分层逻辑。一般来说核心的还是资源层，平台层，应用层，门户层。而对于应用层本身又可以考虑业务域进一步拆分，或者根据价值链或业务生命周期拆分为多个阶段域再展开描述。

在云和SOA下，更加强调平台+应用构建的模式。而两者之间一般是服务层，通过SOA平台或API能力开放平台来统一接入和发布服务，以形成一个完整的资源+服务+应用的松耦合架构。

当然对于领域设计架构分层实际也是传统的三层架构模型和SOA架构思想的一种融合，同时独立出单独的服务层和应用层的概念。

再谈分层逻辑

一个完整的架构本身就是多视角的，如下：

功能架构往往可以给具体用户和业务人员看，而对于技术架构往往更多是内部团队开发人员研讨使用。而设计到资源和平台的架构图往往又是运维工程人员进行部署架构搭建的重要参考。因此不同维度的架构分层属性本身不能随意融合使用，而导致架构图混乱。

云计算分层逻辑

云平台的分层逻辑，即标准的IaaS-PaaS-SaaS三层

• IaaS层：资源层，计算，存储，网络
• PaaS层：各种平台可以放到这层，包括技术平台，集成平台，数据平台等
• SaaS层：对应到应用即服务

当然在构图的时候往往会进一步做些扩展。

比如构建物联网应用的架构，一般会在底层扩展网络和感知层。如果要体现平台+应用的服务化开发思路，一般会增加一个独立的服务层或能力开放层。

云计算架构分层模型一般用在最顶层的整体架构规划设计，这类架构图重点体现出云架构分层，体现平台+应用化构建，体现出各个应用域和具体应用。

要明白在这类架构图里面，各个应用一般只会是一个小方框而不会展开。但是从整个大架构规划里面又能够看到基于云平台构建了哪些具体的应用。

类似一个智慧城市的架构图参考如下：

这类架构图在智慧城市，智慧政务，企业整体IT架构规划中都会应用，一般属于顶层架构设计，体现云平台分层，体现技术平台能力和各个IT应用即可。而不做展开。

应用技术架构

注意常说的类似JAVA开发里面的三层架构，数据访问层，业务逻辑层，展现层。或者类似领域模型中的领域服务层，应用层，界面接口层分层方法。

这些本质是偏应用技术架构的描述。

技术架构描述的重点不是讲清楚应用有哪些功能，而是要说清楚应用中的每一个功能是如何通过技术分层来实现的。比如你需要先定义数据库结构，开发数据访问接口，然后编写业务规则逻辑，最好实现前端界面展现设计，再将所有分层内容连接起来。

所以应用技术架构更多是应用实现技术层面的内容，而不是去关心应用实现用的底层IT基础设施资源。在应用技术架构里面一般不会涉及到底层具体的资源或平台，如果应用技术架构在底层增加了类似IT基础设施，存储等内容，就显得不伦不类了。

类似上图，实际就完全没有必要体现出最底层的基础层内容。

应用功能架构

简单来说应用功能架构需要的是体现出应用有哪些业务模块，有哪些具体的业务功能点，而不是关心应用实现的技术架构分层等内容。

但是应用功能架构最好也体现分层。

简单方式就是最下层全部抽象到基础技术支撑层里面，这里面包括了具体的和业务无关的基础技术支撑功能。中间就是应用功能层，最上层是门户层。

在应用功能层的描述中可以分具体的业务域再到业务功能逐层展开，如果业务应用本身有一个完整的生命周期或阶段线条，那么还可以按阶段来排列具体的功能模块。而底层一般放具体的基础数据管理，元数据管理等功能模块。

当然在应用功能架构的构图中，有时候还需要体现出当前应用和外部应用之间的集成，因此可以在纵向再单独增加了一个接口集成的模块。如下：

集成架构的构图

由于我自己经常做SOA规划咨询类项目，因此做整个企业IT应用间集成架构和做接口关系梳理的时候比较多。一个集成架构不仅仅体现出各个IT系统，更加重要的是需要体现出各个IT系统至今的集成关系和关键的集成点，在集成点上又要体现核心基础的数据流。

对于这类图整体可以理解为传统软件工程里面的数据流图的一个演进。

构图的难点是在于整体IT系统的布局，各个系统间接口连接线的设计，如果设计得不好那么集成架构图就会显得很凌乱。

这本身就是一个不断优化调整的过程，没有统一的方法可以遵循。

部署架构-物理架构还是逻辑架构

我们先看一个常见的网络布线和拓扑架构图。

这个图体现了IT基础设施架构的一个关键内容，即应用层，接入层，汇聚层。汇聚后统一进入到核心网。核心网通过DMZ区再连接到互联网。

如果你做一个IT系统的部署架构，一般不会体现最终的应用层内容。

而是体现你核心系统里面的各个IT基础设施情况，如数据库服务器，中间件服务器，缓存服务器等。但是所有的资源配置最终仍然是经过汇聚层交换机后进入到核心网。

类似如下：

因此在部署架构中不会去体现云平台的分层架构，也不会去体现应用分层架构，只需要列清楚具体的物理资源或逻辑资源，以及资源本身接入和汇聚的情况即可。

应用层拆分-前台应用和中台能力层

最近几年谈中台和微服务比较多，注意中台本身是一个业务概念。

实际中台层本身是原来应用层可共享的共性业务能力的下沉，中台层能力在原来是属于应用层能力的。因此在中台架构下，应用层进一步拆分为前台应用和中台能力。

类似一个电商的中台架构如下：

也就是中台架构下的分层应该是：前台应用+中台能力+后台

这个后台有人会理解为技术平台或技术中台，但是更好地理解是后台本身也是原来的应用层内容，也是业务能力的实现。类似在我前面文章中提到过的，企业传统的ERP系统就下沉为后台应用层能力。同时基于后台能力构建了一个抽象服务适配层，这个抽象的共享服务适配层即是中台能力。在这种场景下中台更类似一个服务层。

SOA架构分层，体现独立的服务层

对于SOA架构分层，重点要体现的就是服务，对于组件本身是属于逻辑资源层的概念，而对于服务则是资源对外暴露的能力抽象。

SOA架构分层重点就是要体现出独立的服务层，注意不是画服务总线，这里可以单独画出具体提供哪些业务服务能力，技术服务能力。在采用SOA架构进行开发的时候，整体业务系统拆分为4个组件，10类服务域，5类流程，那么在构建的时候重点就是将上述组件，服务域和流程类体现出来。

这里的数据层最好改为标准的组件层，更加贴近SOA架构模型。在图中的服务层已经可以看到一个个独立的API服务接口。如果服务接口数据大，一般只会划分到服务域，比如用户中心服务，采购类服务等。

多种分层思路的一个糅合

在前面谈到SOA架构分层，云平台分层，应用技术架构分层等多个分层方法，但是各种分层思路一般不混用，各有各的应用场景。

当然有时候也需要多个分层架构的思想融合。

比如需要在一个分层架构中既体现出技术架构分层，又体现出类似SOA和云的平台+应用架构思想，那么就需要多种分层架构融合。

比如前面谈到云平台是一种横向资源-平台-应用的分层方式。而对于技术架构分层仅仅是应用的进一步展开。那么我们在构图的时候就可以横向+纵向结合的方式来进行构图，同时体现出两种分层内容，参考如下：

参考上图，可以将技术架构的分层转变为纵向方式进行描述。而横向重点还是体现云和SOA的架构分层，整体思路就更加清晰。