阅读说明：本技术 基于单体遗留应用的微服务的容器化部署 (Containerized deployment of microservices based on monolithic legacy applications ) 是由 J·杰格 D·杜兰德 P-J·迪茨施德 J-L·乌阿托克斯 于 2017-04-28 设计创作，主要内容包括：本公开提供一种以存储在非暂态介质中的计算机指令实现的可扩展的基于容器的系统。本公开还提供一种创建和操作可扩展的基于容器的系统的方法。(The present disclosure provides an extensible container-based system implemented in computer instructions stored in a non-transitory medium. The present disclosure also provides a method of creating and operating an extensible container-based system.)

基于单体遗留应用的微服务的容器化部署

技术领域

本发明涉及用于分割单体遗留应用以部署为在容器化、可扩展和灵活的操作环境中执行的微服务的技术和系统。

背景技术

在遗留大型机计算环境中，通常会发现包括在单个操作环境中以非常单一的结构全部一起运行的成千上万个单独程序的单体应用。程序的该单体结构可能表示在开发其底层代码时的时间和资源的大量投资(多达数千人年)，并且软件程序的相互依赖性质使得从一个计算机环境转换或迁移代码非常困难。

遗留程序文件可以利用约束条件进行编译、汇编和链接，以仅在特定体系结构和指令集的处理器(通常被称为遗留系统或遗留平台的一部分)上运行。

图1A描绘使用管理程序(hypervisor)虚拟化的遗留平台(100)的元素。系统硬件(10)可以包括例如大型计算机，该大型计算机运行通常作为虚拟机监视器(z/VM)的管理程序(30)，以提供一组完全隔离的虚拟机(70)，每个虚拟机具有其自己的通常在其中运行程序的访客操作系统(OS)。管理程序(30)提供管理平台，该管理平台将主机的资源分割为可以在遗留系统内独立操作的一组虚拟机或访客机(70)。访客操作系统(40)或多个访客操作系统(40)安装在虚拟机中。然后，一组二进制文件和库程序(50)以及一个或多个应用(60)在给定的虚拟机上运行。像物理机一样，虚拟机具有关联的状态信息，可以被备份或还原，并且可以分配有专用的系统资源。在管理程序系统中启动和清理虚拟机需要大量开销，因此，在建立后，虚拟机通常保留相当长的运行时间。

图1B描绘容器管理系统(110)的示例。容器系统的硬件(15)可以是物理服务器或物理服务器集群，例如可以是基于X86的计算机。系统的主机操作系统内核(25)(例如Linux)被平台共享，并且通过容器管理系统(35)(例如集装箱(Docker))启用一组容器(75)。特别地，Linux内核的名称空间和控制组(cgroup)功能可用于容器化。容器管理系统可以被提供为围绕内核功能的包装器，并且允许容器管理(例如部署)。

可以使用其他容器管理系统(例如亚马逊ACS、Azure容器服务、云铸造厂(CloudFoundry)Diego、核心OS队(CoreOS Fleet)、集装箱群(Docker Swarm)、谷歌容器引擎(Google Container Engine)或中层马拉松(Mesosphere Marathon)容器管理系统)或其他容器管理和编排系统。容器管理系统(35)和一组共享的操作系统库(85)提供如下平台，在该平台中一组容器(75)可以执行。例如，一些低级操作系统库(35)(诸如用于基本文件输入/输出(I/O)功能的那些操作系统库)可以通过操作系统内核或容器管理系统被所有容器共享，而不是驻留在各个容器中。

与虚拟机的情况一样，一组二进制文件和库程序(55)以及一个或多个应用(65)在一组容器(75)中运行。举例来说，提供网络(web)访问服务(例如http协议)的库可能仅在一些应用中才需要，而在其他应用中不需要，因此当特定应用服务需要时，将其包括在库程序(55)中，但是从仅具有从未使用网络(web)访问服务的应用的容器的库程序(55)中省略。

与虚拟机相比，容器是相对轻量级的构造，并且不负担其自己的完整操作系统的开销以及与物理机或虚拟机相关联的所有状态信息。因此，容器的启动和清理需要很少的开销，这使得容器的部署和终止成为用于集群内的应用升级、动态负载平衡和资源分配的有效技术。

特别地，虚拟机具有其自己的操作系统、文件系统、处理器、网络适配器和相关联的存储卷。它们在管理程序上运行访客操作系统的事实使虚拟机成为繁重的进程，伴随着在彼此之上运行无法轻松启动和终止的两个操作系统(管理程序+访客操作系统)的开销，以适应对应用服务的不断变化的需求。另一方面，容器通过内核直接访问和其他物理资源(包括存储卷)来共享核心操作系统功能。存储卷通常驻留在固定盘驱动器上，但是也可以驻留在其他大容量存储装置中，所述大容量存储装置包括闪速驱动器、磁带或其他固定或可移除存储介质。尽管不同容器的行为可能会基于合并到被加载到那些特定容器中的映像中的二进制文件和库程序而有所不同，但是共享操作系统服务的使用会大大减少与容器的每个单独实例相关联的开销。因此，相对于虚拟机，容器是轻量级的，这使得响应于应用需求来实例化和终止容器更加可行。实际上，例如，在运行集装箱(Docker)的Kubernetes容器管理系统的情况下，可以在几分之一秒的时间内启动容器。因此，大型部署可能每秒启动和终止数千个这些容器。

容器管理系统也可以包括容器集合(pod)。容器集合是容器系统中的部署单位，其包括在同一主机或集群上一起部署的一个或多个容器。在一些容器管理系统(例如Kubernetes)中，容器集合中的容器共享相同的网络名称空间和端口空间。此外，附连到容器集合的共享存储卷可以安装在容器集合的容器中的一个或多个容器中。

标准的Linux发行版包括上万(甚至数十万)个单独的文件，并且，取决于使用这样的系统的应用，标准的Linux发行版可以与向平台增加功能的成千上万的附加系统软件包结合使用。这样的软件包的示例包括阿帕奇网络服务器(Apache web server)、Java虚拟机、PostgreSQL、或提供数据库或语言支持的其他软件包等。这些软件包包括描述软件包以及软件包与其他库之间的依赖关系的元数据和程序代码。共享库可被动态链接的软件包使用以提供强大的功能，但是可能大大增加Linux映像的占用空间(footprint)和系统管理的复杂性。合并有极少软件包的Linux的最小实例可能只占用几兆字节的存储器。另一方面，用于支持例如具有高级数据库服务的大型应用网络(web)服务器的具有许多软件包的大型安装可能占用数百兆字节的存储空间，甚至更多。基于Linux的平台的管理通常包括使用软件包管理器软件来管理软件包与库之间的依赖关系以及这些库和软件包的反复升级。一次为多个目标提供服务的大型映像比简单的映像更难以管理。

微服务通常是小型的自主服务，其可以紧密协作在一起以提供应用的功能。微服务的自主特性使得它们能够被彼此独立地部署为隔离的服务，所述隔离的服务可以通过网络调用与其他服务进行通信。一组紧密相关的微服务或在操作中共享对公共卷的访问的微服务可以部署在同一容器集合内。微服务体系结构提供了集群系统上的可管理性、可用性、可扩展性和可部署性的重要优点。然而，许多遗留应用的单体特性使得将这样的单体应用转换为最少相互依赖的微服务集变成困难且需要大量人工的任务。使问题更加复杂的是，由于指令集和API的差异，以Cobol编写并且编译为在具有其专有API的遗留体系结构(诸如MVS或z/OS)上运行的遗留单体应用通常无法从遗留体系结构导出并且在Linux或其他操作系统或集群上运行，尤其是基于x86的服务器时。

更一般而言，可以开发通过仿真、交叉编译、转码或混合方法将应用代码从一个操作环境转换为另一个操作环境的系统，以使得经编译的遗留程序能够在使用不同的底层体系结构的访客操作系统上运行。然而，这样的系统本身往往是不容易扩展的大型程序，这在运行执行高事务量的应用的情况下尤其成问题。另外，仿真或转码系统适合单体应用，这是因为为了有用，仿真器或转码器必须能够在访客环境中执行遗留环境的可能指令的未知子集。

发明内容

