CN113535227A - 一种数字化技术架构的部署方法和装置 - Google Patents

Abstract

本申请提供了一种数字化技术架构的部署方法和装置，包括获取配置项以及框架和至少一个业务功能系统的源码；框架至少兼容单体架构、集群架构、分布式架构和微服务架构；配置项包括部署目标架构的配置指令，配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；依据配置指令和框架对源码打包，生成支持目标架构的安装包。通过在兼容至少四种不同架构的框架上编写业务功能系统的源码，便于打包成不同技术架构环境下运行的安装包，当整个技术架构升级时，只需把原有业务功能系统的源码重新打包成符合新技术架构要求的安装包，无需对框架和业务功能系统的源码进行修改，就能快速地对系统在新技术架构上的升级，减少成本投入。

Description

一种数字化技术架构的部署方法和装置

技术领域

本申请涉及应用架构技术领域，特别是一种数字化技术架构的部署方法和装置。

背景技术

近年来互联网技术的迅速发展，各种公司纷纷将目光投向数字化领域，随着越来越多的业务互联网化，各类企业的数据化系统需求越来越高，而数字化系统的底层根基是整个数字化的技术架构，因此如何构建适合自身企业要求的数字化底层架构就成为企业实施数字化重点关注与探讨的话题。

目前国内的大部分的企业困于人才与资金不足，不具备线上的技术开发能力，一般都是通过购买或者外包的方式来构建服务架构，即单体架构、集群架构、分布式架构和微服务架构中的一种服务架构。

而上述方式构建出的服务架构通常是业务功能系统的源码绑定在架构，造成整体的底层上并具有未来支持扩展的能力，架构类型难以调整，若强行调整就必须将所有的代码得跟着大改一轮；若提前布局，在线上业务还没跑起来的时候就按照最大体量的方式搭建系统，不仅浪费巨大的人力物力，而且当验证发现业务需要调整时，由于原有架构已经按照最大体量搭建，导致调整也需要巨大投入，无法高效敏捷。

发明内容

鉴于所述问题，提出了本申请以便提供克服所述问题或者至少部分地解决所述问题的一种数字化技术架构的部署方法，所述方法应用在至少兼容单体架构、集群架构、分布式架构和微服务架构的环境生成相应的安装包；所述方法包括：

获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；

依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

可选地，所述依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包的步骤，包括：

当所述配置指令为构建单体架构的指令时，将所述框架和所述源码打包成单体架构的安装包；或，

当所述配置指令为构建集群架构的指令时，将所述框架和所述源码打包成集群架构的安装包；所述集群架构的安装包包括第一配置文件，所述第一配置文件用于支持所述集群架构的安装包在集群中间件服务器的架构部署；或，

当所述配置指令为构建分布式架构的指令时，将所述框架和所述源码打包成分布式架构的安装包；所述分布式架构的安装包包括第二配置文件，所述第二配置文件用于支持所述分布式架构的安装包的分布式分发；或，

当所述配置指令为构建微服务架构的指令时，将所述框架和所述源码打包成至少一个微服务架构的安装包；所述微服务架构的安装包包括一个业务功能系统的源码。

可选地，所述配置项还包括调用指令；所述当所述配置指令为构建微服务架构的指令时，将所述源码打包成至少一个微服务架构的安装包的步骤，包括：

获取所述调用指令；

依据所述调用指令开启支持feign的方式调用RPC微服务。

可选地，所述配置项还包括调用指令；所述当所述配置指令为构建微服务架构的指令时，将所述源码打包成至少一个微服务架构的安装包的步骤之后，包括：

依据所述微服务架构的安装包生成服务系统；其中，一所述微服务架构的安装包生成一所述服务系统；

对每一所述服务系统构建数据库连接池。

可选地，所述第一配置文件为xml配置文件。

可选地，所述第二配置文件为将编写接口设置为无状态的配置文件。

一种数字化技术架构的部署装置，应用于单体架构，集群架构，分布式架构和微服务架构的部署；所述装置包括：

获取模块，用于获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；

处理模块，用于依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

可选地，所述处理模块，包括：

第一处理模块，用于当所述配置指令为构建单体架构的指令时，将所述框架和所述源码打包成单体架构的安装包；

