SICS 软件密集型信息物理系统 https://doi.org/10.1007/s00450‐019‐00414‐9

特别专题论文

单体Web应用程序向模型驱动云原生迁移的需求

罗宾·利希滕塔勒1 ·迈克·普雷希特尔1 ·克里斯托夫·施维尔1 ·托比亚斯·施瓦茨1 ·帕斯卡尔·塞尚1 ·古伊多·维尔茨1
施普林格·自然集团德国有限公司，2019

随着云原生应用的出现，如何将现有的、通常是单体式的应用迁移到这一新范式成为了一个问题。主要的迁移挑战在于将应用分解为细粒度的组件以及引入云计算范式。对于复杂的应用系统，迁移过程尤为困难。一种结构化且有工具支持的方法将有助于迁移过程，因此本文提出了一种基于模型驱动工程的迁移方法。作为基础，本文一方面从文献中，另一方面从一个迁移案例研究中，推导并提出了针对该方法的需求。这些需求不仅针对必要的模型，同时也考虑了整体迁移方法。本文阐明了实现模型驱动的云原生迁移方法所需的基本条件，并讨论了尚存的挑战。

关键词 云原生 ·模型驱动 ·迁移 ·微服务 ·函数即服务 ·分解

1 引言

云原生是当今构建基于Web的应用程序的主要范式[1]。许多新应用从一开始就直接构建为云原生应用（CNA），但也有必要将现有应用迁移到CNA架构，以充分利用云原生应用的优势。然而，此类迁移具有挑战性，需要熟练的软件工程师参与。需要迁移的现有应用通常具有单体架构特征，经过较长时间演化，已达到较高的复杂度水平。

云原生应用的一个关键特征是其细粒度架构，这意味着应用程序由可独立管理和演进的各个组件构成。因此，将现有的基于Web的应用程序迁移到云原生应用的关键挑战在于，如何将复杂的单体应用拆分为更小的、符合云原生范式的组件。在文献中，迁移到云原生应用这一主题已被认为具有重要意义（[1–3]）。已实现迁移的个别报告作为案例研究已有提供（[4–6]）。但目前仍然缺乏结构化且广泛适用的方法来促进迁移过程。然而，此类方法对于支持参与迁移项目的软件工程师、降低迁移工作量以及提高对迁移成功性和收益的信心而言是必不可少的。

为了实现一种结构化且受工具支持的向云原生应用（CNA）迁移的方法，即下文所述的云原生迁移，模型驱动工程已被提出为一种有前景的技术，可用于应对复杂性并提供通用适用性[2,7]。因此，本文旨在通过分析包含迁移方法和成功迁移案例的现有文献，并结合来自一个作为案例研究的迁移项目中的自身经验，来推导出此类模型驱动方法的必要需求。所探讨的指导性研究问题是：

– 模型驱动的云原生迁移方法在何种抽象层次上需要哪些信息？
– 为了充分受益于云原生范式，模型驱动方法中需要包含哪些方面？

为了回答这些研究问题，本文结构如下：第2节介绍了本文的基础，并提供了推导需求所需的定义。第3节概述了本文所采用的双重方法论，第4节给出了针对模型驱动迁移方法的需求。接着在第5节对结果进行了讨论。相关工作在第6节中介绍，最后通过第7节的结论结束全文。

2 奋向云原生迁移

2.1 云原生

尽管“云原生”这一术语被广泛使用且已有普遍共识，但由于其涵盖的主题非常广泛，因此需要一个明确的定义，以便为后续工作奠定基础。本文采用Kratzke 和 Quint [8]的定义：“云原生应用（CNA）是由（微）服务[..]构成的分布式、弹性且水平可扩展的系统。该应用及其每一个自包含的部署单元均按照以云为中心的设计模式进行设计，并运行在自助式弹性平台上。”

根据他们的定义，多种软件工程实践的结合促成了云原生应用（CNA）的出现，而这些实践也构成了云原生应用的特性。其中最为突出的是云计算整体以及微服务架构风格。此外，基础设施的软件化和弹性平台的使用也是云原生应用的重要特性。微服务架构风格[9]体现了从单体式应用经由面向服务架构向细粒度软件架构发展的趋势。在这些架构中，应用程序通过独立组件的组合构建而成。云计算所提供的能力进一步加强了这一趋势，因为它通过抽象操作及其他相关关注点降低了复杂性，从而实现了细粒度架构的高效开发与操作。

