CopyRight 2009-2020 © All Rights Reserved.版权所有: 中国海关未经授权禁止复制或建立镜像
下一代口岸监管作业系统架构风格探讨
作者:王 翔1
王 翔1
摘 要 本文从口岸信息化建设运维的现状出发,运用架构风格和架构形态等设计手段,对下一代口岸监管作业系统应该采取何种架构风格进行探讨,通过综合使用关注点正切风格和架构形态模板的方法,在技术设计和实现层面开展尝试,为突破科技资源短缺探寻思路。本文对参与口岸科技工作的技术决策者及实施人员具有一定参考意义,对进行技术设计和管控的相关研究具有一定借鉴作用。
关键词 作业系统;架构风格;架构形态
The Discussion of the Architecture Style Design for the Next Generation of Port Supervision Processing System
WANG Xiang1
Abstract Based on the analysis of current situations of IT development and operation, this paper utilizes techniques, including architectural style and application archetype, for the design of the next generation of port supervision processing system. With the comprehensive integration of aspect-oriented architecture style and templates of application archetype, it discusses ideas for breaking through the long-term competitive shortage of IT resources, at the level of IT design and implementation. This paper has certain reference significance for IT decision-makers, and implementers participating in the work of Customs IT, and it can also serve as a reference for relevant research topics in IT design and governance.
Keywords customs; architecture style; application archetype
1 架构风格概要
2018 年,伴随机构改革进程,口岸监管部门的系统建设与合作进入快车道,信息化融合促进了资源整合、业务融合、队伍聚合,各类口岸监管作业系统在近年多项重大改革工作中发挥了有力的支撑作用。
从架构角度分析,在本轮系统升级改造过程中,口岸监管作业系统的技术关注点和架构风格也呈现新的变化[1-3],逐步从耦合度较高的组件式(Component-Based) 架 构 过 渡 到 微 服 务 (MicroService) 架构。“微服务”本身是一种架构风格(Architectural Style),更适应互联网时代业务技术快速变化的行业,其他领域也有众多流行的架构风格, 例如:传统企业应用的分层架构风格、操作系统流行的微内核(Micro Kernel)风格、物联网和工业控制领域的事件流(Event Streaming)风格、机器人和智能机械领域的代理(Agent)风格等。由于应用的复杂性, 架构风格之间并非完全排他,可以在同一个系统中组合使用,例如:一个搭载物联网交互任务的无人机系统, 可能同时兼具代理和事件流两种风格,总体框架是代理风格,但在前端设备部分使用事件流风格。
同时,一个架构风格在不同的应用场景(Context) 下 , 可 以 发 展 为 不 同 的 架 构 形 态 (Application Archetype),以分层风格为例,在企业应用早期主要是两层(客户端 - 服务器);此后随着展示、业务逻辑和数据处理的复杂,逐步演化为三层(客户端 - 中间层 - 服务器);随着各类新技术、新框架的快速引入以及业务逻辑频繁变革,更多的分层被不断引入, 根据计算容量和密度的不同,分层的重心也各有侧重, 架构形态也更加多元。
2 架构风格与建设运维
面对复杂多变的内外部环境,“改革急、实施急、测试急、上线急、完善急”逐步常态化,“急”成为不断挑战口岸监管工作中科技治理能力和资源上限的重要因子,建设形式也从相对中规中矩的项目,变为项目、技术攻关、研发试点等多种方式。但如图 1 所示,在技术资源长期相对不足的前提下,面对串行的系统建设运维流程,“急”的问题不仅难于解决,随着技术工作存量的不断扩大,冲突还可能加剧。
架构是科技工作中具有全局性、总体性的内容, 架构风格又决定架构工作的方向[4]。因此, 如何打破现有资源瓶颈、破茧成蝶,需要变化思路,结合最新形势,选择适合的架构风格,这成为预研下一代口岸监管作业系统的重要内容。
2.1 现实挑战
经过连续几代工程的接续建设,目前口岸信息化已经初步实现 IT4IT(用信息化服务信息化)[5],从需求分析直至运行监控,几乎都有配套信息化手段支持,口岸监管作业系统作为一个工作产品,与“生产”它的一系列系统、工具、平台并存。
从整体建设流程分析,如图 1 所示,口岸监管作业系统的建设运维是具有迭代闭环的“大串行”,从图纸到正式运行的生产系统,需要通过需求分析、设计、编码、集成、测试、上线等步骤不断充实打磨, 架构的实现过程也是串行的。“生产”口岸监管作业系统的每一个系统、工具、平台相互独立,他们自身也在不断升级架构是科技工作中的生产力因素,用以实现各类工具、技术的高效组合,在其他因素相对稳定的情况下,可以通过全要素生产率度量不同架构方案的效果 [6];而流程体现各方协作关系,是生产关系部分。生产力决定生产关系,生产关系反作用于生产力。如何进一步提升科技供给能力, 满足普遍以“急”为特点的科技需求,应先在生产力领域找切入点,从改进架构风格入手,实现系统建设运维流程从串行向并行转变。
基本思路是在架构上将需求分析、设计、编码、测试、运行监控等功能置于应用内部,并尽可能将他们前置到需求分析阶段启动,同时允许各技术部门并行开展工作,这利于在供给侧解决三个问题:
(1)解决“急”的问题。缩减建设上线周期,更快响应需求侧要求,按照木桶效应,科技部门的全要素生产率主要受限于生产效率最低的步骤。科技管理人员可以聚焦短板,精准优化具体步骤,并且适当调配资源,实现投入效益的最大化。
(2)解决协作关系问题。将部门与部门、人与人之间的流程协作,变为人与系统、工具、平台之间的交互, 各技术领域的知识以口岸监管作业系统为标的,实现快速沉淀和聚集。
(3)支持频繁变化问题。调整建设运维模式,默认系统需要频繁变化,将持续变更、持续集成、持续交付常态化。
2.2 架构风格选择
虽然在“改进措施”部分归纳了部分技术需求,但对于关联度、集成度相对很高的口岸监管作业系统,这意味着需要将以往分散在不同部门的系统、工具、平台集于一身,技术复杂性增加。如何选取新的架构风格,满足技术需求的同时降低技术实现难度,就成为关键。
表1 主要架构风格
Table 1 Typical architectural styles
类别 | 架构风格 |
通信型 | 面向服务风格(SOA)、消息总线风格 |
部署型 | 分层风格 |
领域型 | 领域驱动设计风格(DDD)[7] |
结构型 | 组件风格、面向对象风格、关注点正切风格(AOP)[1-3] |
由于“改进措施”部分只是将现有建设运维中的系统功能聚合在同一系统中,并未调整系统与外部的响应(通信),也未变更系统部署层次和结构,所针对的依然是常规的口岸作业,也未涉及新的业务领域。因此,在排除了表 1 中通信型、部署型和领域型的架构风格后,主要从结构型风格中选取,其中:
(1)组件风格(Component-Based):主要面向技术实现重用。该架构风格已经在各类口岸系统中广泛应用, 并且逐步升级为“大平台 微服务”,但组件和服务的大量积累无法实现系统“生产”流程的并行化。
(2)面向对象风格(OO):更贴近自然语言和自然发展方式的架构。与组件风格类似,该风格也已经在口岸作用系统中应用近 20 年,在政务类、数据交换类系统中使用也较为普遍,但与组件风格类似,无法有效解决跨技术领域的问题。
(3)关注点正切风格(AOP):注重将不同领域的技术功能以“编织”(Weaving)的方式纳入同一系统,各自逻辑相互独立,但又能同时作用于同一系统。
通过对比,关注点正切风格更适合建设运维多步骤的并行处理。但相对组件风格和面向对象风格,关注点正切风格的技术实现难度普遍较大,单一技术团队难以同时掌握众多技术领域的实施技能,为降低技术门槛,可以通过集成既有技术资源并将他们服务化(SOA),简化技术复杂度,也就是在下一代口岸监管作业系统的应用框架上,提供关注点正切方式接入机制,通过接口(Interface)、属性(Attribute)、注解(Annotation)等低侵入式的技术手段,将现有技术资源“编织”到下一代口岸监管作业系统中。
2.3 基于大平台的正切架构风格
应用新的架构风格后,通过将复杂度分离,下一代口岸监管作业系统的逻辑框架如图 2 所示:
其中,对于口岸监管作业系统业务功能之外的部分,即建设运维等技术内容,在大平台集成。相对而言,新的“大平台”不仅是一个编码、集成、测试平台,还集成了信息化全生命周期的各类技术资源,是一个服务化的逻辑整体,以关注点正切方式面向设计、编码、集成、测试、上线、运行监控团队提供技术支持;需求分析团队作为建设运维的“首站”,聚焦需求的整合重用,分析手段从基于文档、表格,变为直接基于“当下的”口岸监管作业系统。
新的“大平台”不仅可以积累业务领域的“微服务”,而且可以沉淀各技术领域的“微服务”,然后通过“大平台”的正切方式直接嵌入作业系统,在落地实施层面真正实现了业务技术一体化,而不是以需求文档为边界,业务部门、技术部门分头推进。
根据应用场景,同一架构风格呈现为不同的架构形态,资源布局也会有较大差别。为此,需要进一步选择适合的架构形态,如表 2 所示:
表2 典型的架构形态
Table 2 Typical application archetypes
架构形态 | 要点 |
移动APP类 | 强调前端易用性 |
支持离线操作场景 | |
显示尺寸受限 | |
富客户端应用类 | 充分利用客户端资源 |
支持高频率动态性交互 | |
部署和更新复杂 | |
富互联网端应用类 | 支持流媒体和图像等内容的丰富显示 |
易于部署 | |
跨平台、跨浏览器 | |
需要在浏览器端留存大量信息 | |
需要部署运行时环境(Runtime) | |
服务端应用类 | 与客户端松散耦合交互 |
支持更多类型的前端应用 | |
支持跨平台互操作 | |
对于网络配置要求相对复杂 | |
传统Web类 | 支持大量互联网标准 |
界面跨平台能力强 | |
部署和管理难度低 | |
用户体验相对单一 | |
传统桌面类 | 支持常规的图形界面 |
充分利用操作系统本地计算资源 | |
更新和部署相对复杂 | |
控制台客户端类 | 字符界面 |
批处理和高效连续处置 | |
高技能门槛 |
如表 2 所示,口岸监管作业系统作为一个规模庞大的复杂系统,不同子系统、模块的应用特征不同, 对于资源的需求差别较大,尤其面向未来几年口岸工作需要,应用客户端平台会更加多样,除了表 2 中的架构形态以外,还可能覆盖 5G/6G虚拟现实(或现实增强)终端、智能机械(无人机、机器人等)、可穿戴设备等。选取不同架构形态的关键在于确定资源分配,新“大平台”中需要增加运行态配置功能(Runtime Configuration),这是针对不同架构形态预先准备的技术模板,主要面向资源分配,力图以更加友好、透明的方式,满足各业务、技术功能的资源需求,以一个常规现场查验模块为示例,各自的应用形态如表 3 所示:
表3 查验模块的建设运维环境(示例)
Table 3 Build Operation environment for goods check module (example)
平台 | 所在位置 | 架构形态 |
业务功能部分 | 作业应用前端 | 移动APP类 |
作业应用后端 | 服务端应用类 | |
需求分析工具 | 需求分析前端 | 传统桌面类 |
需求分析后端 | 服务端应用类 | |
编码工具 | 开发环境前端 | 传统桌面类 |
开发环境后端 | 服务端应用类 | |
集成工具 | 集成环境前端 | 传统桌面类 |
控制台客户端类 | ||
集成环境后端 | 服务端应用类 | |
部署上线工具 | 部署环境前端 | 富互联网端应用类 |
控制台客户端类 | ||
部署环境后端 | 控制台客户端类 | |
运行监控工具 | 运行监控环境前端 | 富互联网端应用类 |
移动APP类 | ||
控制台客户端类 | ||
运行监控环境后端 | 控制台客户端类 |
运行态配置功能可以根据口岸工作需要,为各架构形态配置标准的容量模板,主要包括计算资源、网络资源、存储资源),同时结合相应的参数(例如,用户数、处理频率等),确保架构师能够在需求分析阶段,为业务、技术一体化团队提供一个按需使用的架构方案,并且利用关注点正切风格,实现下一代系统建设运维的“动车模式”,即所有领域的人员并行发力,在供给侧提升口岸工作的全要素生产率。
2.4 关注点正切风格的应用
虽然如图 3 所示,将业务功能与建设运维等技术领域要求“编织”到同一个系统中,可以更好解决“急” 的难题,但从系统设计角度分析,如果不采用新的设计模式 [8-9],就如图 3 中的多功能工具一样,破坏了单一职责原则,整个系统实现难、维护难。
在新一代系统具体实现时,每一个关注点被视为一个方面(Aspect),正常执行过程中的每一个处理叫连接点(Joint Point),需要加入关注内容并生效的叫切入点(Cut Point)。继续使用表 2 的示例,如果运维监控团队希望在不修改系统的前提下,为其增加计数器,并最终生成业务监控指标。
监控就是一个方面,连接点可能包括布控命中、实施查验、搬移货物、开验、复验等,而切入点根据监控规则确定(Advice),而且根据上下文记录不同的监控结果。编码实现时,需要充分利用开发语言的动态编译技术,动态装载编码、测试、监控等技术领域所使用的服务或接口,以目前口岸科技的主流开发语言为例,实现关注点正切机制的静态结构如图 4 所示,除了要完成“编织”功能以外,作为平台及功能,还应实现跨编程语言和技术平台的无关性。
而实际的动态逻辑(执行机制)如图 5 所示,需要完成业务处理与技术处理的动态编译,这会引发一定的资源负载。而且,作为对编程语言解释器(而非编译器)的功能扩展,技术实现复杂度较高。
3 结语
面对复杂多变的内外部环境,口岸改革发展的千根“线”、万条“线”,最后都会“穿”到口岸监管作业系统这根“针”上,“急”将成为科技部门要面对的常态。本文结合架构风格和架构形态两个手段,探索从供给侧改变现有口岸科技的建设运维模式,为进一步提高和释放生产力提供可能。
关注点正切风格虽然降低了各领域技术实施的复杂度,但将实现关注点“编织”的技术复杂度提高到全新高度。这需要在下一代口岸监管作业系统的建设中,对人力资源投入中进行配套,一方面是常规的技术人员,主要面向功能级开发,技术门槛整体适度降低;另一方面是“高精尖”的技术人员,主要面向平台级开发,实现新架构风格升级的同时,确保口岸业务稳定运行,支撑各技术领域高效协同。
【该文经 CNKI 学术不端文献检测系统检测,总文字复制比为 3.6%。】
作者简介:王翔,博士、博士后,全国海关信息中心首席技术架构专家、海关国际贸易信息标准化应用创新实验主任, E-mail:newonemail1@163.com
1.全国海关信息中心 北京 100005
1. The National Information Center, General Administration of Customs, Beijing 100005
图1 典型建设运维流程(简化)
Fig. 1 Typical simplified build operation procedure
图2 下一代作业系统建设运维的并行流程
Fig. 2 Parallel build operation procedure for next generation system
图3 多功能工具(示例)
Fig. 3 Multifunctional toolkit (example)
(图片来自https://www.chinapp.com/scpinpai/3392)
图4 关注点正切的静态结构[3]
Fig. 4 Static structure of cross-cutting concern
图5 关注点正切的动态逻辑[3]
Fig. 5 Dynamic logic of cross-cutting concern
参考文献
[1] Elrad T, Filman RE, Bader A. Aspect-oriented programming: Introduction[J]. Communications of the Acm, 2001,44(10): 29-32.
[2] Kiczales G, Lamping J, Menhdhekar, SpringerVerlag. Aspect-Oriented Programming: proceedings of the Workshop on Object-oriented Technology, 1999[C].
[3] Lafferty D , Cahill V . Language-Independent Aspect-Oriented Programming[J]. Acm Sigplan Notices, 2003, 38(11): 1-12.
[4] Fowler M. Patterns of Enterprise Application Architecture[M]. Pearson, 2012.
[5] OpenGroup. The Open Group IT4IT Reference Architecture, Version 2.1 [M/OL]. 2017[https://pubs.opengroup.org/it4it/refarch21/.
[6] Berument H, Dincer NN, Mustafaoglu Z. Total Factor Productivity and Macroeconomic Instability[J]. Journal of International Trade and Economic Development, 2011,20(5): 605-629.
[7] Evans E. Domain-Driven Design: Tackling Complexity in the Heart of Software[M]. Addison-Wesley, 2004.
[8] Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software[M]. Addison-Wesley, 1995.
[9]王翔, 孙逊. 模式:工程化实现及扩展(设计模式Java版)[M]. 电子工业出版社, 2012.
(文章类别:CPST-A)