本发明提供一种以存储在非暂态介质中的计算机指令实现的能扩展的基于容器的系统。所述系统包括：源代码存储库，所述源代码存储库包含单体遗留应用的源代码，所述单体遗留应用包含能在遗留计算环境中执行以执行多个事务的多个程序。所述系统还包括：源代码分析器，所述源代码分析器能操作以解析所述源代码，并且对于所述多个事务中的每个事务识别对在该事务期间被潜在地调用的每个程序进行识别的事务定义向量，以创建多个事务定义向量。所述系统还包括：事务状态定义存储库，所述事务状态定义存储库能操作以存储所述多个事务定义向量。所述系统还包括：活动日志分析器，所述活动日志分析器能操作以创建动态定义存储库，所述动态定义存储库识别由所述单体遗留应用在执行所述多个事务中的至少一个子集时实际使用的那些程序。所述系统还包括：微服务定义优化器，所述微服务定义优化器能操作以将所述多个事务定义向量与所述动态定义库进行比较，并且从所述事务定义向量中移除未使用的程序，以创建定义多个微服务的多个微服务定义向量。所述系统还包括：微服务映像构建器，所述微服务映像构建器能操作以对于所述多个微服务定义向量中的每个微服务定义向量，为由该微服务定义向量识别的每个程序定位经编译的源代码二进制文件，所述源代码二进制文件被编译为在遗留计算环境中运行以形成对应于所述微服务定义向量的多个微服务映像。所述系统还包括：微服务映像存储库，所述微服务映像存储库能操作以存储所述多个微服务映像。所述系统还包括：补充组件存储库，所述补充组件存储库能操作以存储遗留仿真器的仿真器元素的一组二进制映像，所述仿真器元素合起来小于完整的遗留仿真器，所述映像对应于所述遗留计算环境的多个函数或函数集，并且所述映像能在以与遗留环境的指令集不同的指令集为特征的不同的计算机环境中执行。所述系统还包括：容器构建器，所述容器构建器能操作以使用来自所述微服务映像存储库的对应的一个或多个微服务映像，并且使用来自对于所述遗留仿真器的仿真器元素的所述补充组件存储库的、对应于由所述微服务或微服务集在执行时采用的函数或函数集的、由所述微服务或微服务集中的二进制文件中的调用签名所识别的映像文件，为所述多个微服务中的每个微服务或微服务集形成容器映像，以创建多个容器映像。所述系统还包括：容器映像存储库，所述容器映像存储库能操作以存储能在不同的计算环境中执行的所述多个容器映像。所述系统还包括：容器管理系统，所述容器管理系统能操作以创建至少一个容器以在不同的计算环境中执行，并且在所述至少一个容器中运行存储在所述容器映像存储库中的至少一个微服务。

根据另外的实施例，除非明确地相互排斥，所有另外的实施例可以与以上系统以及彼此以及以上系统的任何组合进行组合，本发明还提供：

i)所述活动日志分析器能操作以创建与所述多个事务定义向量中的至少一部分相对应的多个动态事务定义向量，并且其中，所述微服务定义优化器将每个动态事务定义向量与每个对应事务定义向量进行比较，以创建所述多个微服务定义向量；

ii)所述活动日志分析器使用通过在所述遗留计算环境中运行所述单体遗留应用而生成的所述单体遗留应用的遗留活动日志；

iii)所述活动日志分析器使用仿真器来运行所述单体遗留应用以生成日志文件，并且确定由所述单体遗留应用在事务的执行期间使用的那些程序；

iv)所述源代码分析器能操作以使用来自所述活动日志分析器的信息来识别所述事务定义向量；

v)所述源代码分析器还能操作以创建多个转换表；

vi)所述微服务定义优化器能操作以进一步优化所述微服务定义向量；

vii)所述微服务定义优化器能操作以通过创建附加微服务定义向量来进一步优化所述微服务定义向量，所述附加微服务定义向量包含由所述多个事务中的一个以上事务共享的程序；

viii)还包括二进制文件存储库，所述二进制文件存储库能操作以存储包含被编译为在所述遗留计算环境中运行的二进制文件的经编译的源代码；

ix)所述二进制文件存储库中的经编译的源代码被从所述源代码存储库中的源代码编译为二进制文件；

x)所述遗留计算环境包括多虚拟存储(MVS)或z/OS计算机系统；

xi)所述补充组件存储库还能操作以存储由所述遗留仿真器使用的操作系统软件包的多个映像，并且其中，所述容器构建器还将由所述遗留仿真器的特定元素使用的任何软件包的映像放置在包含所述遗留仿真器的所述特定元素的特定容器映像中；

xii)所述容器构建器还能操作以利用在所述遗留仿真器中能操作的调用的指令来替换所述微服务或微服务集中的二进制文件中的调用签名；

xiii)所述容器管理系统能操作以创建多个容器；

xiv)一组补充映像被实例化在公共容器集合内的单独容器中；

xv)至少一个容器映像的一个以上副本被在一个以上单独容器中激活；

xvi)所述容器管理系统能操作以使所述多个容器中的容器的数量变化；

xvii)所述容器管理系统能操作以将变化的资源分配给单独容器；

xviii)所述容器管理系统能操作以使用来自所述活动日志分析器的信息来确定如何将至少一个容器映像的多个副本放置到一个以上单独容器中，以确定所述多个容器中的容器的数量和/或确定要分配给单独容器的资源；

xix)所述容器管理系统能操作以使用来自所述能扩展的基于容器的系统的使用的信息来确定如何将至少一个容器映像的多个副本放置到一个以上单独容器中，以确定所述多个容器中的容器的数量和/或确定要分配给单独容器的资源；

xx)所述源代码分析器还能操作以从所述单体遗留应用的数据库创建一个或多个子数据库或子数据库集群；

xxi)所述容器构建器能操作以将所述一个或多个子数据库或子数据库集群放置在一个或多个容器中；以及

xxii)当所述源代码改变时，所述基于容器的系统能操作以自动更新至少一个微服务映像、至少一个容器映像和至少一个容器，以包含基于源代码改变而更新的二进制文件。

本发明还提供一种创建和操作能扩展的基于容器的系统的方法。所述方法包括：解析能在遗留计算环境中执行的单体遗留应用，并且对所述单体遗留应用的程序文件进行分割，以创建与能由所述单体遗留应用执行的多个事务相对应的多个事务定义向量，以及对于每个事务识别由该事务调用的所有程序。所述方法还包括：将所述多个事务定义向量存储在事务状态存储库中。所述方法还包括：对于所述多个事务中的至少一部分，通过确定当由所述单体遗留应用执行事务时实际使用的那些程序来创建动态定义存储库。所述方法还包括：将所述多个事务定义向量与所述动态定义存储库进行比较，并且从事务的对应事务定义向量中移除未在该事务中使用的程序，以创建多个微服务定义向量。所述方法还包括：对于所述多个微服务向量中的每个微服务定义向量，定位包含被编译为在所述遗留计算环境中运行的二进制文件的对应的经编译的源代码，并且创建包含所述对应的经编译的源代码的微服务映像以形成多个微服务映像。所述方法还包括：将所述多个微服务映像存储在微服务映像存储库中。所述方法还包括：在补充组件存储库中，存储能操作以在与所述遗留计算环境不同的计算环境中执行程序的遗留仿真器的多个元素的映像，所述遗留仿真器的元素对应于所述单体遗留应用的多个函数或函数集。所述方法还包括：使用来自所述微服务映像存储库的对应微服务映像或多个映像，并且使用来自对于所述遗留仿真器的元素的所述补充组件存储库的、对应于由所述微服务或微服务集在执行时采用的函数或函数集的、由所述微服务或微服务集中的二进制文件中的调用签名所识别的映像文件，为所述多个微服务中的每个微服务或微服务集形成容器映像，以创建多个容器映像。所述方法还包括：将所述容器映像存储在容器映像存储库中。所述方法还包括：使用容器管理系统在不同的计算环境中创建至少一个容器，并且以能在所述不同的计算环境中执行的形式在所述容器中存储至少一个容器映像。

所述方法还包括：在所述容器中执行所述微服务或微服务集。

根据另外的实施例，除非明确地相互排斥，所有另外的实施例可以与以上方法以及彼此以及以上方法的任何组合进行组合，本发明还提供：

i)使用所述活动日志分析器创建与所述多个事务定义向量中的至少一部分相对应的多个动态事务定义向量；以及使用所述微服务定义优化器将每个动态事务定义向量与每个对应的事务定义向量进行比较，以创建所述多个微服务定义向量；

ii)包括：所述活动日志分析器使用通过在所述遗留计算环境中运行所述单体遗留应用而生成的所述单体遗留应用的遗留活动日志；

iii)包括：所述活动日志分析器使用仿真器来运行所述单体遗留应用以生成日志文件，并且确定由所述单体遗留应用在事务的执行期间使用的那些程序；