最近一个典型的云原生应用（CNA）示例是函数即服务范式（FaaS）[10],，在该范式中，开发人员可以专注于构成独立部署单元的各个函数。这些函数运行在弹性的 FaaS 平台之上，该平台抽象了运维相关的问题。此外，云原生应用利用云平台提供的服务，而非自行实现功能，以进一步降低复杂性。这对应于以云为中心的设计模式和示例包括用于身份验证、缓存或日志记录的服务。云原生应用的特性是推导结构化迁移方法需求的基础。本文中最重要的特性是细粒度架构和云计算范式。

2.2 云迁移

随着持续的创新和新技术的出现，现有应用的迁移始终是一个重要话题，以利用这些创新并保持竞争力。自首个云平台出现以来，云迁移就已成为研究课题。Jamshidi 等人综述了云迁移的相关研究，并已描述了不同类型的迁移场景[11]。一种可能的方式是将部署在本地环境中的现有应用迁移到 IaaS 服务的虚拟机中（移移整个应用栈[11]）。虽然这可以减轻应用开发者管理基础设施的负担，但无法获得云计算提供的其他优势。该应用只能作为一个整体进行扩缩容，启动虚拟机耗时相对较长，应用的不同部分无法独立演进，且应用中某一部分的故障可能导致整个应用失效。

相比之下，Jamshidi 等人所描述的部分迁移和云化类型更具优势，即对系统进行改造以充分利用云平台提供的能力，并例如用云平台的服务替换已有功能。向云原生应用的迁移即对应于这些类型。这类迁移需要投入更多工作量，且随着现有应用复杂性的增加，所需 effort 也随之增加。

因此，将现有应用迁移到云原生应用通常很困难，需要有结构化的方法来支持迁移过程。弗朗西斯科等人研究了软件行业在迁移到微服务架构时所采用的方法及面临的挑战[2]。由于微服务架构风格是云原生应用的关键特征，他们的见解也可应用于云原生应用的迁移。弗朗西斯科等人使用了卡兹曼等人最初提出的马蹄形模型。该模型如图1所示，用于描述适应于云原生应用的迁移过程。

关键阶段是架构转换阶段，在云原生应用的情况下，系统被拆分为更小的组件，并引入云计算范式。然而，逆向工程和正向工程阶段同样重要，因为它们为实现转换提供了基础，并支持新架构的实际实现。根据弗朗西斯科等人调查的迁移项目，“半正式模型和领域特定模型并未被广泛使用”[2]。此外，迁移过程本身并不是一个明确的项目，而是作为“日常工作的一部分”逐步完成的[2]。这表明在向云原生应用迁移的过程中缺乏结构化和形式化方法。

另一个需要考虑的方面是，根据弗朗西斯科等人调查的项目，几乎总是在迁移过程中添加新功能[2]。虽然通常认为迁移应保持功能不变，但在实践中这似乎不切实际。Taibi等人在一项调查[3]中也探讨了实践中所使用的迁移过程和方法。然而，Taibi等人描述的推导出的迁移过程仍处于高度抽象的层面，对于如何对现有系统进行架构转换以实现云原生应用提供了很少的支持。如何将现有系统拆分为更小的组件的问题已被报告为主要挑战[3]。

2.3 模型驱动方法

模型驱动工程（MDE）作为一个概念有着悠久的历史。其基础由Kent提出[13]，他主张在软件开发中将模型作为一等工件。平台特定模型（PSM）用于表示特定平台的具体实现。平台无关模型（PIM）用于描述与技术细节无关的系统，以专注于最重要的方面。可以通过将PSM转换为PIM，将现有系统表示为更高层次的抽象，从而简化系统的进一步演化。同时，也可以将PIM转换为PSM，以便从该模型生成特定平台的具体实现。PSM、PIM以及系统实际实现之间的关系如图2所示。

