在数字化转型工作中，所有的数字化应用都会落地为系统工具的形式上。企业可以采购本地化软件或租赁第三方SaaS服务来实现自身的数字化应用需求，同时，也可以基于自建系统的方式来定制化所需要的数字化应用系统。企业在自建数字化系统时，可以采用不同的软件应用架构，不同软件架构各自的技术特点，可适用于特定的技术应用场景。

当前，常见的软件应用架构主要包括：分层架构、事件驱动架构、微核架构、SOA架构、微服务架构、云架构等。下面分别对这些软件应用架构进行介绍，以协助进行数字化转型的项目管理人员更有效地理解技术系统本质，有效组织安排数字化系统应用的具体开发工作任务。

1.分层架构

分层架构是最常见、最传统的软件架构之一，也是比较标准和规范的软件架构。在没有特殊要求的软件系统开发时，可以采用分层架构进行功能模块的设计。分层架构一般可将软件分成若干个水平层，每一层都有清晰的角色和分工，各层级彼此不需要知道其他层的具体细节，层与层之间通过接口的方式进行通信。

一般来说，在分层架构中，将系统分为三层或四层比较常见。在四层的分层架构中，软件系统从上到下可以被划分为表现层、业务层、持久层、数据库层等：

在表现层，系统的功能主要负责与用户进行交互操作，系统中的操作控件、界面菜单、网页、可视化图表等，这些都属于表现层的技术要素；在业务层，系统的功能主要负责实现关键的业务逻辑，旨在满足用户对系统的具体使用需求，例如在电商平台上，商品推荐、商品筛选、订单配置、在线支付、账单查询、物流跟踪，这些核心功能的实现都在业务层完成；在持久层，系统的功能主要完成与数据库的操作逻辑，如基础的SQL操作，为业务层提供数据内容，同时也将需要固化沉淀的信息进行存储；在数据库层，对数据资源进行存储，在数字化项目中，可根据数据的主题、类型、场景、来源等不同维度特征将数据存储在不同数据库中，并分别进行数据库管理系统（DBMS）的技术选型。

分层结构的优点是结构简单，比较容易理解和开发，不同技术栈的开发人员可以同步对不同层的内容进行开发，此外，每一层都可以独立进行测试，在进行软件测试时，其他层的接口通过模拟的方式来配合解决。在数字化建设中，分层架构对数据交互需求丰富的软件系统具有很好的支持性，例如BI分析系统，大数据决策分析工具、仿真设计工具，以及数据管理系统工具等。

2.事件驱动架构

事件（Event），是当系统状态发生变化时，软件发出的通知形式。事件驱动的架构本质上是解决异步处理的需求，其通过事件的方式来实现软件系统中不同组成部分（业务功能模块）之间的消息通信。在事件驱动架构中，一个业务功能模块的执行取决于是否接受到其他模块的特定事件通知。

事件驱动架构主要包括事件队列、分发器、事件通道，以及事件处理器等几个部分内容。其中，事件队列是程序接受事件的入口，分发器负责将不同的事件分发到不同的业务逻辑单元，事件通道是分发器与处理器之间的联系渠道，事件处理器的功能在于实现具体业务逻辑，对应各个业务功能模块，处理完成后会发出事件，接着触发下一步的操作。

事件驱动架构实现了功能模块之间的解耦，不同模块之间通过消息传播的方式进行有效协作，各自的执行彼此不会发生堵塞。系统可以采用分布式的方式进行灵活部署，软件的可扩展性更好，对于具有持续迭代开发需求的数字化项目来说，采用事件驱动的架构能够更有效地应对动态、增量的开发任务。在数字化建设中，很多涉及条件自动触发判别的技术应用需求，可以采用事件驱动架构来建设，例如舆情跟踪系统、质量监测系统、风险监控系统、在线任务分发系统等。

3.微核架构

微核架构又称为“插件架构”，该架构指的是软件的内核相对较小，其主要功能和业务逻辑大都通过插件的方式来实现。微核架构中，每个插件各自负责一项独立的业务功能，而内核通常只包含系统运行所需的最小功能，一般情况下仅作为基础环境存在，不承担具体的业务功能。各个插件是互相独立的，插件之间的通信应该减少到最低，软件系统中需要避免出现插件互相依赖的问题。

微核架构的优点主要在于功能的延展性方面，如果用户需要在系统中添加一个功能，那么只需要在内核上开发并增加安装一个插件即可。各个功能之间是隔离的，如果不需要某个特定的功能，可以直接删除卸载，此时某个功能的卸载并不会影响到其他功能的使用。微核架构满足渐进式的开发方式。值得注意的是，微核架构并不适用于分布式的运行环境，因此在性能上很难横向拓展。不少单机部署的数据分析软件经常会采用微核架构，用户可以通过下载安装特定的数据分析算法包来完成软件功能的扩展升级。

