[0001] 本申请涉及软件开发技术领域，尤其涉及一种软件架构设计平台及软件架构设计方法。

[0002] 随着企业数字化转型的发展，企业建设的应用系统越来越多，用于支撑不同的业务，而多数企业在前期追求业务快速发展的过程中，并未对业务应用进行系统性的软件架构设计，或者根据当时的业务需求和技术场景，从某一方面设计了业务应用的软件架构，但由于设计的软件架构不合理，随着业务的发展、需求的变化、功能的升级、技术的更新迭代和团队的变化，业务应用后期的开发逐渐趋于混乱，存在功能重复、数据孤岛和流程不畅等各种弊端。

[0003] 而在进行软件架构设计时，业务人员认为架构就是规划业务系统现有的和未来的功能模块，以及与其他业务系统之间的接口关系；开发人员认为软件架构应该是代码的组织形式、采用的技术框架和中间件等；部署运维人员认为软件架构应该是服务器的组网关系和网络接口等。不同角色的视角不同，设计出来的软件架构也不同，并且难以达成对软件架构的统一认知，从而无法全面指导多样化的业务系统的软件架构设计，容易影响软件架构的合理性。

[0018] 为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

[0019] 图1是本申请实施例提供的软件架构设计平台的结构示意图，本申请实施例提供的软件架构设计平台特别适用于面向云原生环境的企业级应用软件的架构设计。如图1所示，本申请实施例提供的软件架构设计平台包括：业务架构设计模块10，用于将业务需求转化为业务应用的功能模块，并对功能模块进行拆分，以定义业务应用的业务架构；
数据架构设计模块20，用于设计业务应用的业务逻辑中的数据结构和数据存储架构，以定义业务应用的数据架构；
开发架构设计模块30，用于定义业务应用的代码的层次架构，得到业务应用的开发架构；
运行架构设计模块40，用于设计业务应用的运行时控制流，以定义业务应用的运行架构；部署架构设计模块50，用于定义业务应用的物理部署和网络拓扑，得到业务应用的部署架构；安全架构设计模块60，用于设计业务应用的安全机制和访问控制，以定义业务应用的安全架构；
应用架构设计模块70，用于从全局角度所述业务应用，以定义业务应用的应用架构。

[0020] 可选的，业务架构设计模块10用于将业务需求转化为业务应用的功能模块，并进行拆分，从而涉及出业务应用的业务架构。而业务架构用于构建整体业务能力，其作用是连接业务与IT技术之间的纽带，形成业务和IT技术之间有效沟通的通用语言，用于实现业务需求到IT技术的传递。业务架构的设计过程是梳理用户的业务需求、设计需求方案、选取技术以解决业务需求对应的问题，确定业务应用最终需要为用户提供的功能。业务架构的输入是用户需求，最终输出的是业务应用要提供的功能。面向云原生环境的业务架构设计，需要从业务功能层面进行功能拆分，根据上下文环境，将业务需求对应的功能拆分成独立的业务功能模块，为后期的微服务开发提供基础。

[0021] 可选的，数据架构设计模块20用于涉及业务应用的业务逻辑中的数据结构和数据存储架构，从而定义业务应用的数据架构。数据是所有业务处理的核心，而数据架构就是以数据为核心梳理整个业务流程，现有的数据架构的设计是以数据库为核心的设计过程，在业务需求确定下来后，首先需要设计的是数据库。传统的数据库以关系型数据库为主，而随着云计算技术的发展，当业务应用越来越复杂时，传统数据库无法满足业务需求，数据库的设计也不再仅仅局限于关系型数据库，而是包括关系型数据库、非关系型数据库和大数据平台等。数据架构的设计内容分包括数据库选型、数据库表结构涉及、数据采集存储设计以及数据的容灾备份设计等。

[0022] 可选的，开发架构设计模块30用于定义业务应用的程序代码的层次架构，从而定义业务应用的开发架构。其中开发架构又称工程架构，是从开发人员的视角进行的软件架构设计，开发架构设计阶段以业务需求为依据，通过整理归纳出各个功能模块的技术共性，总结共性需求、共性设计、共性的技术架构，最后从全局角度去设计业务应用的架构。在开发架构设计阶段，需要设计的内容包括技术选型、系统分层、代码规范和接口定义。

[0023] 可选的，运行架构设计模块40用于涉及业务应用的运行时控制流，以定义业务应用的运行架构。运行架构又称进程架构或过程架构，运行架构关注进程、线程和中断服务程序等运行时控制流，以及相关的并发、同步、通信和吞吐量等问题。运行架构的设计对业务应用的运行期质量属性有较大影响，运行期质量包括性能、可伸缩性、持续可用性和安全性等。尤其对于云原生运行架构，其包括微服务和容器化等核心架构设计。云原生的运行架构需要充分利用云计算的弹性、敏捷、资源池和服务化等特性，解决业务应用在开发和运行的整个生命周期中的问题。运行架构是将功能以及非功能需求对应到技术组件上，确定技术组件如何配合完成业务应用的运行。云原生的运行架构的设计内容主要包括技术选型、分布式设计、运行流程设计、吞吐量定义、响应时间定义、容错机制设计、可靠性定义、微服务定义和容器化处理等。