iv)包括：所述源代码分析器使用来自活动日志分析器的信息来识别所述事务定义向量；

v)使用所述源代码分析器创建多个转换表；

vi)进一步使用所述微服务定义优化器来优化所述微服务定义向量；

vii)通过创建附加微服务定义向量来使用所述微服务定义优化器进一步优化所述微服务定义向量，所述附加微服务定义向量包含由所述多个事务中的一个以上事务共享的程序；

viii)将包含被编译为在所述遗留计算环境中运行的二进制文件的经编译的源代码存储在二进制文件存储库中；

ix)将所述二进制文件存储库中的源代码从所述源代码存储库中的源代码编译为二进制文件；

x)所述遗留计算环境包括多虚拟存储(MVS)或z/OS计算机系统；

xi)所述补充组件存储库存储由所述遗留仿真器使用的操作系统软件包的多个映像，并且所述容器构建器还将由所述遗留仿真器的特定元素使用的任何软件包的映像放置在包含所述遗留仿真器的所述特定元素的特定容器映像中；

xii)所述容器构建器利用能在所述遗留仿真器中操作的调用的指令来替换所述微服务或微服务集中的二进制文件中的调用签名；

xiii)使用所述容器管理系统来创建多个容器；

ix)在公共容器集合内的单独容器中实例化一组补充映像；

x)在一个以上单独容器中激活至少一个容器映像的一个以上副本；

xi)所述容器管理系统使所述多个容器中的容器的数量变化；

xii)所述容器管理系统将变化的资源分配给单独容器；

xiii)所述容器管理系统使用来自所述活动日志分析器的信息来确定如何将至少一个容器映像的多个副本放置到一个以上单独容器中，以确定所述多个容器中的容器的数量和/或确定要分配给单独容器的资源。

xiv)所述容器管理系统使用来自所述能扩展的基于容器的系统的使用的信息来确定如何将至少一个容器映像的多个副本放置到一个以上单独容器中，以确定所述多个容器中的容器的数量和/或确定要分配给单独容器的资源；

xv)所述源代码分析器从所述单体遗留应用的数据库创建一个或多个子数据库或子数据库集群。

xvi)所述容器构建器将所述一个或多个子数据库或子数据库集群放置在一个或多个容器中；

xvii)当所述源代码改变时，自动更新至少一个微服务映像、至少一个容器映像和至少一个容器，以包含基于源代码改变而更新的二进制文件。

附图说明

为了更全面地理解本发明的各个实施例及其特征和优点，现在结合附图参考以下描述，在附图中：

图1A是现有技术的基于管理程序的虚拟机环境的示意图。

图1B是可以与本发明一起使用并且修改的基于容器的虚拟化环境的示意图。

图2A是与应用的事务相对应的一组程序向量的示意图。

图2B是与应用的事务相对应的一组优化程序向量的示意图。

图3是用于将单体遗留应用分割为微服务的可扩展的基于容器的系统的组件的图示。

图4是用于单体遗留应用中的两个事务的调用树的组件的图示。

图5是用于在可扩展的基于容器的环境中被实现为微服务的图4的相同两个事务的调用树的图示。

图6是描绘用于解析单体遗留应用以在可扩展的基于容器的环境中部署微服务的方法的步骤的流程图。

具体实施方式

根据本发明的一个方面，提出一种可扩展的基于容器的系统，所述可扩展的基于容器的系统可以自动将单体遗留应用分割为微服务集，并且在容器中利用遗留仿真器的适当元素来部署这样的微服务。

具有不同体系结构的处理器支持具有不同二进制表示形式的不同指令集，其结果是，包括一个指令集的机器指令(通常被称为“二进制”或“二进制映像”)的可执行程序通常不会在具有不同体系结构和不同对应指令集的不同处理器上执行。因此，被设计为在遗留计算环境(诸如包括遗留处理器的遗留大型机计算环境)中的使用特定机器指令集的具有特定体系结构的遗留处理器上运行的单体遗留应用不容易在不同计算环境中的不同类型的处理器上可执行。特别地，本文中描述的可扩展的基于容器的系统使用与单体遗留应用被设计为在其中运行的遗留计算环境不同的处理器、不同的指令集和不同的计算环境来操作。因此，如果不修改单体遗留应用和/或不同的计算环境(诸如本文中描述的那些)，则单体遗留应用将不能在可扩展的基于容器的系统的不同计算环境中运行。

通常，为了在包含不同处理器的不同计算环境中运行单体遗留应用，使用为不同体系结构设计的编译器重新编译该单体遗留应用，将其指令转码以在不同体系结构上运行，或者单体遗留应用在遗留体系结构转换器(以下被称为遗留应用仿真器)上运行，该遗留体系结构转换器可以在具有不同体系结构的不同计算环境中运行对于遗留计算环境编译的可执行程序。这仅当存在可以将遗留源代码编译到不同计算环境的合适的编译器或者存在合适的转码器或遗留仿真器时才有可能。

因此，本公开的可扩展的基于容器的系统包括至少一个遗留仿真器元素。然而，可扩展的基于容器的系统通过如下方式来优化遗留仿真器使用：仅在微服务使用遗留仿真器的仿真器元素(例如功能组件的二进制映像)时将这些元素放置在容器中，而不是在每个容器中需要完整的遗留仿真器的映像来完成由单体遗留应用可执行的每项任务。单独的仿真器元素支持单体遗留应用功能的不同子集。

遗留仿真器通常还使用由操作系统提供的各种功能，例如输入/输出功能。可扩展的基于容器的系统不是将整个操作系统的映像放置在每个容器中，而是还通过将操作系统的OS元素(例如功能组件的二进制映像)放置在具有有效地使用这些OS元素的仿真器元素和微服务的容器中来优化操作系统使用。单独的OS元素支持遗留仿真器功能和相关的单体遗留应用功能的不同子集。

可扩展的基于容器的系统可以识别可以使用单体遗留应用执行的独立事务，例如创建记录、下订单、执行查询等。可扩展的基于容器的系统然后识别每个独立事务中包括的程序。最终，可扩展的基于容器的系统创建微服务，这些微服务可被使用或组合以在单体遗留应用外部执行同一事务。在某些情况下，组成来自单体遗留应用的事务的独立程序可能位于不同的微服务中。在其他情况下，微服务可能包含来自单体遗留应用的一个以上程序。另外，由于微服务可以以任何方式对程序进行分组以有效地完成来自单体遗留应用的事务，因此来自单体遗留应用的任何一个程序可能仅位于可扩展的基于容器的系统的一个微服务中，或者它可能位于可扩展的基于容器的系统的多个不同微服务中。

单个容器映像中的微服务可以通过可扩展的基于容器的系统而被部署在多个并行实例中，通常被部署在单独容器中。容器可以包括一个以上的微服务以及允许微服务执行和起作用所需要的其他信息。微服务可以优选地被构造为最小地相互依赖和/或最小化当更新程序时需要改变的微服务的数量。微服务容器映像可以被限制为应用程序二进制文件，然后与通用实用程序(错误日志记录、活动日记(journaling)、安全性等)容器相关联以形成容器集合。

可扩展的基于容器的系统高度灵活，允许改变微服务本身以及容器的类型和数量、被分组在一个或多个特定容器中的微服务和支持程序，例如容器中包含的OS元素和仿真器元素以及基于事务、程序、其他信息或者事务或微服务的使用等因素的改变而专用于特定容器或容器集合的资源。

另外，从单体遗留应用或其一部分创建的微服务的总数可以大于单体遗留应用或其一部分中的独立事务的总数。

图3示出可扩展的基于容器的系统(300)。可扩展的基于容器的系统可以包括存储单体遗留应用的源代码的源代码存储库(305)。单体遗留应用的源代码可以是例如单体COBOL应用，该单体COBOL应用可以包括被设计为独立地或成组地执行数百个不同事务T₁、T₂、....T_x的数十个、数百个甚至多达数万个独立程序文件。这样的事务的示例可以包括客户记录的创建、更新、移动或删除，其例如可以使用客户信息控制系统(“CICS”)或信息管理系统(“IMS”)来执行数据库2(“DB2”)关系数据库事务或数据语言接口(“DL/I”)分层数据库事务。编译器(310)将源代码编译为一组被存储在二进制文件存储库(315)中的一个或多个二进制文件。