主要优势在于，系统可以在更高层次的抽象上进行开发和维护，并且独立于技术细节。然而，为了充分利用模型驱动工程（MDE），所使用的模型需要针对特定用例具有准确性，并且应提供支持模型生成、模型转换和代码生成的工具。以弥补在维护模型的同时维护代码所带来的额外工作量。这些模型需要捕获有关系统的详细信息，包括其功能和行为，以支持代码生成。模型驱动工程（MDE）似乎是一种合适的方法，可为将现有系统迁移到云原生应用（CNA）提供形式化和结构化支持。弗朗西斯科等人指出，他们希望将模型驱动工程方法用于微服务迁移作为未来工作[2]。事实上，MDE的基本机制是从现有系统生成平台特定模型（PSM），将其转换为平台无关模型（PIM），通过变换PIM来优化架构，并最终再次将PIM转换为PSM，这一过程与弗朗西斯科等人提出的马蹄形模型高度吻合。然而，将MDE应用于云原生迁移的基础是拥有合适的模型，这些模型能够准确支持将现有系统拆分为更细粒度的架构，并引入云计算范式。因此，本文的目标是推导出在云原生迁移过程中所使用模型的必要需求。

3 方法论

为了推导模型驱动的云原生迁移方法的需求，我们采用双重方法论。一方面，我们分析现有文献，考虑云原生迁移的项目或方法。文献分析的具体步骤在第3.1节中描述。另一方面，我们进行了一次云原生迁移，并将其作为案例研究，以验证文献中的需求并进一步推导新的需求。案例研究的一般信息见第3.2节。

3.1 文献检索

为了找到可供分析的文献，我们根据Brereton等人[14]的建议进行了文献检索。在检索过程中，我们使用了以下关键词：迁移、分解、微服务、云原生、模型驱动、基于模型。我们通过Google Scholar、IEEE Xplore和 SemanticScholar使用这些关键词来识别与该主题相关的一组初始文献。从该集合中，我们筛选出符合以下条件的文献：

– 明确描述了一种模型驱动的云迁移方法，
– 描述了一个向微服务架构或云原生架构的迁移项目，
– 或描述了一种用于云原生迁移的架构转换方法。

最后，我们仅选择了那些对迁移项目或方法进行了足够详细描述的文献，以便推导出模型驱动的云原生迁移的需求。这种详细程度对于现有应用和转换后的应用都是必要的。用于分析的最终文献如表1所示。

3.2 案例研究

作为一项案例研究，我们将一个单体应用迁移为基于 FaaS范式的无服务器应用1。我们选择了FaaS范式，因为它基于细粒度的组件，即函数，并且可以被视为云计算中的最新趋势[10]。需要注意的是，该项目的目标并不是在性能、成本或可维护性方面改进现有应用程序，而是探索将现有单体应用迁移为云原生应用的迁移过程。对于该单体应用，我们选用了Spring Petclinic示例应用的REST版本2。尽管该应用相对简单，但它具备基于Web的应用程序的典型特性，因此适合作为一个贴近现实但又易于理解的示例。该 REST版本仅包含后端功能，在第一轮迭代中，我们保留了原有的前端。

我们使用了OpenFaaS3作为平台，因为它是开源的，并且支持不依赖于云提供商的本地开发。我们也可以选择例如AWS Lambda4，但这将导致类似的结果，因为底层的FaaS范式是相同的。然而，OpenFaaS与AWS Lambda之间存在技术差异，因此潜在的转换并非没有难度。示例应用程序还包含一个 SQL数据库，在第一轮迭代中我们直接采用了该数据库。该项目的目标是使用OpenFaaS函数重新实现应用逻辑，并在转换前后对应用程序进行建模，以评估采用模型驱动方法实现此目标所需的内容。这些需求随后可以与从文献分析中推导出的需求进行比较。

4 结果

接下来，将展示基于双重方法论得出的需求。这些需求按照第 2.3 节中提出的 MDE 方法进行组织。图 3 提供了总体概览，其中整合了文献分析和案例研究的成果。

4.1 从文献中推导出的需求

4.1.1 现有系统的平台特定模型（PSM）需求