第二处理模块，用于当所述配置指令为构建集群架构的指令时，将所述框架和所述源码打包成集群架构的安装包；所述集群架构的安装包包括第一配置文件，所述第一配置文件用于支持所述集群架构的安装包在集群中间件服务器的架构部署；

第三处理模块，用于当所述配置指令为构建分布式架构的指令时，将所述框架和所述源码打包成分布式架构的安装包；所述分布式架构的安装包包括第二配置文件，所述第二配置文件用于支持所述分布式架构的安装包的分布式分发；

第四处理模块，用于当所述配置指令为构建微服务架构的指令时，将所述框架和所述源码打包成至少一个微服务架构的安装包；所述微服务架构的安装包包括一个业务功能系统的源码。

一种设备，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的数字化技术架构的部署方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如上所述的数字化技术架构的部署方法的步骤。

本申请具有以下优点：

在本申请的实施例中，通过获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。通过在同时兼容至少四种不同架构的框架上编写业务功能系统的源码，以便于打包成不同技术架构环境下运行的安装包，当整个技术架构升级时，只需要把原有业务功能系统的源码重新打包成符合新技术架构要求的安装包，无需对所述框架和所述业务功能系统的源码进行修改，就能快速地实现系统在新技术架构上的升级，减少成本的投入。

附图说明

为了更清楚地说明本申请的技术方案，下面将对本申请的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以依据这些附图获得其他的附图。

图1是本申请一实施例提供的一种数字化技术架构的部署方法的步骤流程图；

图2是本申请一实施例提供的一种数字化技术架构的部署装置的结构框图；

图3是本申请一实施例提供的一种数字化技术架构的部署装置中各服务架构的业务功能系统的示意图；

图4是本申请一实施例提供的一种数字化技术架构的部署装置中WebSphere软件部署集群服务架构的页面图；

图5是本申请一实施例提供的一种数字化技术架构的部署装置中分布式架构的示意图；

图6是本申请一实施例提供的一种数字化技术架构的部署装置的架构设计图；

图7是本申请一实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请的所述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，目前数字化应用的底层技术架构主要分成以下几类，以及各自不同的优缺点：

（1）单体架构；这种架构一般是将所有的功能服务集成在一起，这种架构是传统软件时代的产物，但它的优点是快速且部署成本较低，一般部署一两个服务应用就可以跑起整体系统的所有功能；但是缺点也非常明显，随着业务增长，整体系统架构可承载的并发量非常有限，压力稍微一大就会导致整个系统无法工作，无法实现多节点互备。

（2）集群架构；这种架构是在原有单体架构上延伸出来，将原有单体架构进行多个服务节点组建成集群应用，然后在统一的集群应用上可以实现服务的多节点分发，在支持原有单体架构无法支撑的更大的访问请求量。它的优点是可以在原有单体结构上通过较快的改造快速切换到集群模式，而且通过中间件服务器来保证服务的稳定性，单一应用节点出现问题不影响系统正常使用；但是缺点是无法实施服务的动态扩展，必须一开始就确定好集群服务节点的数量，当请求量超过集群服务节点的要求时，这时节点扩展的成本就变得非常高，甚至无法扩展，另外相对于单体架构，服务部署的成本较高。

（3）分布式架构；这种架构是为了解决传统集群架构无法按需扩展而演变出来的，也是目前互联网主流的架构，这种架构是通过反向代理的方式来实现服务的负载均衡；分布式架构的主要优点是支持应用服务的动态扩展，可以随着用户访问量的增大而动态的增加应用服务器，不存在集群服务的瓶颈问题；缺点是当这个架构只解决了应用的动态扩展问题，最终服务的压力会传递到数据库层面上，当服务访问量足够大的时候，应用可以支撑，但是会因为数据库压力过大而导致整体服务不可用。

（4）微服务架构；这种架构目前是主流互联网平台的标配，主要是为了解决当访问量增大和业务功能扩大时，某个系统的性能瓶颈会拖累整个系统，这种架构风格是将一个复杂的应用拆分成多个独立自治的服务，服务与服务间通过松耦合的形式交互，相对于分布式架构，是直接将数据库和服务也同步分解了，这样相对于分布式架构可以有效的避免因为某个功能的数据库压力过大而导致整个系统出现严重的性能瓶颈。缺点是复杂度高，相对于以上其他类型的技术架构，微服务架构整体的复杂度高，服务治理和运维成本高，后续系统的扩展和维护成本也高。需要有固定专业的技术团队来负责。