根据某些实施例，源代码分析器(320)通常经由依赖性分析器组件来解析存储在源代码存储库(305)中的单体遗留应用中的源代码和相关联的文件，并且生成识别源代码中的相互依赖性(调用方<>被调用方)的代码树。优选地，源代码分析器(320)如在事务系统(例如，CICS，IMS等)的配置参数中所定义的那样迭代通过单体遗留应用的每个事务。在一个示例中，源代码分析器(320)从源代码存储库(305)接收如下文件作为输入，该文件识别可以由用户在其与单体遗留应用的交互中调用的可用CICS事务定义。优选地，该文件识别每个事务及其根、或者当执行事务时调用的第一个程序。这可能包括在许多事务中使用的作为EXEC CICS链接(EXECCICS LINK)的被调用方的根程序。在该示例中，根程序是指由处理接口的程序调用的第一个程序(例如，当接口为3270时进行发送/接收映射，但是当接口不同时也进行其他等同的API)。可以使用识别事务或有助于其服务的其他文件或格式，例如，附加构建文件可以包括由事务使用的资源(例如消息队列和数据源)的定义文件。

另外，源代码分析器(320)可以解析与单体遗留应用相关联的所有程序文件，以检测单体遗留应用的所有事务的程序文件之间的相互依赖关系(程序的调用方<>被调用方或诸如抄本(copybook)的资源的包含)。源代码分析器(320)内的依赖性分析器识别由事务使用的程序之间的调用方-被调用方或包含关系。静态分析器可以生成向量或向量集或图形形式的调用树或包含树，该调用树或包含树识别用于特定事务的源代码可以调用或包括的程序或模块。

期望对单体遗留应用进行分割，以将应用划分为例如可以经由SOAP或REST(具有JSON或其他数据格式)进行访问的一组最小地相互依赖的事务。每个最小相互依赖的事务可能能够在遗留仿真器(325)的独立实例中运行。源代码分析器(320)的输出可以是对于每个事务识别完整程序集的程序调用或包含树或图形，该完整程序集可以被调用或使用以执行每个事务以及程序之间的调用方-被调用方关系或包含关系。图4是这样的调用树的示例，其中第一事务T1以根程序A开始，然后根程序A可以调用程序F或程序D。仍然在事务T1中，然后程序D可以调用程序E。第二事务T2以根程序B开始，然后根程序B可以调用程序C，或者也可以调用同一程序D，然后程序D再调用程序E。

调用树可以被转换为一组向量，每个向量用于单体遗留应用的可能事务中的每个事务或所定义的子集，这一组向量识别可以在执行事务中被调用的程序。图2A描绘事务定义向量Ta(210)、Tb(220)、...Tc(230)的集合(200)的示例。在该示例中，第一向量(例如Ta(210))包括在执行第一事务时潜在地被调用的一组程序<P1,P2,...Px>。使用图4的示例，事务可以是T1，并且这组程序将包括程序A、F、D和E。还示出了与第二事务和第三事务相对应的第二说明性向量Tb(220)(包括程序<P2,P3,...Py>)和第三说明性向量Tc(230)(包括程序<P1,P6,....Pz>)。程序的不同数量和组合可以指定单体遗留应用的不同事务。

源代码分析器(320)还可以基于根程序的接口定义，提取或生成数据类型、消息、消息格式/绑定以及消息输入和输出集合，并且定义每个事务的地址和端点，以及将该信息转换为消息结构以供在将消息提供给容器构建器(330)和/或容器管理系统(335)时构造并定义与事务的接口例如作为微服务映像的一部分时使用。另外，如果使用SOAP协议，则源代码分析器(320)还可以生成WSDL消息接口。WSDL消息接口可以是W3C标准中定义的格式化文档，包括用于存储所定义的数据类型、消息、端口类型、绑定、端口和服务定义信息的结构。如果其他协议(REST等)和表示(JSON)对于给定情况是优选的，则源代码分析器(320)还可以生成接口消息的其他表示。源代码分析器还可以进一步被配置为生成双向数据编码转换表或过程，以将UTF字符转换为8比特EBCDIC字符，反之亦然(或者在包括ASCII的不同字符集之间转换)，以及可以通过基于事务并且在其朝向请求者的接口处生成要与微服务一起使用的脚本/程序来实现该转换。

事务定义向量的集合(200)、通信接口定义(WSDL、REST)和通过脚本的转换指令可以存储在事务状态定义库(340)中。

源代码分析器(320)还可以包括转码应用的一部分以呈现转码器路径，以便将经转码的程序用到可扩展的基于容器的系统中。以这种方式，源代码分析器还可以用来支持将源代码从其原始语言(例如Cobol)转变到不同语言(例如Java)。可以执行其他源代码转换。此外，源代码分析器(320)也可以以不是作为转码应用的一部分的分立程序的形式使用。

事务状态定义库(340)中的每个事务定义向量(210)、(220)、(230)包括在使用单体遗留应用执行实际事务的过程中实际调用的程序的超集。通常，事务应用包含从未调用的许多程序。这可能是由于以下各项而引起的：事务应用的初始设计、设计改变、改变用例、在事务应用的不同部分中共享程序及其被调用方、或对事务应用的其他演进。将这些未使用的程序包含在代码中会由于许多原因而导致容器化应用的效率降低，所述许多原因包括：在永久性存储装置上四处移动、将未被调用的程序加载和卸载到中央计算机存储器中所需要的开销，以及在通过网络编译、构建或传输更新到事务容器时的附加延迟。为了从微服务应用映像中消除这些未使用的程序，微服务定义优化器(345)从事务状态定义存储库(340)中提取事务定义向量、接口定义和转换表，并且应用存储在动态定义存储库(350)中的动态定义向量来消除事务状态定义存储库(340)的事务定义向量(210)、(220)、(230)中包括的未使用的程序，以达成如图2B中所示的对应的微服务定义向量(260)、(270)、(280)，其可以由微服务定义优化器(345)以中间状态存储以等待对微服务的进一步细化和定义，或者由微服务映像构建器(350)处理以创建存储在微服务映像存储库(355)中的微服务映像。在大型单体系统遗留应用中，通常会存在可能会以这种方式消除的未使用的程序。然而，对于使用通过静态事务状态分析而识别的所有程序的事务，微服务定义向量将与初始事务定义向量相同。这由图2A中的事务定义向量(220)和图2B中的对应的微服务定义向量(270)示出。

动态定义向量是通过动态定义处理而与事务状态定义向量分开地开发的，其中动态定义处理通常在不同的系统上运行或使用遗留活动日志。动态定义向量可以预先存在，或者动态定义向量可以与事务定义向量并行地开发。

在动态定义处理中，运行单体遗留应用，并且对每个事务进行分析，以确定哪些程序实际上被调用，以及哪些程序未被调用。当系统运行足够长的时间段(例如，取决于应用的性质，星期、月、季度、年)或使用调用所有实际用例的数据集时，则动态定义向量将更精确地识别当执行事务时被实际地调用的程序。

替选地，动态定义向量也可以通过以静态事务状态定义向量开始来生成，该静态事务状态定义向量可能包含过多的程序，然后仅选择被实际地调用的那些程序。因此，可以在识别程序时建立动态定义向量，或者可以通过从事务状态定义向量中消除不需要的程序来创建动态定义向量。

在一些系统中，活动日志分析器(365)使用在遗留计算环境中运行的单体遗留应用的预先存在的遗留活动日志(360)来识别通过现实世界事务的执行而实际调用的程序，从而生成程序向量，该程序向量指示对于每个事务使用哪些程序。

在某些系统中，单体遗留应用在遗留仿真器(325)上运行，并且由仿真器生成的活动日志数据被活动日志分析器(365)分析以生成程序向量，该程序向量指示对于每个事务使用哪些程序。在一些实施例中，遗留仿真器(325)将每个事务执行一段时间以足以确信已经遇到了对于每个事务的用例的所有实际变体。替选地，可以执行被设计为训练每个实际用例的所定义的一组测试事务，从而使得活动日志分析器(365)能够类似地确定哪些程序被单体遗留应用中的事务实际使用。

在一些系统中，活动日志分析器(365)可以使用来自遗留活动日志(360)和遗留仿真器(325)两者的信息来确定哪些程序被单体遗留应用中的事务实际使用。例如，如果遗留活动日志(360)不包含在给定事务中使用的程序的示例，则在断定该事务未使用该程序之前，可以查阅来自遗留仿真器(325)的日志，反之亦然。在另一示例中，可以仅使用遗留活动日志(360)来评估对于其存在充足遗留数据的事务，而无需遗留仿真器(325)进行进一步仿真。在又一个示例中，遗留日志数据可以用作微服务定义的初始线索。