[0024] 可选的，部署架构设计模块50用于定义业务应用的物理部署和网络拓扑，从而设计业务应用的部署架构。部署架构也称物理架构或网络架构，部署架构重点关注业务应用的底层硬件分布、网络拓扑和软件部署，以及如何通过服务器和网络来配合业务应用的可靠性和可伸缩性等要求。随着云原生技术的发展，大型业务应用一般需要部署上百台服务器，所有对业务应用的性能、安全和可靠性的设计调优，最终都将落实到服务器节点、资源设备及网络拓扑等物理设备上。部署架构的设计内容主要是确定所需的物理设备的数量、网络带宽以及各组件如何部署等，部署架构是对运行架构的落地与实施。

[0025] 可选的，安全架构设计模块60用于涉及业务应用的安全机制和访问控制，以定义业务应用的安全架构。安全架构是业务应用的安全保障。随着云原生技术的发展，安全架构不断演进，面向云原生环境的安全目标是防护云原生环境中基础设施、编排系统和微服务等的安全。通过安全架构防范对网络、运行环境以及业务应用的攻击、入侵、干扰、破坏和非法使用意外事件，使网络、运行环境和业务应用处于稳定可靠运行的状态。

[0026] 可选的，应用架构设计模块70用于从全局角度描述业务应用，从而定义业务应用的应用架构。应用架构也称逻辑架构，应用架构定义所需的业务应用、以及业务应用之间的分工与合作，该业务应用具体是指各业务系统，以及业务系统中的各个逻辑模块或者子系统。业务应用作为独立可部署的单元，明确划分出了业务系统的边界，为业务应用的功能组织、代码开发、部署和运维等工作奠定基础。

[0027] 本申请实施例提供的软件架构设计平台，针对不同的设计角色提供了一个标准化的设计平台，通过提供业务架构设计模块10、数据架构设计模块20、开发架构设计模块30、运行架构设计模块40、部署架构设计模块50、安全架构设计模块60以及应用架构设计模块70等多个设计模块，分别为软件架构设计的不同角色提供了设计基础，有利于统一从不同角色的视角对软件架构作出的设计，从而确保软件架构的合理性和准确性。

[0028] 在本实施例中，通过为软件架构不同的设计角色提供设计模块，为不同的设计角色提供了一个标准化的软件架构设计平台，可以统一从不同角色的视角对软件架构作出的设计，从而确保软件架构的合理性和准确性。

[0029] 可选的，参照图2，业务架构设计模块10用于对业务目标、业务功能、业务流程和微服务中的至少一项进行拆分，以及，还用于定义运维工作台，如图2所示，该运维工作台包括资源管理单元、电路调度单元、维护与支撑单元和业务配置单元。

[0030] 进一步地，运维工作台是串联的多层级工作台，其中的上级运维工作台与下级运维工作台之间用于端到端的业务开通和端到端的路由还原。对于每一层级的运维工作台而言，其用于与业务平台连接，该业务平台包括数据共享平台、故障管理平台、运维管理平台、业务编排系统、网管系统、资源管理中心和安全管控平台中的至少一个。

[0031] 具体地，运维工作台与数据共享平台连接，用于对数据共享平台的传输性能进行实时监测和实时告警；运维工作台与故障管理平台连接，故障管理平台用于对运维工作台的性能异常进行管理，该性能异常包括运维工作台自身的性能异常，以及运维工作台监测到的性能异常，也即，故障管理平台对运维工作台的性能异常进行管理，以及，运维工作台将监测到的性能异常发送到故障管理平台进行管理；运维工作台与运维管理平台连接，运维管理平台用于对运维工作台进行资源入网业务开通和设备割接管理；运维工作台与业务编排系统连接，用于对业务编排系统进行业务调单；运维工作台与资源管理中心连接，资源管理中心用于对运维工作台进行资源同步和资源勘误，如图2所示，对运维工作台的资源同步包括自动采集内线资源同步和内外线串联后资源同步；运维管理平台与网管系统连接，网管系统用于向运维工作台发送资源数据，并接收运维工作台下发的网络配置数据；运维工作台与安全管控平台连接，安全管控平台用于对运维工作台进行安全管控和登录认证。

