浅析大型应用上云架构验证原型选择方法及实践*

冯青峰 许颖 杨永艳 王慧

北京中电普华信息技术有限公司 北京 100192

引言

企业云平台作为企业基础设施建设的数字化底座，为应用提供了所需的最基础的架构支撑和源源不断的强大算力，推动企业数字化转型与智能升级。随着企业云平台的深化建设，越来越多的大型业务应用系统开始迁移上云。企业在应用上云时，架构设计是应用软件开发中最为关键的一环，软件架构中包含了关于如何构建软件的一些最重要的设计决策，如基于云平台的组件设计和技术选型、部署架构、集成架构和安全防护方案设计等，决定了最终开发出来的软件系统能否满足我们预期的质量属性，架构设计是否合理将直接影响软件系统最终能否成功。鉴于大型业务应用系统和企业云平台本身的复杂性，应用系统架构设计存在很多悬而未决的重大风险，现代软件开发非常注重尽早降低风险，在以架构为中心展开大规模的系统开发之前，通过开发演进型原型进行架构验证是有效的风险应对措施，即将软件架构设计方案尽快通过原型实现，并通过对该原型的测试和评审，来评估软件架构是否合理以降低项目风险，架构原型作为演进型原型，代码要达到产品级质量，成为下一步开发的基础。

目前，架构验证原型的识别和选择研究成果较少，无法有效指导项目实践，本文正是针对上述问题，在进行了各种探索与实践后，总结提炼了一套架构验证原型的识别和选择方法，供准备进行架构验证的个人或企业参考[1]。

1 架构验证原型选择方法

1.1 方法概览

鉴于架构验证原型的用途，架构验证原型实现的功能有限，需要经过细心挑选，选择最影响用户满意度（功能性需求/非功能性需求满足程度）或有较高技术风险的一些功能进行原型开发，以保证重大的技术风险在架构设计中得到解决和验证，为下一步启动大规模开发打下基础。架构验证原型选择活动主要由需求和架构文档收集、业务场景分析、架构风险识别、制作场景架构风险矩阵、为已识别架构风险点选择验证场景、通过业务场景推演识别架构风险点、完善场景架构风险矩阵和确定验证原型8个任务组成。

架构验证原型选择以业务设计需求分析和架构设计成果为输入，通过业务场景分析识别用户最关心的关键业务场景，通过对业务系统组件和技术选型、部署架构、集成架构和安全防护架构等架构元素的分析识别架构风险。把关键业务场景和架构风险进行匹配，形成包含业务场景信息和架构风险的二维矩阵表。从架构风险角度对已识别的架构风险点遍历关键业务场景，选择适合验证架构风险的业务场景。从业务场景角度，通过场景推演识别和该业务场景相关的技术架构风险。通过多次迭代，完善场景架构风险矩阵表，针对场景架构风险矩阵表中的风险点制定风险应对措施，确定哪些风险点需要开发原型进行验证，最终完成架构验证原型的选择。

1.2 方法详述

（1）需求和架构文档收集。需求和架构文档收集的目的是为业务场景分析和架构风险识别收集相关资料，输入是业务设计、软件需求分析、架构设计相关文档，输出：业务蓝图、业务架构、业务场景（包含业务流程和业务功能等），软件需求说明，系统架构设计内容（包含系统架构、组件和技术选型、部署架构、集成架构、安全架构等），云平台提供的云服务产品规格等，步骤通过手工方式整理，为确定关键业务场景和识别架构风险点，收集并梳理前期设计成果。

（2）业务场景分析。业务场景分析的目的是识别用户最关心的关键业务场景，输入是业务蓝图，业务架构，业务场景（包含业务流程和业务功能等），软件需求说明等，输出关键业务场景清单。步骤依据业务蓝图、业务架构和业务场景等业务设计成果，可采用层次分析法(AHP)等方法，对业务场景优先级进行排序，识别关键业务场景。场景信息包含的关键要素有业务场景、场景简述、关键非功能指标信息。

（3）架构风险识别。架构风险识别目的通过对架构元素的分析，识别架构风险点，输入是系统架构设计内容（包含系统架构、组件和技术选型、部署架构、集成架构、安全架构等），云平台提供的云服务产品规格等。输出架构风险表，步骤首先确定需要评审的关键架构元素，设计每个架构元素的风险类别，然后根据业务系统架构设计内容识别架构风险点。

例如：系统架构中通过云平台引入的新组件对业务需求的满足度可能存在风险；部署架构中部署地点的选择对用户体验的影响可能存在不确定性。

（4）场景架构风险矩阵表制作。场景架构风险矩阵表制作目的是建立关键业务场景和架构风险点关联关系，输入是关键业务场景清单，架构风险表，输出是场景架构风险矩阵表，步骤是编制场景架构风险矩阵表，初步建立关键业务场景和架构风险点关联关系[2]。

（5）为已识别架构风险点选择验证场景。为已识别架构风险点选择验证场景目的是对于已识别的架构风险点，在关键业务场景清单中匹配包含该架构风险点的业务场景。输入：场景架构风险矩阵表，系统架构设计内容（包含系统架构、组件和技术选型、部署架构、集成架构、安全架构等），云平台提供的云服务产品规格等。输出是场景架构风险矩阵表。步骤是在场景架构风险矩阵表中，针对每个架构风险点，遍历每个业务场景，检查该业务场景是否存在该风险，如果存在该风险，该业务场景未来可作为验证该风险的候选场景。