将活动日志分析器的输出存储在动态定义存储库(370)中，该动态定义存储库对于每个事务存储与实际使用的程序相对应的向量。

加载模块是指通常在大型机遗留计算环境的上下文中的可执行程序的全部或一部分。遗留仿真器(325)可以是如下仿真器，该仿真器被开发为允许执行来自z/OS或其他遗留计算环境的经编译的遗留应用或加载模块，以在不同的计算环境(例如具有Linux操作系统的x86平台)中运行。遗留仿真器可以将原始可执行程序的每个本机指令或本机操作系统服务调用转换为不同计算环境的等效指令和系统调用。遗留仿真器(325)可以实现一组本机API，以允许仿真独立遗留指令或系统服务调用。遗留仿真器(325)可以是整个仿真器的单个映像，或者它可以包括本文中进一步讨论的经分割的映像。遗留仿真器(325)可以进一步包括或可访问被遗留仿真器实际使用的操作系统或其组件。

微服务定义优化器(345)将存储在动态定义存储库(370)中的动态事务向量应用于存储在事务状态定义存储库(340)中的事务定义向量，以达成可被微服务映像构建器(350)用来创建微服务映像的微服务定义向量。然后，将这些映像存储在微服务映像存储库(355)中。

图2B描绘微服务定义向量MSa(260)、MSb(270)、...MSc(280)的集合(250)的示例。在该示例中，第一微服务定义向量MSa(260)包括由在执行第一事务Ta时调用的一组程序<P1b,...Px-qb>构成的优化向量。在该示例中，程序P2没有在事务Ta中实际使用，因此被从微服务定义向量中删除。第二示例性微服务定义向量MSb(270)包括程序<P2,P3,...Py>。在该示例中，构成事务定义向量的所有程序都被使用，因此被保留在微服务定义向量中。第三说明性微服务定义向量MSc(280)包括程序<P1,P6,....Pz-y>。作为结果的体系结构包括一组Tx事务，每个事务由最少数量的程序来定义。在先前单体遗留应用的转换操作中以及在可以调用所定义的微服务MSx的增强或修改的应用中，可以将单体遗留应用的Tx事务中的任何事务定义为可独立调用的微服务MSx。

Tx事务中的任何事务也可以被定义为一组可独立调用的微服务。对于来自单体遗留应用的Tx事务的总集合，某个子集可以由每个事务的一个微服务来定义，而另一个子集可以由每个事务的微服务集来定义。例如，如图5中所示，如果事务T1和T2使用公共程序D和E，则当这些事务被微服务定义优化器(345)转换成微服务时，那些公共程序可以被分组为独立的微服务MS3，该微服务MS3可以被包含T1的其他程序的MS1调用，或者被包含T2的其他程序的MS2调用。

微服务定义优化器(345)可以存储微服务映像向量或之后进一步改变或优化的中间微服务映像向量。例如，当向微服务定义优化器(345)提供对于图4的事务的事务定义向量时，微服务定义优化器(345)可以首先创建中间微服务定义向量MS1和MS2，MS1和MS2两者都包含也位于事务定义向量中的程序。微服务定义优化器(345)可以识别这些微服务定义向量MS1和MS2的公共组件(如由图4的元素D和E所示)，并且从前两个微服务定义向量中提取公共组件。如图5中所示，除了第一微服务MS1和第二微服务MS2之外，公共元素D和E还被用来创建第三微服务定义向量MS3，MS3包含这些公共组件并且可以被MS1或MS2调用。然后，将这些优化的微服务定义向量MS1、MS2和MS3提供给微服务映像构建器(350)。

替选地，中间微服务定义向量可以被存储在除微服务定义优化器(345)之外的位置中，诸如被存储在中间存储库(未示出)中。在某些实施例中，中间微服务定义向量可以被存储在微服务映像构建器(350)中，或者作为中间映像被存储在微服务映像存储库(355)中，随后被优化的微服务定义向量或微服务映像访问和/或替换。

编译器(310)编译源代码存储库(305)中的源代码以在二进制文件存储库(315)中产生二进制文件。编译器(310)生成用于诸如系统390或z/OS大型机之类的遗留计算环境的二进制文件。以此方式，用来在本文中描述的可扩展的基于容器的系统中构造微服务映像的二进制文件可以与在遗留计算环境中运行的二进制文件相同，从而促进单体遗留应用从遗留计算环境到可扩展的基于容器的系统的互操作性和渐进迁移。

微服务映像构建器(350)从二进制文件存储库(315)中检索与在微服务定义向量或优化的微服务定义向量(在适用时)中识别的程序相对应的经编译的二进制文件，并且组合这些二进制文件以生成用于每个微服务的映像，所述用于每个微服务的映像包括用于微服务定义向量中的每个程序的二进制映像。微服务映像还可以包括由微服务映像构建器(350)检索的相关联的工件(artifact)和信息，例如共享资源定义等。这些微服务映像被存储在微服务映像存储库(355)中。

容器构建器(375)通过将与存储在微服务映像存储库(355)中的特定微服务相关联的二进制映像和存储在补充组件存储库(380)中的二进制映像相组合来构建容器映像。补充组件存储库(380)可以存储一起构成遗留仿真器的仿真器元素的一组映像文件，该留仿真器通常与由可扩展的基于容器的系统以其他方式使用的遗留仿真器(325)相同。

可以通过功能或功能的子集来分割遗留仿真器，以形成遗留元素，这提供了在本文中所述的基于容器的系统中部署遗留仿真器的优点。例如，对由遗留仿真器支持的接口上的指令子集的支持可以分开。另外，可以分割遗留仿真器中对批处理操作、CICS事务服务、DB2或其他关系数据库服务、IMS服务、安全性、日志记录或其他功能的支持。以此方式，由容器中的微服务使用的遗留仿真器的独立遗留元素或元素集仅可以在给定容器内部运行。另外，由容器集合中的容器使用的某些遗留元素可以存储在单独容器中，然后由容器集合中的其他容器中的微服务访问。合适的遗留元素包括仿真器的运行时环境的跟踪和日志记录功能。这样的设置可以提高性能和/或安全性。

补充组件存储库(380)还可以存储来自遗留仿真器可能使用的操作系统的软件包，其可以被称为OS元素。例如，独立的系统API组件也可以被独立地存储为单独的映像。在一些示例中，可以在运行时组合独立的软件包和库文件以增加由Linux或其他操作系统提供的功能，并且二进制文件可以存储在补充组件存储库(380)中。

容器构建器(375)可以选择性地将用于提供与微服务或微服务集相关联的功能的仿真器元素和/或OS元素合并到包含该微服务或微服务集的容器映像中。以这种方式，与在每个容器中包括完整的遗留仿真器映像或完整的OS映像相比，每个容器的整体映像大小可以更小。

在一些情况下，遗留仿真器的映像可能为数百兆字节。另一方面，执行特定功能(例如特定批处理或特定数据库事务)的仿真器元素可能只有几十兆字节。类似地，完整操作系统的映像可能比由仿真器元素使用的实际组件的映像大很多倍。

因此，与在容器或容器集合中包含完整遗留仿真器的映像或未被微服务使用的仿真器元素的其他相同容器或容器集合相比，将遗留仿真器分割为仿真器元素并且在容器中或在容器集合中的容器中包含少于所有这样的元素可以将用来容纳容器或容器集合的存储器减少五到七倍。

与在容器或容器集合中包含完整OS的映像或未被微服务和/或仿真器元素使用的OS元素的其他相同容器或容器集合相比，在容器中或在容器集合中的容器中包含少于所有的OS元素可以类似地将用来容纳容器或容器集合的存储器减少五到七倍。

通过在容器中或在容器集合中的容器中包括少于所有的仿真器元素和少于OS元素，与在容器或容器集合中包含完整遗留仿真器的映像或未被容器或容器集合中的微服务使用的仿真器元素、以及在容器或容器集合中包含完整OS的映像或未被微服务和/或仿真器元素使用的OS元素的其他相同容器或容器集合相比，也可以将用来容纳容器或容器集合的存储器减少五到七倍。在这种情况下，遗留仿真器大小和操作系统大小的减少对用来容纳两者组合的存储器的减少的相对贡献可能取决于遗留仿真器和操作系统的相对总体大小和两者的分割程度。例如，在将200MB的遗留仿真器分割为大约十个元素并且将50MB的操作系统分割为大约五十个元素的情况下，移除仿真器元素的贡献通常将会超过移除操作系统元素的贡献。