[0032] 可选的，数据架构设计模块20用于涉及业务应用的数据架构，设计内容主要包括数据库选型、数据库表结构设计、数据采集存储设计和数据的容灾备份设计，以及，用于定义数据存储架构。该数据存储架构包括数据集市层IM、汇总数据层DWS、明细数据层DWD、公共维度层DIM、原始数据层ODS和数据可视化层。

[0033] 其中，数据集市层，用于对集群存储的业务应用的业务数据和用户行为数据进行汇集；汇总数据层，用于存储业务数据和用户行为数据的汇总数据；明细数据层，用于存储业务数据和用户行为数据的明细数据；公共维度层，用于存储业务数据和用户行为数据的数据维度；原始数据层，用于存储业务数据和用户行为数据的原始数据；数据可视化层，用于根据公共维度层中的数据维度对业务数据进行多维分析和即时查询，并对分析结果进行可视化显示。

[0034] 参照图3，业务数据是业务交互过程中产生的，可以通过应用服务器采集，而用户行为数据可以通过在用户端埋点的方式，从日志服务器采集得到，用户行为数据是由用户对业务应用的操作行为产生的用于描述用户操作行为的数据，以日志文件的形式采集。如图3所示，对业务数据的集群存储，是对业务数据的全量同步和增量同步，对业务数据和用户行为数据的集群存储，通过消息缓存和日志消费实现。对业务数据的可视化，是基于对数据集市层、汇总数据层、明细数据层、公共维度层和原始数据层的全量同步实现的。基于数据集市层、汇总数据层、明细数据层、公共维度层和原始数据层，还可以对业务数据和用户行为数据进行即时查询和多维分析。

[0035] 可选的，开发架构设计模块30用于设计业务应用的开发架构，主要设计内容包括技术选型、系统分层、接口定义和代码规范，以及定义工程结构，如图4所示，该工程结构包括终端显示层、开放应用程序编程接口(API)层、第一请求处理层、业务逻辑层、第二请求处理层、第三方服务层和外部数据接口层。其中，数据持久层与数据存储系统连接，用于对数据持久层持久化的数据进行存储。

[0036] 可选的，运行架构设计模块40用于设计业务应用的运行架构，主要设计内容包括技术选型、分布式设计、运行流程设计、定义吞吐量、定义响应时间、设计容错机制、定义可靠性和服务集群中的微服务，从而定义业务应用的运行架构。如图5所示，业务应用以微服务集群的方式运行，其运行架构主要包括代码提交层、自动化构建层、容器化层、数据存储层、服务监控层、用户交互层、微服务层和服务注册中心，其中：代码提交层用于提交微服务的程序代码；自动化构建层用于提供自动化发布管道，将代码提交层提交的程序代码自动化编译和构建为可发布构件，并部署到容器化层中的生产环境容器中；容器化层用于对自动化构建层部署的可发布构件进行容器化处理，从而对微服务进行容器化；数据存储层用于存储微服务层的集群数据；数据存储层包括关系型数据库、非关系型数据库和对象存储数据库中的至少一种；用户交互层用于向微服务层发送服务请求，以及向服务注册/配置中心发送服务注册请求；服务注册/配置中心用于响应用户交互层的服务注册请求，对服务注册请求中的微服务进行注册与配置下发。服务监控层用于监控微服务层、容器化层和数据存储层的性能和服务质量。其中，自动化构建层提供自动化发布管道，可以实现对微服务的持续集成和持续发布，并自动化快速部署到生产环境容器中，实现开发和运维的一体化协同。而微服务层用于响应服务请求，从而调用服务请求对应的微服务向用户交互层对应的用户端提供服务。

[0037] 可选的，部署架构设计模块50用于设计业务应用的部署架构，设计内容主要包括设计网络拓扑、服务器组网、网络策略、网络带宽、定义服务器的配置和对网络区域进行划分；网络拓扑的节点包括终端、代理集群、应用服务集群和数据存储集群。

[0038] 可选的，安全架构设计模块60用于设计业务应用的安全架构，主要设计内容包括网络安全、数据安全、空间安全、容器安全、编排系统安全和应用安全。以分布式日志采集为例，安全架构涉及认证授权、日志审计、漏洞扫描和应用服务器分布式集群的防火墙。

[0039] 可选的，应用架构设计模块70用于设计业务应用的应用架构，主要设计内容包括业务应用的逻辑分层、模块定义和接口协议。应用架构包括采集层、数据层、服务层、应用层和接入层。

[0040] 其中，采集机层用于采集数据源系统中的业务数据；数据层用于对采集层采集的业务数据进行存储；应用层包括多个业务应用，接入层用于用户终端接入各业务应用，并向业务应用发送服务请求；服务层用于根据数据层存储的业务数据，向应用层的各业务应用提供服务，以响应用户终端的服务请求。