迁移过程中的第一步是分析并建模现有应用。应通过一个平台特定模型（PSM）来表示现有应用，如图 3 左下角所示。PSM 可能由多个部分组成。其核心是作为源代码的应用逻辑。由于在转换过程中需要将现有的单体应用拆分，因此有必要在足够高的抽象层次上对应用进行表示。对于大多数编程语言而言，存在多个可选的抽象层次。以 Java 为例，包（packages）是最高层次的抽象，而单个语句（individual statements）则是最低层次的抽象。将系统拆分为微服务的相关方法通常建议采用类级别（[19,21]）。然而，Spillner 和 Dorodko 的方法[20],要求在方法级别进行分析，因为他们的方法旨在生成符合 FaaS 范式的云函数。Frey 和 Hasselbring[15]以及 Menychtas 等人[16],的方法则使用知识发现元模型（KDM）[22]，该模型具备在单个语句级别分析应用的潜力。因此，类级别的分析应被视为最低要求，而更细粒度的抽象层次能够实现对组件更为精确的划分。

除了应用程序的组件外，它们之间的关系对于确定哪些元素属于同一组以及在何处将应用程序拆分为更细粒度的组件也非常重要。这些关系可以通过静态代码分析生成的依赖图来展示，这是一种简单的方法，但仅由莱夫科维茨等人[17]完成。尽管依赖图可以显示元素之间的关系，但很难衡量这些关系的强度。因此，Nakazawa 等人[21]提出对系统进行运行时分析，以生成调用上下文树，从而用于描述组件之间关系的强度。Mazlami 等人[19]使用元数据来确定类之间关系的强度。具体而言，他们利用应用程序开发所使用的版本控制系统中的元数据，例如哪些类被一起修改或由相同的开发人员处理。Gysel 等人[18]也使用关于应用程序的元数据，他们考虑系统所有可用的文档，例如非正式的架构模型或 ERM 图。然而，他们的方法与其他方法不同，因为不需要以类或方法的形式表示应用程序。他们从元数据中导出一个基于领域驱动设计（DDD）概念的平台无关模型。Gysel 等人将应用程序建模为一组数据、操作和工件元素，这些元素被总结为纳米实体。然后，这些纳米实体基于所谓的耦合准则进行连接，从而推导出形成服务的纳米实体组。此类元数据通常可以丰富关于现有应用程序的信息，但也需要更多努力来获取。

作为PSM的最后一个关键因素，是应用程序所使用的存储组件或数据库。令人惊讶的是，只有莱夫科维茨等人[17]在其拆分应用程序的方法中包含了数据库，更具体地说是数据库模式。然而，它是应用程序的重要组成部分，而且由于微服务架构推荐采用分布式数据治理方式，因此在拆分应用程序时也应考虑对数据库进行拆分。

总结现有应用程序平台特定模型（PSM）的需求，我们可以说，该应用应在足够抽象的层级上进行表示，以派生出细粒度的组件。类级别是最低要求，但更细粒度的表示更为理想。在考虑元素之间的关系时，应能够标记这些关系的强度。数据库也应包含在PSM中。元数据有助于丰富PSM，但获取元数据也需要额外的工作。

4.1.2 平台无关模型的需求

然后应将现有应用的平台特定模型映射到平台无关模型。该平台无关模型应捕获各个组件内部元素及其关系的加权图概念，如图3左上角所示。有必要将平台特定模型中的信息抽象并映射为有用的平台无关模型。因此，本文提出了一种平台无关模型的基本建模方法作为示例性解决方案。该方法结合了以下方面的见解：通过捕捉共性并包含被认为有用的特定信息，对相关文献进行分析。组件是建模方法的基本元素，可以是计算组件或存储组件。这种区分非常重要，因为存储组件本质上是有状态的，无法直接利用云环境的弹性伸缩能力。这一点与莱夫科维茨等人[17]的观点一致，他们区分了业务功能和数据库表；Gysel 等人[18]区分了操作和数据；Bucchiarone 等人[5]在其新架构表示中将服务和数据库分别可视化。为了表示应用程序在类和方法级别的结构，正如第 4.1.1 节所述（基于 [19–21]），计算组件具有灵活性，可用于表示类或方法。例如，若要表达哪些方法属于同一个类，可以使用组件组，而组件组本身也可被视为组件。因此，单体应用可被表示为一个由子组件组成的单一组件。然后根据组件之间的集成和通信方式将其连接起来。该建模方法应区分同步通信和异步通信，以尽可能推动向异步通信转变。在云原生应用中，通过消息传递实现的异步通信更受青睐，因为它能确保组件间的松耦合[5]，从而提高可扩展性和故障恢复能力。最后，组件可通过额外的特性进行描述。有状态性已在计算组件与存储组件的区分中讨论过。虽然存储组件始终是有状态的，但计算组件通常倾向于无状态，但也可能是有状态的。有必要明确哪些组件是无状态的，因而适合弹性伸缩（例如在函数即服务中）[20]，以及哪些组件是有状态的，以便识别可能的改进机会。此外，一致性关系对于决定哪些组件应组合在一起、哪些可以分离至关重要。Gysel 等人[18]也将一致性作为拆分应用程序的准则，因为处理具有更强一致性要求的数据的组件应被归为一组，而较弱的一致性要求则更有利于组件的分解。此外，如 Gysel 等人所采用的，基于领域驱动设计（DDD）的特性可支持基于领域知识的分解。还应考虑安全性方面，例如与某个组件通信是否需要身份验证，或哪些组件必须位于同一虚拟网络中[6]。最后，平台无关模型（PIM）应支持聚类或映射算法的应用。这些算法利用组件类型、组件间的连接关系以及组件特性等信息，对应用程序进行拆分，并在适用时引入云计算范式。特别是在分解方面，[17–19],或[21]的方法应因此可以推广，并基于所讨论的平台无关模型建模方法。