可以将遗留仿真器分割为与微服务的可能需求相对应的仿真器元素。例如，微服务可能不需要某些功能，例如管理控制台和用户界面功能，或者它们可以由以更适合于该体系结构的形式的容器管理系统(385)来本地提供，因此可以与其他仿真器元素分离，甚至可以从补充组件存储库(380)中省略。可以对其他仿真器元素(例如安全性元素)进行专门分割，以便可以将它们放置在与其他仿真器元素和微服务分开的容器中，甚至可以被替换为由新系统提供的类似服务。

遗留仿真器也可以被分割以将遗留仿真器的其他组件所依赖的核心功能放置到核心仿真器元素中。这样的元素可以被包括在大多数(如果不是全部)容器或容器集合中。通常，与其他仿真器元素相比，该核心仿真器元素在总遗留仿真器大小中所占的比例更大。例如，核心仿真器元素可能占总遗留仿真器大小的30％至40％。

遗留仿真器可以被进一步分割以将可能通常在容器集合中的一个或几个容器中、而不是将所有容器中使用的功能(例如安全功能)放置在单独元素(例如安全仿真器元素)中。

以事务仿真器为例，合适的仿真器元素可能还包括在线/通信仿真器元素(例如包含用于CICS的子产品和用于事务服务的IMS-TM的在线/通信仿真器元素)、关系仿真器元素(例如用于DB2的关系仿真器元素)、分层数据库仿真器元素(例如，用于IMS-DB的分层数据库仿真器元素)、数据集/日期管理仿真器元素(例如，用于VSAM文件和顺序文件的数据集/日期管理仿真器元素)、批处理服务仿真器元素、和/或语言仿真器元素(例如具有用于Cobol和PL/1的子产品的语言仿真器元素)、安全仿真器元素以及用户界面/管理控制台仿真器元素。

子产品可以从被实际合并到容器中的仿真器元素映像中排除。例如，在线/通信仿真器元素可以只包含用于CICS的二进制映像而不包含用于IMS-TM的二进制映像。

与总遗留仿真器相比，仿真器元素的大小可能有所不同，但是通常，非核心仿真器元素可能各自占遗留仿真器总大小的1％至20％，尤其是3％至15％。与总遗留仿真器相比的仿真器元素的大小以及其他因素(例如一起使用的可能性)可以在确定将哪些功能分为不同的仿真器元素时使用。

OS元素可以采用可用软件包的形式，例如各种Linux软件包，例如PostgresSQL、LLVM、节点.js(node.js)等。

伴随仿真器元素的OS元素的大小也可以在确定将哪些遗留仿真器功能分为不同的仿真器元素时使用。

在一些可扩展的基于容器的系统中，容器构建器(375)包括加载模块编译器，该加载模块编译器接收存储在微服务映像存储库(355)中的二进制文件(例如系统390或z/OS可执行映像文件)作为输入。加载模块编译器检测由单体遗留应用对遗留计算环境的程序、服务或功能的调用的二进制文件中的所有签名，例如一套汇编程序指令。加载模块编译器可以使用该信息来确定由微服务或微服务集使用的遗留仿真器功能。然后，容器构建器(375)可以在补充组件存储库(380)中的仿真器元素当中定位能够执行这些功能的仿真器元素，并且将仿真器元素以及来自补充组件存储库(380)的任何与微服务映像或微服务映像集相关联的OS元素一起放置到容器映像中。替选地，容器构建器(375)将会把仿真器元素和OS元素的映像放置在与微服务映像或映像集的容器映像相关联的容器映像中，从而将这两个容器映像都放置在容器集合中。

此外，加载模块编译器可以用指令替换二进制文件中的一个或多个签名，以在遗留仿真器中调用在遗留仿真环境中被调用的一个或多个相同功能，从而形成可以存储在容器映像中的遗留仿真器优化的微服务映像。可以使用为单体遗留应用或遗留计算环境以及可扩展的基于容器的系统的遗留仿真器或不同计算环境创建的现有数据库来识别签名并且定位替换指令。另外，容器构建器(375)可以利用对遗留仿真器的本机API的调用来替换所识别的遗留功能调用，并且构造修改后的一个或多个映像。

在如本文中所述的微服务映像或容器映像的任何优化或修改期间或之后，容器构建器(375)随后将其存储在容器映像存储库(390)中。随后，在由容器管理系统(385)管理的容器(395)中执行容器映像存储库(390)中的容器映像。

根据某些实施例，容器映像存储库(390)可以是集装箱(Docker)存储库，其结构类似于公共集装箱中心(DockerHub)。然后，容器管理系统(385)优选地支持集装箱(Docker)容器并且使能其优化的执行。

容器管理系统(385)可以组合以下功能：调度容器的实例化，运行容器，向它们分配受控数量的计算/存储/联网资源，升级它们，和/或可以执行附加的日志记录和管理功能以跟踪和管理系统的健康状况。根据某些实施例，容器管理系统(385)可以是用于集装箱(Docker)容器的Kubernetes容器管理系统。但是，可以使用其他容器管理系统，例如亚马逊ACS、Azure容器服务、云铸造厂(Cloud Foundry)Diego、核心OS队(CoreOS Fleet)、集装箱群(Docker Swarm)、谷歌容器引擎(Google Container Engine)或中层马拉松(MesosphereMarathon)容器管理系统、或其他容器编排系统。容器管理系统(385)可以类似于图1B中所描述的容器管理系统，具有如本文中所述的修改和添加。当容器基于集装箱(Docker)时，由容器管理系统(385)进行的资源的选择性分配可以通过使用控制组(cgroup)来完成。

在容器管理系统(385)前面的智能代理(未显示)可以与最终用户的终端仿真器或需要永久连接的任何其他客户端接口保持永久TCP连接。然后，该代理将扫描在永久连接上的请求，并且将所述请求转换为适当的服务请求，然后由Kubernetes将适当的服务请求路由到适当的微服务。智能代理和微服务中的临时(ad hoc)包装器允许将3270流量或任何其他特定流量封装到微服务请求和响应中。

容器(395)和容器管理系统(385)可以驻留在子系统(400)中。子系统(400)可以与可扩展的基于容器的系统(300)的其余部分在物理上分开，并且可以在分立系统处操作，该分立系统能够实现当使用可扩展的基于容器的系统(300)时可获得的相同益处。例如，子系统(400)可执行本文中所述的资源分配和容器管理功能。特别地，如果子系统(400)也包括容器映像存储库(390)，则容器管理系统(385)也可以使用容器映像来创建附加的或复制的容器。子系统(400)仍可受益于将单体遗留应用分割为微服务，以及在容器映像中仅包含所需要的仿真器元素和OS元素。然而，因为子系统(400)缺少专用于创建微服务定义向量和容器映像的可扩展的基于容器的系统(300)的元素，所以子系统不能自动更新其容器映像和容器。相反，子系统可以接收由容器管理系统(385)应用于容器(395)的更新后的容器映像、或存储在容器映像存储库(390)(如果存在)中的更新后的容器映像。

未示出的另一个子系统可以包括容器(395)、容器管理系统(385)、容器映像存储库(390)、容器构建器(375)和补充组件存储库(380)。这样的子系统可以与可扩展的基于容器的系统(300)的其余部分在物理上分开，并且可以实现结合系统(300)描述的许多益处。这样的子系统具有在被提供有新的微服务映像时更新容器映像的能力。这样的子系统可以进一步包含微服务映像存储库(355)和/或(遗留应用仿真器(325))，但是缺少负责最初地或当更新单体源代码时开发新的微服务定义向量和/或微服务映像的组件。这样的子系统还可以包括遗留应用仿真器(325)。

许多基于关系数据库的遗留应用是根据泰德·科德(TeddCodd)的关系理论构造的，该关系理论最初发表于他的文章“ARelational Model of Data for Large SharedData Banks(大型共享数据库的关系数据模型)”，CACM 13，第6期，1970年6月。这些遗留数据库在设计时就考虑到了最小冗余：它们的结构通常已经被尽可能地归一化了。第五范式(5NF)是其中大多数的最初设计目标，即使多年来实际生活已经改变了该理想形式。高度归一化的结果是，由单体遗留应用使用的数据的各个部分之间的相互依赖性很高。

该纠缠的数据体系结构在单体遗留应用程序中的程序集群之间创建了间接的相互依赖关系，这些程序集群直接共享相同的数据(sql请求访问相同的表)或间接共享相同的数据(由程序X访问的表被由程序Y更新的表的参考完整性约束修改)。