需要说明的是，Spring Cloud微服务架构集成：

Spring cloud是当下主流的微服务框架，其包括各种微服务、注册发现、服务网关、熔断器、统一配置、跟踪服务等。

Fegin(接口调用)：微服务之间通过Rest接口通讯，Spring Cloud提供Feign框架来支持Rest的调用，Feign使得不同进程的Rest接口调用得以用优雅的方式进行，这种优雅表现得就像同一个进程调用一样。

Netflix eureka(注册发现)：微服务模式下，一个大的Web应用通常都被拆分为很多比较小的web应用(服务)，这个时候就需要有一个地方保存这些服务的相关信息，才能让各个小的应用彼此知道对方，这个时候就需要在注册中心进行注册。每个应用启动时向配置的注册中心注册自己的信息（IP地址，端口号, 服务名称等信息），注册中心将他们保存起来，服务间相互调用的时候，通过服务名称就可以到注册中心找到对应的服务信息，从而进行通讯。注册与发现服务为微服务之间的调用带来了方便，解决了硬编码的问题。服务间只通过对方的服务id，而无需知道其IP地址和端口即可以获取对方服务。

Ribbon(负载均衡)：Ribbon是Netflix发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为。为Ribbon，配置服务提供者的地址列表后，Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者去请求。Ribbon默认为我们提供了很多的负载均衡算法，例如轮询、随机等。当然，我们也可为Ribbon实现自定义的负载均衡算法。在SpringCloud中，当Ribbon与Eureka配合使用时，Ribbon可自动从EurekaServer获取服务提供者的地址列表，并基于负载均衡算法，请求其中一个服务提供者的实例（为了服务的可靠性，一个微服务可能部署多个实例）。

Hystrix(熔断器)：当服务提供者响应非常缓慢，那么消费者对提供者的请求就会被强制等待，直到提供者响应或超时。在高负载场景下，如果不做任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统的崩溃（雪崩效应）。Hystrix正是为了防止此类问题发生。Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。

包裹请求：使用HystrixCommand（或HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。

跳闸机制：当某服务的错误率超过一定阈值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。

资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判定。

监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时和被拒绝的请求等。

回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员指定。

2.反向代理技术：反向代理服务器位于用户与目标服务器之间，但是对于用户而言，反向代理服务器就相当于目标服务器，即用户直接访问反向代理服务器就可以获得目标服务器的资源。同时，用户不需要知道目标服务器的地址，也无须在用户端作任何设定。反向代理服务器通常可用来作为Web加速，即使用反向代理作为Web服务器的前置机来降低网络和服务器的负载，提高访问效率。反向代理方式与包过滤方式或普通代理方式并无冲突，因此可以在防火墙设备中同时使用这两种方式，其中反向代理用于外部网络访问内部网络时使用，正向代理或包过滤方式用于拒绝其他外部访问方式并提供内部网络对外部网络的访问能力。因此可以结合这些方式提供最佳的安全访问方式。通过反向代理技术可以达到以下的作用：

2.1、提高了内部服务器的安全：外部网络用户通过反向代理访问内部服务器，只能看到反向代理服务器的IP地址和端口号，内部服务器对于外部网络来说是完全不可见。而且反向代理服务器上没有保存任何的信息资源，所有的网页程序都保存在内部服务器上，对反向代理服务器的攻击并不能使真的网页信息系统受到破坏，这样就提高了内部服务器的安全性。

2.2、加快了对内部服务器的访问速度：在内部服务器前放置两台反向代理服务器，分别连接到教育网和公网，这样公网用户就可以直接通过公网线路访问学校服务器，从而避开了公网和教育网之间拥挤的链路。同时反向代理服务器的缓存功能也加快了用户的访问速度。

2.3、节约了有限的IP地址资源：互联网应用一般会采用公网的IP地址对外提供服务，公网分配的IP地址数目是有限的，如果每个服务器有分配一个公网地址，那是不可能的，通过反向代理技术很好的解决了IP地址不足的问题。

3.分库分表技术：关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。