对于云原生应用（CNA）的平台无关模型（PIM），采用了相同的建议建模方法，但需要进行扩展。组件作为子组件集合的概念变得更加重要，因为应用程序由细粒度的组件构成。在此组件层次结构中代表最高层级的组件也定义了部署单元。与单体架构不同，将会有多个部署而非单一部署[5]。此外，新增了一种服务组件类型。这是必要的，因为云应用越来越多地依赖于服务而非自实现功能。服务是具有明确定义接口的现成组件，例如认证服务、消息队列、媒体处理服务或机器学习服务。通过使用这些服务，可以降低提供此类功能的复杂性。Iosifescu‐Enescu 等人[6] 讨论了其转换后应用的相关服务，包括可靠消息排队、缓存以及安全相关服务，如虚拟云网络和托管防火墙。在云原生迁移过程中，组件可以被服务替代。因此，还增加了另一个重要特性：描述一个组件是自管理还是托管的，例如作为来自云提供商的服务被消费。Iosifescu‐Enescu 等人[6] 的迁移项目通过将功能从自管理组件转移到云提供商的服务来说明这一点。例如，他们提到了从独立的 PostgreSQL 服务器迁移到 PostgreSQL 数据库即服务（DBaaS）。在 Bucchiarone 等人[5], 描述的迁移项目中，向迁移后的应用引入了基于开源项目的缓存和日志记录服务。例如，使用 ElasticSearch5 和 Kibana6 进行日志记录，这可以在所提议的 PIM 中表示为一个自管理的服务组件。最后，组件之间同步通信与异步通信的区别变得更加重要，在迁移过程中应考虑转向异步通信，以促进组件之间的松耦合[5]。

4.1.3 云原生系统的平台特定模型需求

如图 3 概览的最后部分所示，提出了云原生应用的平台特定模型的需求。在平台特定模型中，必须具体决定系统应部署在哪里，例如选择哪个云提供商或私有云。在不断发展的云服务格局中，应用程序的部署有多种选项，尽管存在不同的云提供商共享许多服务，如 Iosifescu‐Enescu 等人[6], 所列出的，但其差异仍需考虑。通常需要决定将多大程度的操作职责交由提供商承担。现有的服务模式包括 IaaS、PaaS 和 SaaS[23]，以及新兴的 FaaS 模式。此外，还有可作为服务使用的容器编排技术。特别是 Kubernetes 越来越多地被选为运行 CNAs 的主要技术之一[24]。PIM 中的信息较为抽象，例如关于组件的可扩展性要求。因此，PSM 应包含来自云提供商的可用技术选项，正如 Menychtas 等人[16], 所提到的，以实现向 PSM 中具体元素的恰当转换。此外，自动化实践（如持续集成和部署）也应在 PSM 中得到体现，因为处理包含大量独立组件的细粒度架构只有通过此类实践才可行，正如 Bucchiarone 等人[5]所讨论的。最后需要注意的是，PSM 仍然是一个模型，源代码以及基础设施描述（例如用于 Kubernetes 的 Pod 清单）应从 PSM 生成。