但是，在大多数情况下，通常的大型单体遗留应用在其由数千个表组成的大型数据库中仍然具有独立数据的集群。在可扩展的基于容器的系统中，为了提高各种系统性能，应将这些集群分为独立的子数据库，每个子数据库由独立的微服务集使用。然后，这些子数据库可以例如在单独的数据库服务器中隔离开，并且可以彼此独立地进行管理。这从整体上提高了系统的灵活性和敏捷性，因为从操作角度来看，本地数据结构改变比全局数据结构改变更易于执行。将数据库分为子数据库还提高可扩展的基于容器的系统的全局可用性，因为一个子数据库或其维护的问题不影响其他数据库和使用其他数据库的微服务。

类似于识别程序依赖性，可以通过创建依赖性树来根据微服务体系结构对数据进行分割，该依赖性树通过数据集群在对应事务或事务集中的使用来识别该数据集群。该识别可以由源代码分析器(320)尤其是其依赖性分析器来完成，因为该源代码分析器(320)解析单体遗留应用以产生通常以向量或表的形式的子数据库和子数据库集群，所述子数据库和子数据库集群可以彼此分离以获得上述益处中的至少一些。

各种微服务映像可以共享对相同子数据库的类似访问。特别地，关系数据库服务事务可以与用于遗留仿真器的其他功能的事务分开包装，从而例如最终在单独的微服务中定义数据库服务和处理服务。

完整数据库或子数据库可以在若干个微服务之间共享。完整数据库或子数据库可能位于单独的持久数据库容器中，这些持久数据库容器可以由较短生存期的处理容器进行远程访问。通常，具有处理微服务的容器可以在容器集合中，其中一个或多个容器容纳由处理微服务使用的关系数据库服务和子数据库。

在类似类型的结构中，可以通过如下方式来实现对在单体遗留应用中的事务之间共享的对象的支持：使用源代码分析器检测共享对象，然后使用如由源代码分析器通知的容器构建器在专用资源容器中收集支持对象。例如，在若干个微服务中存在的程序之间共享的CICS TS队列可以驻留在托管它们的长期资源容器中。这些共享对象(例如，存储器会话、消息队列、共享数据对象)可以通过遗留仿真器的远程访问功能进行远程但透明的访问，这些远程访问功能最初是为了复制遗留计算环境的远程访问功能而开发的。在CICS遗留环境的情况下，这些功能是遗留功能(例如MRO、IPIC等)的仿真版本。共享存储器区域(在z/OS系统的情况下，CSA、CICS CWA、CICS TCTUA等)在各个微服务之间共享时可以被检测，被放置在分布式共享缓存中，并且由特定资源容器上的相同远程访问功能进行远程访问。

在另一个相似类型的结构中，为了使分离数据最大化，可以构造跨若干个微服务的事务，这些微服务在对Kubernetes的初始服务请求之后以级联方式彼此同步地调用。该实施例引入了具有分布式两阶段提交的相关问题的分布式事务和数据库连接共享的附加复杂性。

本文中所描述的基于容器的系统通过提供自适应的集成的构建处理而从构建的角度呈现了改变的格局，该构建处理灵活地耦合到生产环境。当对存储在源代码存储库(305)中的源代码进行修改、由编译器(310)编译并且存储在二进制文件存储库(315)中时，源代码分析器(320)、事务状态定义存储库(340)、微服务定义优化器(345)和微服务映像构建器(350)可用来为仅与受改变影响的那些事务相对应的一个或多个微服务构建更新的微服务映像或微服务映像集。然后，容器构建器(375)可以触发构造过程，该构造过程基于由容器构建器先前提取的微服务定义向量、用于更新的微服务的容器映像来自动且最佳地定义和设置，然后可以由容器管理系统(385)来部署。容器映像可以仅包括用于微服务或微服务集的更新的映像，但是如果需要，容器映像还可以包括对来自补充组件存储库(380)的映像的改变。在对源代码进行更极端或更多改变的情况下，可以改变微服务定义向量，以便创建不同的微服务或微服务集。例如，如果将源代码改变为提供使用公共程序集的大量事务，则可以将该公共程序集重新放置在单独微服务中，类似于图5中的MS3，并且相应地修改或创建用于其他微服务的现有的和新的微服务定义向量。

整个更新处理优选地是自动化的，但是更新的微服务的部署也可以被置于管理性管理控制台(未示出)的控制之下。类似地，在存在对诸如数据(例如，抄本、sql文件等)之类的其他信息的改变的情况下，可以识别并且传播对改变的依赖性以自动适应构建过程。

为了说明，更新处理的自动步骤可以包括：(1)将源代码结构放置到源代码存储库中(310)；(2)Jenkins(或其他DevOps构建系统)构建作业定义；(3)通过大型机二进制文件的适当聚类来进行集装箱(Docker)映像构建；以及(4)Kubernetes管理参数。

可扩展的基于容器的系统的微服务结构在更新所需要的改变数量和在这样做时所花费的时间方面也提供了优点。例如，如图5中所示，对程序D或E的改变仅需要在微服务MS3的构建中进行，而不是在事务T1和T2的两个单独的微服务构建MS1和MS2中进行。由大量独立微服务提供的高粒度水平允许并且优选地在全自动下进行操作。

这样的微服务的形成可以提高整体系统的可管理性，因为对改变子树的应用代码的升级或改变仅需要导致对内部微服务(而不是调用它的所有微服务)的对应容器的升级。

考虑到可以容易地构造容器并且减少了将容器映像加载到容器(如果它较小)中的时间，许多可扩展的基于容器的系统中的微服务定义优化器(345)可以实施指令以创建每个事务定义向量的多个微服务定义向量，尤其是在如图4和图5中所示的事务使用适合被放置在单独微服务中的公共程序或程序集的情况下。例如，T个事务可以很容易变成P个微服务，其中P是程序的数量，而T是由单体遗留应用支持的事务的入口点的数量，如果对入口点的需求不再是每个现有事务的根程序、但是是应用内的任何可调用(例如在CICS下经由链接(LINK))的程序。

是使用容器集合还是仅使用容器来实现给定的可扩展的基于容器的系统可以进一步通知如何创建和定义微服务。例如，在被设计为使用容器集合的可扩展的基于容器的系统中，与未被如此设计的可扩展的基于容器的系统相比，可能更多地将事务解析为微服务并且更加最小化微服务定义向量。

在一些情况下，对所定义的单独微服务的数量的仅有限制可以是单体遗留应用中的单独程序的数量、和/或可扩展的基于容器的系统中可用于容纳微服务映像存储库(355)和/或容器(395)的存储器。

此外，由于可以将给定的容器映像放置在任意数量的活动容器中，因此可扩展的基于容器的系统允许检查并且渐进地实施更新，其中一些容器运行旧版本的微服务或微服务集，而较新的容器运行更新的微服务或微服务集。这允许针对失败来检查并且测试更新，同时保持使用旧版本的微服务或微服务集执行事务的能力(如果需要)。一旦充分验证了更新，运行旧版本微服务的容器可以被自动清理(或根据用户指令被移除)。

另外，由于可以轻松地构建和清理容器，因此，如果事务正在一些容器中运行，则可以构建具有更新的新容器以执行对该事务的新请求，而该事务在没有更新的现有容器中结束，然后当这些容器完成它们刚刚正在运行的事务时，可以自动被清理。因此，例如，如果十个容器C1-C10正在运行事务T1，则当进行对相应MS1的更新时，容器管理系统(385)可以在接收到对事务的新请求时自动创建新容器C11。容器C11包括更新的微服务MS1'的映像。当容器C1完成其正在运行的事务时，没有新的事务分配给容器C1，并且容器C1被清理。具有更新的微服务MS1'的新容器可以被立即构建以替换C1，或者可以在对事务T1的新请求到达时被构建，这取决于容器管理系统(385)为创建和管理容器而应用的参数。

诸如集装箱(Docker)和Kubernetes之类的技术已被设计为以网络(web)规模运行，因此允许工作负载的非常快速的增加，其中，随着越来越多的请求到达，工作负载可以分散在越来越多的增加的x86机器上。这正是诸如Kubernetes之类的编排器的目的。随着在线客户事务越来越多地要求在完成事务之前回答越来越多数量的查询，在线商务的需求将可扩展性问题引入到遗留计算环境到在线市场中的扩展中。通过使得专用于这些客户密集型查询应用的容器能够激增(proliferation)，诸如本文中所述的基于容器的系统的可扩展性在增加这样的遗留计算环境的可扩展性方面特别有利。此外，由于每个容器映像、或者在某些情况下每个容器集合包含一些OS元素和一些仿真器元素，因此可以轻松地将其从一个硬件复制或移动到另一硬件，只要保留不同的计算环境(例如Linux操作系统的使用)即可。