数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分；微服务架构本身结合的分库技术就是垂直分库，就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。每个微服务使用单独的一个数据库。通过微服务垂直分库的技术可以解决业务系统层面的耦合，使子系统业务清晰，同时也能对不同业务的数据进行分级管理、维护、监控、扩展等；从而达到应对高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈的目的。

参照图1-图6，示出了本申请一实施例提供的一种数字化技术架构的部署方法；所述方法应用在至少兼容单体架构、集群架构、分布式架构和微服务架构的环境生成相应的安装包；

所述方法包括：

S110、获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；

S120、依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

在本申请的实施例中，通过获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。通过在同时兼容至少四种不同架构的框架上编写业务功能系统的源码，以便于打包成不同技术架构环境下运行的安装包，当整个技术架构升级时，只需要把原有业务功能系统的源码重新打包成符合新技术架构要求的安装包，无需对所述框架和所述业务功能系统的源码进行修改，就能快速地实现系统在新技术架构上的升级，减少成本的投入。

下面，将对本示例性实施例中数字化技术架构的部署方法作进一步地说明。

如所述步骤S120所述，依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

在本申请一实施例中，可以结合下列描述进一步说明步骤S120所述“依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包”的具体过程。

如下列步骤所述，当所述配置指令为构建单体架构的指令时，将所述框架和所述源码打包成单体架构的安装包；或，

如下列步骤所述，当所述配置指令为构建集群架构的指令时，将所述框架和所述源码打包成集群架构的安装包；所述集群架构的安装包包括第一配置文件，所述第一配置文件用于支持所述集群架构的安装包在集群中间件服务器的架构部署；或，

如下列步骤所述，当所述配置指令为构建分布式架构的指令时，将所述框架和所述源码打包成分布式架构的安装包；所述分布式架构的安装包包括第二配置文件，所述第二配置文件用于支持所述分布式架构的安装包的分布式分发；或，

如下列步骤所述，当所述配置指令为构建微服务架构的指令时，将所述框架和所述源码打包成至少一个微服务架构的安装包；所述微服务架构的安装包包括一个业务功能系统的源码。

需要说明的是，在启动应用程序的时候，应用程序会去加载使用@Configuration注解的所有程序类来加载应用程序的配置；在应用程序中，我们定义了一个配置项，这个配置项加入了@ConditionalOnProperty和@EnableFeignClients两个注解，其中@EnableFeignClients注解是用来标注是否开启支持Feign方式来远程调用远程PRC服务；

在JudgeEnableFeignClient配置类中，加入配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令。

作为一种示例，当所述配置指令为构建单体架构的指令时，将所述框架和所述源码打包成单体架构的安装包；

整个系统工程加载将以Jar包依赖的方式进行程序构建（Build），这时整个工程会将所述框架和所述源码打包在一个JAR上，形成了单独的安装包，可以作为单体结构单独部署。

作为一种示例，当所述配置指令为构建集群架构的指令时，将所述框架和所述源码打包成集群架构的安装包；所述集群架构的安装包包括第一配置文件，所述第一配置文件用于支持所述集群架构的安装包在集群中间件服务器的架构部署。整个程序架构接口都是设置为支持无状态会话的服务，在打包过程中可以选择设置中间件服务打包形式，就可以支持部署在集群中间件服务器（WebLogic，WebSphere等），构建成集群架构。

需要说明的是，WebLogic是美国Oracle公司出品的一个application server，确切的说是一个基于JAVAEE架构的中间件，WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和JavaEnterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。WebSphere 是IBM 的软件平台。它包含了编写、运行和监视全天候的工业强度的随需应变 Web 应用程序和跨平台、跨产品解决方案所需要的整个中间件基础设施，如服务器、服务和工具。WebSphere 提供了可靠、灵活和健壮的软件。

作为一种示例，当所述配置指令为构建分布式架构的指令时，将所述框架和所述源码打包成分布式架构的安装包；所述分布式架构的安装包包括第二配置文件，所述第二配置文件用于支持所述分布式架构的安装包的分布式分发；由于服务支持标准的http协议，可以通过部署多个安装包的结点，通过反向代理技术，从而实现将整个系统以分布式服务架构进行构建，整体的部署架构如图4。

作为一种示例，当所述配置指令为构建微服务架构的指令时，将所述框架和所述源码打包成至少一个微服务架构的安装包；所述微服务架构的安装包包括一个业务功能系统的源码。