4.2 来自案例研究的需求

尽管第4.1节和图3中提出的需求源自文献，但案例研究的目标是验证这些需求，并可能根据迁移过程的实际经验补充其他需求。需要注意的是，在本案例研究中，我们手动转换了应用，而未采用特定的分解方法。因此，无需为现有应用建立完整的平台特定模型。尽管如此，我们仍为现有应用创建了基本的UML图，以探索其在迁移过程中的实用性，并加深对现有应用的理解。图4展示了现有应用的一个简化模型，重点说明了与宠物实体相关的功能，该实体作为应用中的一个示例实体。

SICS 软件密集型信息物理系统 https://doi.org/10.1007/s00450‐019‐00414‐9

特别专题论文

单体Web应用程序向模型驱动云原生迁移的需求

可以看出，该应用包含一系列实体，这些实体显示在图4左下角的模型包中。基本上，每个实体都有一个提供CRUD操作的REST控制器，以及一个连接到数据库的仓库。控制器使用一个服务类，该服务类将所有实体的功能集中在一个类中，并在控制器与仓库之间进行协调。由此可以明显看出，为了实现细粒度的拆分，有必要在方法级别上表示现有应用。因此，尽管UML图的基本粒度位于类级别，我们仍连接了类的方法。

对于实体类而言，按其方法级别进行表示是没有意义的，因为它们是作为完整对象使用的。因此，系统在类和方法级别上采用混合表示是平台特定模型的要求。

UML图还为我们提供了类和方法的基本依赖图。该依赖图突显了应用内部的紧耦合。然而，对于有意义的分解，仅知道一个组件依赖于另一个组件是不够的。还需要有关关系强度的信息。根据我们的手动方法，可以通过理解组件的名称和功能来提取其语义信息。但对于更自动化的模型驱动方法，则需要提取更多信息，例如在现有应用的PSM需求中描述的元数据。这一问题也存在于使用Spring框架的过程中。尽管 Spring通过使用注解简化了应用开发——这些注解由 Spring解释以提供功能，但组件之间的关系可能隐藏在这些注解背后，因此需要额外的工作来提取框架特定信息。

另一个明显的问题是，需要将数据库纳入现有应用的平台特定模型和平台独立模型中。仅仅关注应用逻辑是不够的拆分应用程序时需要考虑的部件，因为组件也可能通过数据库紧密耦合。在案例研究中，只有当函数中同时复制了其他被引用实体的模型和仓库类时，才能实现每个实体对应一个OpenFaaS函数的方式拆分应用。为了将应用程序拆分为每个函数仅处理一个实体的形式，还必须修改数据库。这显然会影响一致性考量，因此验证了在PIM中描述一致性要求的需求。例如，一只宠物属于一个主人，因此依赖于该主人的存在。如果处理宠物和主人的逻辑被分离，当删除一个主人时，问题就出现了：如何确保相关的宠物也被删除，是否允许出现不一致视图（即没有主人的宠物），还是需要强一致性。必须能够反映哪些组件需要被分组并部署在同一个聚合组件内以确保一致性，或者需要采取哪些额外措施来确保跨多个组件至少达到最终一致性。

最后，用户认证在转换后的应用中成为一个挑战。在单体应用中，用户认证以及配置调用特定操作所需的用户角色是通过Spring的注解实现并全局可用的。在转换后的应用中，我们使用了额外的认证功能，因为 OpenFaaS 对此提供的支持较少。在云原生应用中，身份验证理想情况下由明确的身份验证服务以及位于客户端和实际应用服务之间的网关组件来处理。在平台无关模型中，这可以通过进一步的组件特性来表示，这些特性描述了组件的安全性和认证要求。

5 讨论

基于文献和一项案例研究，我们得出了模型驱动的云原生迁移方法的需求，总结如图3所示。目前该方法仍具有概念性，所提出的需求在其实际实现中需要进一步评估。对于实际实现，还存在其他方面和挑战，将在下文进行讨论。

5.1 迁移前进行可行性研究的重要性