由隔离容器提供的隔离还为服务级别管理提供了更为复杂的方法。可以为每个容器分配不同数量的资源，以比其他容器更好地服务某些微服务(对应于特定遗留事务或由特定遗留事务使用)。本文中所述的可扩展的基于容器的系统可以自动检测和跟踪容器的资源使用情况，并且基于使用情况分配更多或更少的资源。附加地或替选地，容器管理系统可以基于使用情况来缩放专用于特定微服务或微服务集的容器的数量。用户定义的优先级也可以包括在用于资源分配或与事务或微服务相对应的容器数量的计算中。该用户定义的对可用于给定事务的资源的调整在单体遗留应用中是不能的。

在一些变型中，包含微服务或微服务集的容器映像到容器或容器集合中的初始部署可以至少部分地基于当在遗留计算环境中执行单体遗留应用时的事务活动或其仿真。这样的信息可以从诸如图3中所示的遗留仿真器(325)之类的遗留仿真器导出。这样的信息也可以从诸如遗留活动日志(360)之类的遗留活动日志、或诸如活动日志分析器(365)之类的活动日志分析器(图3中未示出)导出。

例如，通常精确地监测当使用单体遗留应用时给定事务的资源消耗。资源数量可以被提取，并且可以在转换为可扩展的基于容器的系统的不同计算环境中的相似资源数量之后被使用，以作为可扩展的基于容器的系统、尤其是容器管理系统(385)的部署定义参数的基础。

此外，通过在分立容器中运行安全性和独立的API或事务服务支持特征，可扩展的基于容器的系统通过在按需的基础上限制对受保护的数据和资源的访问来提高安全性。另外，初始遗留应用的安全性特征被移植到可用的微服务集中，以及可以由微服务定义优化器(345)来具体地识别并且包括在微服务中。

可扩展的基于容器的系统中的容器(例如图1B中所示的通用类型的容器)可以在没有管理程序的情况下操作，从而允许可扩展的基于容器的系统比其他组件(例如管理程序或多个OS副本)还必须在其中操作的诸如虚拟机(诸如图1A中所示的类型)之类的系统更有效地操作。

可以以存储在非暂态介质(例如服务器或服务器集群或一组服务器集群中的计算机存储介质)中的计算机指令来实现根据以上描述的系统。计算机指令可以存储在这样的系统上安装的非易失性固定或可移除存储介质上。在一个实施例中，源代码存储库(310)、事务状态定义存储库(340)和动态定义存储库(440)存储在公共存储库系统中，而二进制文件存储库(330)、事务映像存储库(360)、补充组件存储库(450)和容器映像存储库(370)存储在公共二进制映像存储库系统上。在另一实施例中，容器映像存储库(370)被在单独的平台中实例化。根据系统的规模和需求，可以使用不同数量的存储库系统，并且源存储库和二进制文件存储库可以共享或分离为不同的存储库系统。

指令和/或数据可以以其他通常的方式存储。例如，二进制映像可以按标准文件系统的常规分层结构存储在盘上。应用数据可以存储在常规文件和/或结构化(关系、分层等)数据库中。

根据本发明的另一方面，提供了一种用于产生和/或维护执行单体遗留应用的操作的可扩展的基于容器的系统的方法。图6是这样的方法的某些步骤的流程图。然而，上述结合可扩展的基于容器的系统描述的任何功能也可以包括在该方法中。此外，尽管该方法不限于与任何特定系统一起使用，该方法也可以在如上所述的可扩展的基于容器的系统中实现。

方法600包括步骤605，在步骤605中，解析单体遗留应用并且自动对程序文件进行分割。在步骤610中，识别事务根程序。在可能在步骤610之前或之后进行的步骤615中，识别程序相互依赖性。对于多个事务中的不同事务，步骤610和615可以同时进行。

接下来，在步骤620中，识别多个事务调用树。优选地，这多个事务调用树代表单体遗留应用中可能的所有事务或者单体遗留应用的所定义的子部分中可能的所有事务。

在步骤625中，使用多个事务调用树来创建多个事务定义向量，这些事务定义向量被存储在例如事务状态定义存储库中。

在步骤650中，活动日志分析器确定哪些程序在单体遗留应用中可能的所有事务中、或者在单体遗留应用的所定义的子部分中可能的所有事务中实际使用。如果仅使用单体遗留应用的所定义的子部分，则其通常将会与步骤625的子部分相同，包括步骤625的子部分的整体，或者与步骤625的子部分至少部分地重叠。活动日志分析器可以使用单体遗留应用在其原始环境中运行时的遗留活动日志，以确定在事务中实际使用哪些程序。活动日志分析器可以替选地使用仿真器来运行单体遗留应用，以便确定在事务中实际使用哪些程序。在一些方法中，相同或不同的活动日志分析器可以使用遗留活动日志和仿真器两者来确定在事务中实际使用哪些程序。基于结果，创建动态定义存储库。动态定义存储库包含用于多个事务中的每个事务的程序的日志。在一些实施例中，该日志可以包括多个动态定义向量。动态定义存储库可以相对于事务状态定义存储库来定义，或者可以被独立地创建。

在步骤630中，通过微服务定义优化器将来自步骤625的多个事务定义向量与来自步骤650的动态定义存储库进行比较，并且从每个事务定义向量中移除未在事务中实际使用的程序，以创建与多个事务相对应的多个微服务定义向量。

在步骤635中，微服务定义优化器确定是否将进行进一步的优化。如果将进行进一步的优化，则在步骤640中，进一步优化多个微服务定义向量中的至少一个，然后在步骤645中将多个微服务定义向量中的至少一个提供给微服务映像构建器。如果对于多个微服务定义向量中的任何一个都不会进行进一步的优化，则在步骤645中，将微服务定义向量提供给微服务映像构建器。无论是否对于任何微服务定义向量进行优化，在步骤645中，将从多个事务向量导出的多个微服务定义向量提供给微服务映像构建器。

在步骤655中，微服务映像构建器获取多个微服务定义向量中的每个微服务定义向量，并且从二进制文件存储库中定位被编译为在遗留计算环境中运行的对应的经编译的源代码，以在微服务映像存储库中形成微服务映像。微服务映像还可以包含由其包含的程序使用的其他信息和工件。在步骤655完成之后，微服务映像存储库优选地包含与单体遗留应用或其所定义的子部分中可能的多个事务中的每个事务相对应的多个微服务映像。

在步骤660中，从遗留仿真器的元素的单独映像创建补充组件存储库。单独的元素对应于遗留仿真器的不同功能。与遗留仿真器相关联的OS元素的映像也可以存储在补充组件存储库中。

在步骤665中，容器构建器使用来自微服务映像存储库的映像以及来自用来执行一个或多个微服务的遗留仿真器的仿真器元素的补充组件存储库的映像，为每个微服务或微服务集形成容器映像。来自补充组件存储库的其他映像(例如与遗留仿真器的元素相关联的OS元素的映像)也可以放置在容器映像中。可以通过如下方式来选择仿真器元素：在微服务映像的二进制文件中识别对函数或程序的调用的签名，并且包括能够执行被调用函数或与被调用程序一起操作的仿真器元素。在某些实施例中，可以改变每个容器映像中的至少一个微服务映像中的至少一个二进制文件，以形成遗留仿真器优化的微服务映像，其中利用在遗留仿真器中调用相同的一个或多个函数的指令来替换微服务二进制映像中的调用签名。

在步骤670中，将多个容器映像存储在容器映像存储库中。

在步骤675中，容器管理系统将容器映像存储库中的至少一个容器映像存储在容器中。来自活动日志分析器的信息以及微服务映像本身可以由容器管理系统使用。优选地，每个容器映像在至少一个容器中被激活。可以为每个容器映像指定资源分配，该资源分配反映在分配给包含该容器映像的一个或多个容器的资源中。

在步骤680中，在容器管理系统中的容器中执行至少一个微服务。

本文中提供了许多示例。在不偏离本发明的精神的情况下，可以修改这些示例。例如，各种示例和实施例中的任何一个可以彼此组合，除非它们明显地相互排斥。本文中描述的示例和实施例作为示例提供，并且也可以使用其他组件、例程或模块。