作为一种示例，获取所述调用指令；依据所述调用指令开启支持feign的方式调用RPC微服务。

在一具体实施例中，所述调用指令为@EnableFeignClients注解，在启动应用程序的时候，JudgeEnableFeignClient配置类将会被应用程序加载并生效，由@EnableFeignClients注解中basePackages参数设置下包路径的service将会全部支持feign的方式来调用RPC微服务。同时将整个工程项目下的各个子系统（商品，订单，用户，商城等）作为独立的系统服务进行部署，并且针对每个子系统都有单独的数据库连接池，也实现了服务的分库，从而整体形成完整的微服务部署构架。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

如图2，示出了本申请一实施例提供的一种数字化技术架构的部署装置；具体包括：

获取模块100，用于获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；

处理模块200，用于依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

在本申请一实施例中，所述处理模块200，包括：

第一处理模块，用于当所述配置指令为构建单体架构的指令时，将所述框架和所述源码打包成单体架构的安装包；

第二处理模块，用于当所述配置指令为构建集群架构的指令时，将所述框架和所述源码打包成集群架构的安装包；所述集群架构的安装包包括第一配置文件，所述第一配置文件用于支持所述集群架构的安装包在集群中间件服务器的架构部署；

第三处理模块，用于当所述配置指令为构建分布式架构的指令时，将所述框架和所述源码打包成分布式架构的安装包；所述分布式架构的安装包包括第二配置文件，所述第二配置文件用于支持所述分布式架构的安装包的分布式分发；

第四处理模块，用于当所述配置指令为构建微服务架构的指令时，将所述框架和所述源码打包成至少一个微服务架构的安装包；所述微服务架构的安装包包括一个业务功能系统的源码。

参照图7，示出了本申请的一种数字化技术架构的部署方法的计算机设备，具体可以包括如下：

上述计算机设备12以通用计算设备的形式表现，计算机设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，内存28，连接不同系统组件（包括内存28和处理单元16）的总线18。

总线18表示几类总线18结构中的一种或多种，包括存储器总线18或者存储器控制器，外围总线18，图形加速端口，处理器或者使用多种总线18结构中的任意总线18结构的局域总线18。举例来说，这些体系结构包括但不限于工业标准体系结构（ISA）总线18，微通道体系结构（MAC）总线18，增强型ISA总线18、音视频电子标准协会（VESA）局域总线18以及外围组件互连（PCI）总线18。

计算机设备12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

内存28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器30和/或高速缓存存储器32。计算机设备12可以进一步包括其他移动/不可移动的、易失性/非易失性计算机体统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质（通常称为“硬盘驱动器”）。尽管图7中未示出，可以提供用于对可移动非易失性磁盘（如“软盘”）读写的磁盘驱动器，以及对可移动非易失性光盘（例如CD-ROM，DVD-ROM或者其他光介质）读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质界面与总线18相连。存储器可以包括至少一个程序产品，该程序产品具有一组（例如至少一个）程序模块42，这些程序模块42被配置以执行本申请各实施例的功能。

具有一组（至少一个）程序模块42的程序/实用工具40，可以存储在例如存储器中，这样的程序模块42包括——但不限于——操作系统、一个或者多个应用系统、其他程序模块42以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本申请所描述的实施例中的功能和/或方法。

计算机设备12也可以与一个或多个外部设备14（例如键盘、指向设备、显示器24、摄像头等）通信，还可与一个或者多个使得操作人员能与该计算机设备12交互的设备通信，和/或与使得该计算机设备12能与一个或多个其他计算设备进行通信的任何设备（例如网卡，调制解调器等等）通信。这种通信可以通过I/O接口22进行。并且，计算机设备12还可以通过网络适配器20与一个或者多个网络（例如局域网（LAN）），广域网（WAN）和/或公共网络（例如因特网）通信。如图7所示，网络适配器20通过总线18与计算机设备12的其他模块通信。应当明白，尽管图7中未示出，可以结合计算机设备12使用其他硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元16、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统34等。

处理单元16通过运行存储在内存28中的程序，从而执行各种功能应用以及数据处理，例如实现本申请实施例所提供的一种数字化技术架构的部署方法。