Jamshidi 等人开发了一个全面的云迁移框架[11]，其主要阶段包括迁移规划、迁移执行和迁移评估。本文讨论的模型驱动方法属于迁移执行阶段，即实际进行系统迁移的阶段。然而，迁移规划阶段对于一个成功的迁移项目至关重要，因为在该阶段会进行评估和可行性研究，以确定是否需要迁移以及迁移的目标是什么。所提出的模型驱动的云原生迁移方法可能并不适用于所有类型的应用程序。因此，在应用该方法之前，应充分分析和评估迁移的可行性。分析阶段的结果和决策对于架构转换阶段以及将精化后的平台无关模型转换为特定平台特定模型也具有重要价值，有助于合理决策应用程序应如何拆分和部署。

5.2 技术异构性

考虑到现有应用的另一个挑战是其巨大的技术异构性。其中编程语言是核心因素，但即使在同一编程语言内部也存在差异。正如我们在案例研究中所经历的，样本应用虽然使用Java编写，但与其他Java实现并不相同，因为它基于Spring框架，而该框架引入了其自身的特定机制。因此，需要针对不同的编程语言和框架开发不同的平台特定模型（PSM），以使该方法具有通用适用性，并通过工具提供支持。然而，该方法的仅在平台特定模型（PSM）中处理技术异构性也是模型驱动方法的一个优势。如果平台无关模型与实际实现无关，即使在技术的持续演进过程中，它们也能保持稳定。

如果通过为现有技术创建多个PSM来应对技术异构性，那么所提出的方法是否适用于所有应用仍有待探讨。单体应用往往紧密集成。我们已经提出，有必要在方法层面分析现有系统。但可能存在一些系统，其单个方法本身也很复杂，并且集成了多种功能，理想情况下应将其拆分为不同的组件。在这种情况下，若不将应用从头重写为云原生应用，则在应用所提出的方法之前，可能需要先对现有系统进行重构。

5.3 数据库的重要性

从我们的角度来看，目前尚未得到充分重视的一个方面是数据库的纳入。这也是弗朗西斯科等人调查的结果：“令人惊讶的是，超过一半的参与者报告称，在迁移过程中现有数据并未被迁移”[2]。为了充分获得云原生应用的优势，也需要对数据库进行相应的考虑和拆分，类似于应用逻辑组件的拆分方式。我们在案例研究中也遇到了这一问题。由于在第一次迭代中我们仅将应用逻辑拆分为函数，而数据库保持不变，因此不得不复制代码以维持与数据库的通信方式不变。这导致函数之间的独立性不如预期。此外，由于所有函数都使用同一个数据库，我们还遇到了过多数据库连接打开的问题。因此，系统的耦合不仅存在于应用逻辑中，也存在于数据库中；要实现全面的迁移，数据库也必须得到妥善处理。当数据被分离时，有必要考虑整个应用所需的事务一致性级别。因此，一致性方面的因素也应包含在所提出方法的平台无关模型中。

5.4 用户界面的重要性

另一个迄今为止尚未涉及的方面是用户界面（UI）。应用的耦合不仅体现在应用逻辑中，也体现在数据库中，这一观点同样可以延伸到用户界面。对于基于Web和移动应用而言，通常采用服务器端和客户端通过REST进行通信的分离方式。基于这种分离，可以利用服务器端的独立性，将服务器端迁移到云原生应用，而保持客户端不变。然而，正如我们在案例研究中所经历的那样，如果客户端期望通过单个请求获取集成的数据，则可能会导致问题。当应用程序在服务器端通过将实体相互解耦而拆分时，服务器端不再能够提供不同实体的聚合数据。因此，客户端需要针对不同的实体发起多个请求，而不是一个请求。此外，客户端本身也需要进行迁移。在本文分析的文献中，用户界面很少被提及，因此在所提出的模型驱动方法中并未体现。然而，用户界面不应被忽视，最终可能有必要通过显式的组件在建模中将其包含进来。

5.5 半自动化转换

所提出方法的关键阶段是架构转换阶段，在此阶段中对平台无关模型（PIM）进行转换。该阶段应将迁移项目预期实现的收益落实到架构中。然而，可能的解决方案范围广泛，仅基于技术因素难以做出决策，必须结合应用特定领域内的业务知识，而这些知识只能由人类专家提供。因此，我们认为该阶段只能实现半自动化，理想的方案是由人类专家在工具支持下完成架构转换。该工具应为预期的云原生应用（CNA）提供一个框架，包含系统约束条件，同时保留足够的灵活性，以设计出适合迁移的架构方案。一种可能的扩展是引入常见的云原生应用蓝图或模式，以指导架构转换阶段的工作。