[0041] 参照图5，采集层与数据源系统连接，用于采集数据源系统的数据，并对采集的数据进行预处理，该预处理包括数据校验、数据过滤、数据抓取、数据脱敏和数据清洗等。数据层用于对采集层采集的数据进行存储和大数据处理，数据层设有文件服务器、关系型数据库和分布式数据库等，用于数据存储。服务层包括服务1‑服务5等多个微服务，应用层包括应用1‑应用5等多个业务应用，接入层用于用户终端接入到应用层的业务应用，并发起服务请求，服务层用于根据数据层存储的数据向应用层提供服务，响应用户终端的服务请求。其中，接入层的用户终端包括但不限于PC端、APP端、PAD端、小程序端和自助终端。

[0042] 在本实施例中，面向云原生的业务应用，提供了包括业务架构设计模块、数据架构设计模块、开发架构设计模块、运行架构设计模块、部署架构设计模块、安全架构设计模块以及应用架构设计模块等多个设计模块，供不同的软件架构设计角色分别设计业务应用的业务架构、数据架构、开发架构、运行架构、部署架构、安全架构和应用架构，统一了不同角色对软件架构的设计认知，从而提供了一种软件架构的标准化设计平台，解决了软件架构设计的复杂性。

[0043] 参照图6，本申请实施例还提供一种软件架构设计方法，该软件架构设计方法基于上述各实施例所描述的软件架构设计平台实现，图6是本申请实施例提供的软件架构设计方法的设计流程示意图，如图6所示，本申请实施例提供的软件架构设计方法，包括：步骤100，对业务应用的业务目标、业务功能和业务流程进行拆分，设计业务应用的业务架构；
步骤200，基于所述业务架构进行数据库选型、数据库表结构射界、数据存储设计和数据容灾备份设计，得到所述业务应用的数据架构；
步骤300，基于所述数据架构进行技术选型、系统分层、接口定义和代码规范，设计所述业务应用的开发架构；
步骤400，基于所述开发架构进行技术选型、分布式设计、运行流程设计，并定义吞吐量、响应时间、容错机制、可靠性、微服务和容器化处理，得到所述业务应用的运行架构；
步骤500，基于所述运行架构设计网络拓扑和服务器组网，并定义网络策略、网络带宽和服务器配置，以及划分网络区域，得到所述业务应用的部署架构；
步骤600，基于所述部署架构定义网络安全、数据安全、空间安全、容器安全、编排系统安全和应用安全，设计所述业务应用的安全架构；
步骤700，基于所述安全架构进行逻辑分层、模块定义以及定义接口协议，设计所述业务应用的应用架构。

[0044] 业务应用的软件架构包括业务架构、数据架构、开发架构、运行架构、部署架构、安全架构和应用架构。在设计业务应用的软件架构时，首先，以业务需求分析开始，对业务需求对应的业务目标、业务功能和业务流程进行拆分，设计出业务应用的业务架构。然后，以数据为核心，梳理业务流程，进行数据库选型、数据库表结构设计、数据采集存储设计、数据的容灾备份设计，得到业务应用的数据架构。

[0045] 进一步地，基于数据架构，以业务需求为依据，整理归纳出业务应用各个功能模块的技术共性，总结共性需求、共性的设计、共性的技术架构，以此进行技术选型、系统分层、代码规范、接口定义开发架构设计，从全局角度去设计软件的开发架构。

[0046] 根据设计出的开发架构，以关注进程、线程服务程序等运行时以业务需求为依据，整理归纳出各个功能模块的技术共性，总结共性需求、共性的设计、共性的技术架构，最后从全局角度去设计软件的开发架构；进行技术选型、系统分层、代码规范、接口定义开发架构设计，控制流，以及相关的并发、同步、通信、吞吐量等问题，进行技术选型、分布式设计、运行流程设计、吞吐量、响应时间、容错机制、可靠性、微服务、容器化、Devops等运行架构设计。

[0047] 基于设计出的运行架构，以关注硬件分布、网络拓扑和软件部署，以及如何通过服务器和网络来配合实现业务应用的可靠性和可伸缩性等要求，进行网络拓扑、服务器组网、网络策略、网络带宽、服务器的配置以及网络区域划分的设计，得到业务应用的部署架构。

[0048] 根据部署架构，以业务应用的安全保障为基础，进行网络安全、数据安全、空间安全、容器安全、编排系统安全和应用安全等的安全设计，得到业务应用的安全架构。最后，基于设计的安全架构，以定义有哪些业务应用、以及业务应用之间如何分工和合作为目的，进行逻辑分层、模块定义和接口协议定义，得到业务应用的应用架构，从而完成对业务应用的软件架构的设计。

[0049] 在本实施例中，基于软件架构设计平台，提供了一种标准化的软件架构设计流程，可以满足不同设计角色对软件架构的设计需求，实现了面向云原生的业务应用的软件架构设计的标准化。

[0050] 通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

[0051] 最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。