4.SOA架构

SOA（Service-Oriented Architecture）架构全称为面向服务的软件架构，该架构首先在90年代中期得名，由Gartner Group公司认识到了这个软件架构的新趋势并在全球推广。当前，SOA已经成为软件服务行业中最主流的软件架构之一。

在SOA架构中，服务对应于原先软件系统中的功能模块，软件功能模块不是在代码层紧密粘结在一起，而是相互剥离出来。每个服务把其内部复杂的代码逻辑进行封装，并通过接口进行外部暴露，系统中的其他功能模块可以通过调用接口的方式，来获得该接口所提供的业务能力或数据能力。

对于整个软件系统来说，每个功能模块可以作为独立的服务进行维护，服务是软件系统的基础开发和管理单元。工程师可以对服务进行独立的配置、部署、状态监控、升级更新等各种运维操作。在物理层面，通过服务调用的方式可以实现系统功能模块的“分布式”部署的效果，系统的功能模块不在是单独部署在指定的单台服务器上，而是可以增量地在多个机器上迭代式地进行业务功能的扩增以及服务能力的扩容。只需要把需要调用的功能模块配置在特定的服务器上，软件系统就自动增加了这部分的技术能力。

无论是功能的上线和下线，还是功能的升级和优化，基于面向服务的软件架构都极大地简化了软件变更的过程。在面向服务的软件架构中，IT项目可以更好地应对外部环境中频繁变化的数字化需求，在服务层面进行软件升级和调整具有更大的灵便型。

面向服务的软件架构的本质是集成的思想，软件系统不是被编写出来，更多是被集成出来的，被集成的部分是可以复用的功能模块，也可以是某些需要被进行资源整合的子系统。系统的集成时只需要关注服务交换的协议和数据接口定义，而不用关注服务内部的具体技术实现细节，这极大地提高了IT项目开发的并发效率。

5.微服务架构

微服务架构是SOA架构的深化升级版本，每一个服务就是一个独立的部署单元，这些单元都是分布式的，各个单元的功能互相解耦。微服务架构中的服务之间通过远程通信协议进行联系和功能协作，常见的协议类型有SOAP、REST等。

与SOA架构相比，微服务架构在功能模块拆分方面更加彻底，服务的颗粒度更精细，将模块化的思想深入到子系统内部。微服务架构中各个服务之间并非通过ESB总线的方式进行集中式的通信，而是根据具体的业务逻辑进行点对点的分布式交互调用。

在微服务架构的软件系统中，通常会存在一个服务注册中心，每个服务在运行时需要提前在服务注册中心进行注册，让其他服务可以在执行过程中通过服务注册中心快速发现所调用的服务接口是否存在。微服务架构适用于功能集合庞大、结构复杂、具有平台属性特征的大型数字化系统项目，若采用微服务架构，十分有利于实现不同模块之间的解耦和复用，同时可以做到每个组件持续集成式的开发、实时部署、动态升级。

6.云架构

云架构主要解决扩展性和并发的问题，是最容易扩展的软件架构。与传统的服务器相比较，云平台可以将物理资源虚拟化为虚拟机资源池，使得软件系统可以根据具体使用情况灵活调用软硬件资源，实现真正意义上的“按需访问”。云架构的高扩展性来自于不使用中央数据库，数据资源可以在多个处理单元上进行存储和计算。当软件系统的访问量增加时，就动态新建处理单元，反之，如果访问量减少，就关闭一些处理单元。云架构的优点主要体现在高负载、高扩展性方面，支持动态部署的客观需求。

典型的云架构软件中主要包含三个层级，SaaS层、PaaS层、IaaS层：

其中，SaaS的全称为Software as a Service，软件即服务，这层的作用是将软件应用整体以Web的方式提供给用户使用，当前越来越多的企业数字化应用都采用SaaS的产品形态，使用系统功能的B端企业可以按需对SaaS功能进行租赁；

PaaS的全称为Platform as a Service，平台即服务，这层的作用是将一个应用的开发和部署平台作为服务提供给用户，用户不需要管理或控制系统的底层基础架构，只需要控制部署的应用程序或者控制应用程序运行环境的基础配置信息，PaaS层经常采用的典型大数据技术有REST、多租户、并行处理、应用服务器，以及分布式缓存等；

IaaS的全称是Infrastructure as a Service，基础架构即服务，这层的作用是将各种底层的信息处理资源，如虚拟机、服务器、网络、存储设备等作为服务提供给用户。服务部分的层级结构，同时也衍生出了三种不同的云服务模式，企业在开展数字化建设时，可以综合考虑成本因素和灵活度需求，选择IaaS、PaaS或SaaS作为云服务选择。