对于从云原生系统的平台特定模型（PSM）生成代码的最后一步，一种合理的方法是仅生成预期系统的骨架。实际的实现仍由软件工程师完成，以确保功能正确，并为最终的完善工作保留灵活性。

6 相关工作

本文的主题涉及多个研究领域，如云原生应用、微服务、云迁移和模型驱动工程。一项具有相似目标的 noteworthy 工作是 ARTIST 项目[16]。它提供了一套完整且由工具支持的将传统系统迁移到云的方法论。Jamshidi 等人[11]所描述的所有阶段均被支持，即迁移规划、迁移执行和迁移评估。基本上，ARTIST 项目的方法论和工具涵盖了如图2所示的相同流程，但其重点是当时云计算的发展状态。此外，由于缺乏对工具支持7以及方法论本身，应用程序转换步骤并未像本文所提出的那样重点关注云原生应用。尤其是将应用程序分解为细粒度组件并非首要关注点。因此，本文提出的方法与ARTIST项目有许多共同之处，但在一些关键特性上存在差异。尽管如此，ARTIST项目期间开发的一些工具支持可能可被复用并适应该方法。

拉德马赫等人[25]提出了一种基于领域驱动设计（DDD）的微服务模型驱动工程方法。他们使用领域驱动设计（DDD）来捕获应用程序的平台无关功能，并开发了可用于建模应用程序并生成相应代码的 UML元模型8。然而，他们的重点在于新应用的开发，而非迁移。因此，将他们的方法与本文的方法在已迁移系统的平台无关模型（PIM）上进行结合是可能的，但他们不支持架构转换阶段。

弗里茨施等人[26]综述了明确关注架构转换阶段的相关工作。弗里茨施等人回顾了将现有应用分解为微服务的方法。这种分解是架构转换阶段的关键部分。因此，所综述的方法具有高度相关性，其中一些方法也被纳入本文的文献分析中（[17–19]）。然而，与这些已综述的方法不同，本文提出的方法明确聚焦于云原生应用，从而在转换阶段引入了云计算范式。

最后，还有一些方法旨在优化已基于微服务的现有应用程序的架构。与生成应用程序平台特定模型（PSM）的阶段类似，格兰切利等人[27]和迈尔和魏因赖希[28]提出了提取微服务架构的方法。格兰切利等人使用来自源代码和应用程序日志的静态信息，而迈尔和魏因赖希认为只有在运行时进行分析才能为全面的架构分析提供足够的信息。如果采用模型驱动方法，并且模型能够与实现保持同步，则这可能并非必要。然而，这些方法有助于验证转换后的应用程序是否实现了迁移所追求的目标。

7 结论

在文献分析和案例研究的基础上，我们提出了模型驱动云原生迁移的需求。它们按迁移的不同阶段以及各阶段所需的模型进行分组。针对第1节中提出的研究问题，这些需求提供了具体的答案。通过组件类型及其关联关系来捕获所需的信息和抽象层次，而从云原生范式中受益的各个方面则体现在组件类型及其特性中。

本文的贡献在于提出了相关需求以及所提出方法的概述。这些需求可用于推进云原生迁移的模型驱动研究。特别是，可根据这些需求开发该方法中平台无关模型和平台特定模型（PSM）的元模型。基于这些元模型，需要相应的工具支持来从现有应用中提取具体模型，并从模型生成代码。

此外，可以使用模型来表达典型的迁移模式和规则，以指导迁移过程。通过提供典型模式，可以支持所讨论的半自动架构转换。这一点尤为重要，因为云原生应用的可能解决方案空间很大。因此，这为该主题的未来工作奠定了基础。但第5节中讨论的挑战需要注意并加以应对。这些挑战在具体的迁移项目之间重要性有所不同，但它们源于云原生应用的一般特性，因此对于云原生应用的普遍研究具有重要意义。总体而言，云原生是基于Web的应用程序的首选范式，为其开发提供结构化支持有助于开发人员高效且有效地实现这些应用。