（6）通过业务场景推演识别架构风险点。通过业务场景推演识别架构风险点目的是通过关键业务场景技术实现推演，识别和补充架构设计风险点。场景架构风险矩阵表，软件需求说明，系统架构设计内容（包含系统架构、组件和技术选型、部署架构、集成架构、安全架构等），云平台提供的云服务产品规格等。输出是场景架构风险矩阵表。步骤是针对每个业务场景，分析支撑该业务场景的跨层组件、组件调用关系以及部署架构、集成架构和安全架构对业务场景非功能指标的影响，识别和补充架构风险点。

（7）完善场景架构风险矩阵表。完善场景架构风险矩阵表目的是对场景架构风险矩阵表架构风险点内容进行去重整理。输入是场景架构风险矩阵表。输出是场景架构风险矩阵表。步骤通过前面任务进行的架构风险点的识别和补充，可能造成场景架构风险矩阵表中架构风险点存在于多个场景中，对相同的架构风险点选择一个高优先级业务场景进行去重处理。

（8）确定验证原型。确定验证原型目的是基于场景架构风险矩阵表，对架构风险点进行评估，确定哪些风险点要通过开发原型进行验证。输入是场景架构风险矩阵表。输出是架构验证原型清单。步骤针对场景架构风险矩阵表中的架构风险点制定风险应对措施，确定哪些架构风险点需要开发原型进行验证。基于架构风险点对应的业务场景设计验证原型功能范围，编制架构验证原型清单[3]。

2 应用案例

2.1 项目概况

某电力公司营销服务系统是对外提供客户侧用能业务服务，对内支撑营销专业业务管理的信息化管理系统。新建系统以“活前端、大中台、强后台”为架构模式覆盖原有的24个业务系统并支持新兴业务。系统基于公司云平台构建，广泛应用“云大物移智”技术，推进信息技术融入营销全业务、全流程，全面支撑新型营销业态。

该系统架构设计的复杂性主要体现在业务和云平台两个方面。

业务体量大，逻辑复杂。营销业务能力规划包括14个业务域、57个业务类，全面覆盖客户用能设备管理、产品服务和运营管理等业务能力，体量巨大。支撑业务的应用类型包括事务处理类、决策分析类、采集量测类和移动应用类，业务逻辑复杂。

公司云平台体系复杂。在云平台架构方面，公司云平台采用了两家商业云平台产品进行构建，为多云模式，两家商业云平台产品不兼容，增加了云平台的整体复杂度。在云平台技术体系方面，为了解决单体架构“复杂度问题”使用了微服务架构，为了解决微服务间“通讯异常问题”使用了治理框架+监控，为了解决微服务架构下大量应用“部署问题”使用了容器，为了解决容器的“编排和调度问题”使用了Kubernetes，为了解决微服务框架的“侵入性问题”使用了Service Mesh，对这些云原生的技术体系项目组没有太多经验，带来了很多技术风险。

为有效应对项目风险，为下一步大规模开发打好基础，架构组设计了《典型业务场景技术验证方案》，开展了架构验证工作。

2.2 关键业务场景梳理

基于营销业务能力蓝图设计，采用业务场景分析方法，分析了营销业务的14个业务域、57个业务类，提取关键业务场景[4-7]。

图1 业务蓝图

2.3 架构风险点识别

营销服务系统架构包括IaaS层、PaaS层、业务服务层、聚合开放层及前端5层和应用构建、运维监控、安全防护3个跨层。

IaaS层为业务服务提供计算服务、存储服务和网络服务三大类服务；PaaS层提供各种平台服务，包括数据库服务、中间件服务、人工智能服务、大数据服务和公共服务；业务服务层由基于企业中台构建的各业务域微服务组成，每个微服务单独部署；聚合开放层通过服务连接平台等集成组件实现外部服务的接入和内部服务的开放，支撑系统之间的服务调用；前端直接面向用户提供业务服务，由前端页面、APP界面以及交互逻辑等组成；应用构建提供研发过程的协作支撑，实现研发过程中各个环节的统一管理，保证系统研发迭代的速度和质量；运维监控提供自动化监控和自动化运维服务；安全防护根据等保2.0三级安全技术要求，从云平台安全、通信网络安全、区域边界安全、大数据平台安全、数据安全、应用安全、安全管理等方面提供安全防护。

采用架构风险识别方法，通过对系统架构、部署架构、集成架构、安全架构等架构设计内容的分析，识别了系统存在的风险[9]。

2.4 制作场景架构风险矩阵表

通过对业务场景的梳理、架构风险的识别，制作场景架构风险矩阵表，并对场景和架构的反复打磨，持续迭代，完善场景信息和架构风险点，形成最终的场景架构风险矩阵表。以下以电费测算场景为例，制作的场景架构风险矩阵表如下表1：

表1 远程实时费控场景架构风险矩阵表

2.5 确定验证原型清单

通过关键业务场景和架构风险点的匹配，持续完善场景架构风险矩阵，明确哪些架构风险点需要开发原型进行验证，最终明确架构验证原型清单[10]。

3 结束语

很多项目做架构设计的时候往往不做架构验证，导致架构设计一些内容变成空中楼阁，无法落地，甚至导致后续大规模开发推倒重来。大型业务系统上云，项目风险大，通过开发原型进行架构验证是有效的风险应对措施。本文介绍了一种架构验证原型选择方法，并通过某电力公司营销服务系统案例介绍了该方法的应用，该方法为后续大规模开发工作打下了坚实的基础，避免了颠覆性推倒重建带来的巨大损失。