也即，上述处理单元16执行上述程序时实现：获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

在本申请一实施例中，还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请所有实施例提供的一种数字化技术架构的部署方法。

也即，给程序被处理器执行时实现：获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑磁盘只读存储器（CD-ROM）、光存储器件、磁存储器件或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言——诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言——诸如“C”语言或类似的程序设计语言。程序代码可以完全地在操作人员计算机上执行、部分地在操作人员计算机上执行、作为一个独立的软件包执行、部分在操作人员计算机上部分在远程计算机上执行或者完全在远程计算机或者服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网（LAN）或广域网（WAN）——连接到操作人员计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种数字化技术架构的部署方法和装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种数字化技术架构的部署方法，其特征在于，所述方法应用在至少兼容单体架构、集群架构、分布式架构和微服务架构的环境生成相应的安装包；所述方法包括：

获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；

依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

2.依据权利要求1所述的方法，其特征在于，所述依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包的步骤，包括：

当所述配置指令为构建单体架构的指令时，将所述框架和所述源码打包成单体架构的安装包；或，

当所述配置指令为构建集群架构的指令时，将所述框架和所述源码打包成集群架构的安装包；所述集群架构的安装包包括第一配置文件，所述第一配置文件用于支持所述集群架构的安装包在集群中间件服务器的架构部署；或，

当所述配置指令为构建分布式架构的指令时，将所述框架和所述源码打包成分布式架构的安装包；所述分布式架构的安装包包括第二配置文件，所述第二配置文件用于支持所述分布式架构的安装包的分布式分发；或，

当所述配置指令为构建微服务架构的指令时，将所述框架和所述源码打包成至少一个微服务架构的安装包；所述微服务架构的安装包包括一个业务功能系统的源码。

3.依据权利要求2所述的方法，其特征在于，所述配置项还包括调用指令；所述当所述配置指令为构建微服务架构的指令时，将所述源码打包成至少一个微服务架构的安装包的步骤，包括：

获取所述调用指令；

依据所述调用指令开启支持feign的方式调用RPC微服务。

4.依据权利要求2所述的方法，其特征在于，所述配置项还包括调用指令；所述当所述配置指令为构建微服务架构的指令时，将所述源码打包成至少一个微服务架构的安装包的步骤之后，包括：

依据所述微服务架构的安装包生成服务系统；其中，一所述微服务架构的安装包生成一所述服务系统；

对每一所述服务系统构建数据库连接池。

5.依据权利要求2所述的方法，其特征在于，所述第一配置文件为xml配置文件。

6.依据权利要求2所述的方法，其特征在于，所述第二配置文件为将编写接口设置为无状态的配置文件。

7.一种数字化技术架构的部署装置，其特征在于，应用于单体架构，集群架构，分布式架构和微服务架构的部署；所述装置包括：

获取模块，用于获取配置项以及预设置的框架和至少一个业务功能系统的源码；其中，所述框架至少兼容单体架构、集群架构、分布式架构和微服务架构；其中，所述配置项包括部署目标架构的配置指令，所述配置指令至少包括部署单体架构、集群架构、分布式架构或微服务架构的指令；

处理模块，用于依据所述配置指令和所述框架对所述源码进行打包处理，生成支持目标架构的安装包。

8.依据权利要求7所述的装置其特征在于，所述处理模块，包括：

第一处理模块，用于当所述配置指令为构建单体架构的指令时，将所述框架和所述源码打包成单体架构的安装包；

第二处理模块，用于当所述配置指令为构建集群架构的指令时，将所述框架和所述源码打包成集群架构的安装包；所述集群架构的安装包包括第一配置文件，所述第一配置文件用于支持所述集群架构的安装包在集群中间件服务器的架构部署；

第三处理模块，用于当所述配置指令为构建分布式架构的指令时，将所述框架和所述源码打包成分布式架构的安装包；所述分布式架构的安装包包括第二配置文件，所述第二配置文件用于支持所述分布式架构的安装包的分布式分发；

第四处理模块，用于当所述配置指令为构建微服务架构的指令时，将所述框架和所述源码打包成至少一个微服务架构的安装包；所述微服务架构的安装包包括一个业务功能系统的源码。

9.一种设备，其特征在于，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至6中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6中任一项所述的方法。

Images