微服务设计与识别的过程模型

摘要

微服务已成为开发现代应用程序的一种架构风格。在理论和实践中，一个主要挑战是确定微服务的适当粒度。为了实现一个一致且易于理解的过程，本文提出了一种用于微服务的设计与识别的过程模型。该过程模型应支持微服务的开发以及合适识别方法的选择。该过程模型是基于文献中现有的识别方法通过演绎推导得出的。这有助于将这些方法分类到所提出过程模型的各个阶段中，同时也有助于识别研究空白，从而发现新的方法。

首先，通过将现有的识别方法整合到该模型中来评估该过程模型。其次，一项案例研究表明，该过程模型允许从多个角度看待微服务架构，并可产生不同的架构替代方案。因此，软件架构师能够以标准化方式更好地论证、比较和推导微服务架构决策。我们还表明，该过程模型可以集成到现有的软件开发流程中。

关键词 —微服务, 过程模型, 软件架构, 软件设计

一、引言

微服务自2014年左右以来已成为现代应用程序开发的架构风格。它们经常被提及的优势包括更好的可扩展性、可维护性以及更快的开发周期，并且可以减少整个应用系统中的技术债务[1]。

然而，采用微服务架构也存在一些挑战，例如初始复杂性的增加以及在运维过程中出现数据不一致的风险。此外，微服务的充分识别仍然具有挑战性。在此过程中，软件架构师的经验和知识至关重要。服务如果分解不当，最终可能导致后期昂贵的重构。近年来，研究人员也在探索自动化流程，以在设计阶段支持软件架构师[2],[3]。

微服务的识别基于内聚性和松散耦合的原则。内聚性意味着特定微服务的职责沿业务能力有明确的定义。松散耦合意味着微服务可以独立运行和部署。一方面，微服务应具有高度内聚性，另一方面保持松散耦合。此外，还有其他可能影响粒度的因素，这些因素决定了微服务是细粒度还是粗粒度。问题在于，在设计阶段，一个结构化的过程模型如何支持软件架构师开发微服务架构[4]–[6]。

一个持续存在的问题是，目前尚不存在统一且结构化的过程模型来支持微服务识别方法的开发、应用和选择。识别方法的目标是基于软件制品（如源代码或日志）确定合适的微服务候选者。为解决这一问题，本文通过论证‐演绎分析构建并提出了一种过程模型。统一过程模型能够提高微服务识别方法及架构的标准化程度、共同理解能力和可比性。通常情况下，过程模型是“设计/产品开发/产品创建过程的表示”[7]。我们的过程模型聚焦于并扩展了软件开发过程中的设计阶段。此外，我们展示了如何将识别方法集成到该过程模型中。一项案例研究表明，该过程模型能够以统一且结构化的方式实现对软件架构的不同视角观察。

本文的结构如下。首先，我们总结了与面向服务的架构以及微服务识别过程模型相关的研究工作。其次，我们阐述了研究方法、研究问题和结果。第三，我们通过集成新的识别方法以及案例研究，对过程模型进行了评估。该案例研究涉及信用评分领域中的一个分析应用。最后，我们总结了理论和实践意义，并提出了研究展望。

II. 相关工作

A. 软件开发流程和服务导向架构

服务划分不充分的问题对微服务而言并非新问题。面向服务的架构（SOA）同样考虑服务内聚性和低耦合，并加以确定。

细粒度服务与粗粒度服务之间。该领域已存在全面的过程模型，例如图1所示的“面向服务的设计与开发方法论”[4],。该模型整合并连接了规划、分析与设计、实现、服务供给、部署与运维等阶段。与传统软件开发流程相比，两者都共同包含设计阶段，例如[9]。此外，[4]还将服务内聚和服务松散耦合的原则融入到过程中。

如何支持软件架构师的挑战在SOA中已经得到解决。例如，[10] modeledar‐chitecture decisions并将其组织成可重用的模型。在此基础上，粒度问题还包括消息交换的结构和操作分组。

关于自动化算法的具体支持及其如何集成到统一过程模型中的内容，在上述论文中未涉及。本文重点关注图1中的设计阶段，因为本文通过我们提出的过程模型扩展了该阶段。

B. 微服务识别的过程模型

在[6],[11],[12]的文献综述中可以找到微服务自动和半自动识别的方法。识别方法旨在基于源代码或日志等软件制品来确定微服务候选者。

具体的过程模型确实存在，但必须针对相应的方法进行适配。例如，[13]指定了一个“服务分解过程”，该过程提供了以下活动：(1) 创建纳米实体，(2) 创建加权图，(3) 计算候选切割，以及(4) 可视化候选切割。此外，[14]提出了“微服务的数据流驱动的分解机制的过程”：(1) 指定用例（函数、业务能力），(2) 构建数据流（语句），(3) 识别微服务候选者。

还存在一些具体的向微服务架构迁移的过程模型，例如在[11],[15],[16]中。例如，[15]中提出的活动包括：(1) 从单体应用收集信息，(2) 将系统中的实体分组为候选微服务，(3) 以图的形式对分解进行可视化。

上述提到的过程模型存在一个局限性，即它们是为特定的识别方法而非常具体地开发的。这类方法有很多，因此也各自拥有独立的过程模型。我们的过程模型对这些具体的模型进行了泛化，这有助于软件架构师更轻松地开始设计微服务。

III. 微服务设计与识别的过程模型

A. 方法

为了开发一个过程模型，我们选择了论证‐演绎分析[17]的方法。我们将该方法与定性内容分析的方法相结合，定义检索式、纳入与排除标准，以选择相关论文[18]。

总体而言，本论文的目标是通过统一过程支持软件架构师进行微服务的设计与识别。因此，我们希望回答主要的研究问题：如何统一设计和比较微服务架构？

为了实施研究问题，我们采用了来自[12]的检索策略，并于2020年在相关的科学数据源ScienceDirect、IEEE和ACM DigitalLibrary中应用了该策略。

ALL=((微服务 OR 微服务) AND (iden‐tif\* OR extract\* OR migrati\* OR decompos\* OR refactor\*)) AND PY>=(2014)

我们决定将结果的发表年份限制在2014年，因为微服务的概念自2014[5]以来已经确立。我们定义了纳入标准，即研究必须提供关于结构化过程步骤的线索，并且以英文撰写。我们排除了超出范围、属于灰色文献且没有摘要的论文。此外，我们将论文集分为两部分：一部分用于论证‐演绎分析（2014年至2019年，包含完整年度），另一部分用于评估（2020年）。我们在2020年初首次应用检索式，随后在2020年期间持续使用。

应用的检索式共得到101篇论文。在2014年至2019年的完整年度中，我们找到了81篇论文。对于2020年，我们找到了21篇论文。在构建过程模型时，我们选定了31篇论文作为相关文献。在评估阶段，我们选定了20篇论文作为相关文献。

为了开发该过程模型，我们重点关注了论文中可用于软件开发过程设计阶段的方法和制品。在阅读全文的过程中，我们持续识别出论文中的具体过程阶段，并从论文[12],[18]中归纳推导出抽象过程阶段。

B. 过程模型概述与阶段

根据相关文献，我们开发了一个微服务设计与识别的过程模型，如图2所示。该过程模型可以集成到

图1[4],[9]的设计阶段中，但也可以应用于具有类似设计阶段的其他软件开发流程。我们通过方法论和具体描述来细化该阶段，说明如何开展设计阶段。

在进入提出的流程模型之前，需要完成至少一次需求分析和规划阶段。需求分析对于收集设计阶段所需的相关制品至关重要。在敏捷项目中，整个软件开发过程可以以多次迭代的方式进行。因此，我们的过程模型可以通过先前阶段的迭代逐步丰富更多信息，例如来自实现阶段的已实现源代码或来自监控阶段的日志。此外，还可以涉及不同的利益相关者。我们希望该过程模型能够支持软件架构师和开发人员，因此大多数任务将面向他们。然而，业务专家或需求工程师也可以参与该过程[19]。

为了在结合该提出的流程模型时，为微服务识别的适当方法选择提供支持，我们参考了[12]中的文献综述。各阶段将在以下章节中进行描述。

1) 识别并定义原子单元（阶段1）

阶段1的目标是识别原子单元。我们引入原子单元的概念，因为它们是开始分解过程的起点。在一些论文中，原子单元也被称为功能原子[13]。此外，[11]将原子单元的概念用作微服务架构的细粒度构建块。该阶段的输出是原子单元的文本说明。

例如，原子单元可以是一个实体、一个函数、一个功能或一个接口[12]。可以从需求分析或规划阶段的制品中找到相关信息。实体可以从用例描述中推导出来。如果源代码已经存在于迁移项目的背景下。

2) 建模原子单元之间的依赖关系（阶段2）

此阶段的目标是建模原子单元之间的功能依赖关系。对于功能需求，可以考虑用例描述或业务流程。因此，理解业务流程和需求至关重要。

在如何建模依赖关系方面，存在不同的方法和视角：从逻辑和物理视角，或从静态和动态视角。建模语言取决于所选择的原子单元。例如，可以使用实体关系模型对应用程序进行建模，以描述业务实体、其数据及其关系[13]。

另一种选择是采用数据流驱动方法，对函数与操作之间的数据交换进行建模[14]。此外，在此阶段也可以采用领域驱动设计，因为可以根据通用语言对限界进行建模[20],[21]。该阶段的输出至少是一种适当建模语言（如统一建模语言或实体关系表示法等）的模型。

3) 使用适当的标准描述原子单元及其依赖关系（第三阶段）

此阶段的目标是考虑原子单元以及它们之间关系的重要基本条件。除了功能需求（阶段2）之外，这些框架条件也对软件架构产生决定性影响，通常被称为非功能需求或质量属性。

这些条件必须整合到阶段2的模型中。重要的是要整体识别并描述影响因素。可以咨询业务专家、需求工程师、软件架构师和开发人员来识别这些因素。

在微服务背景下，必须考虑内聚性以及低耦合的原则。指标可以为此目的进行了定义。例如，[13]定义了重要的耦合指标和尺度，可用于描述原子单元之间的关系。在数据流图的背景下，函数调用之间的关系也可以通过调用频率和数据量来描述和量化。

原子单元本身也可以进一步表征。例如，一个实体的具体技术属性可以描述实体之间的语义相似性和概念。团队组织等非功能性特征也可以被整合进来。

图3阐明了质量属性如何扩展阶段2（原子单元及其关系）的模型。该阶段的输出是关于关系和原子单元的质量属性的文本规范。

IV. 过程模型评估

我们从两方面评估该过程模型。首先，我们尝试对在论证‐演绎分析过程中明确排除的2020年论文进行分类（见第IV‐A节）。其次，我们开展一项案例研究来应用该过程模型（见第IV‐B节）。

A. 2020年发表方法的评估

通过2020年的论文进行评估，使我们能够展示该过程模型在新方法上的应用和泛化能力。总共，我们使用前述检索式在2020年找到了20种新方法。

我们在表I中展示了一个来自[15]的已采用和评估的示例。利用表I中的模板，可以将方法（1）归类到我们过程模型的各个阶段，并且（2）能够针对每个阶段轻松地与其他方法进行比较。此外，还可以发现研究空白。例如，在[15]直到第三阶段具有相同前提条件的情况下，我们可以研究替代的聚类算法，并使用阶段5的指标对这些算法进行比较。

B. 案例研究——信用评分分析应用中的微服务

本节介绍了一个案例研究，用于展示我们的过程模型如何应用。该用例来自一个名为KNIME[24]的开源分析平台。此示例要解决的主要需求是银行职员希望了解客户的信用状况以支持信贷决策的客户。该用例已在KNIME中实现，但尚未迁移到微服务架构。微服务架构可能适用于将该需求集成到银行的现有系统中。为了推导出合适的微服务架构，我们将通过我们的过程模型迭代三次，以识别此用例的微服务。

该用例描述了一个来自信用风险领域的分类问题，旨在确定客户的信用评分。基于选定的客户和信用数据（特征），计算出信用评分（良好或不良）。为此，通过准确率来训练和比较分类模型，然后选择最佳模型以执行未知和未来的信用评分。工作流如图4[24]所示。该工作流区分了持续训练和模型应用。本案例研究的目的是展示我们的过程模型如何运作，因此我们将为该工作流识别一个合适的微服务架构。

除了应用我们的过程模型外，我们还使用了三种具体的识别方法。因此，我们对该过程模型进行了三次迭代。首先，我们应用了由[14]提出的一种“通过数据流驱动从单体应用中识别微服务的方法”；其次，我们应用了由[25]提出的“stream‐MSA：一种用于创建短周期、快节奏的流处理管道的微服务方法”；第三，我们应用了由[13]提出的“服务切割器：一种系统化的服务分解方法”。这三种方法由作者选定，更多方法可在[12]中找到。表II展示了案例研究的摘要与比较。由于本案例研究的重点并非对具体微服务架构的评估，因此评估阶段采用描述性方式进行。

基于“一种从单体应用中通过数据流驱动方法识别微服务”的第一次迭代[14]

为了将单体应用迁移到微服务架构，[14]提出了一种由业务逻辑数据流驱动的自上而下分解方法。我们希望使用这种用于分解信用评分工作流的方法。首先，我们遵循过程模型的步骤开始。然后，在[14]方法中搜索我们需要的信息以启动分解过程。表II显示了结果。例如，图4中的初始工作流是一个该方法所需的0级数据流图。

在我们的过程模型的阶段2中，需要将该模型转换为图5中建模的抽象格式。具体依赖是指描述两个相互调用函数的语句，例如{数据存储1, P1}。这些函数被建模为过程。数据通过数据存储进行交换。例如，P3表示训练函数，需要从数据存储3获取预处理数据，并将训练好的模型持久化到数据存储4中。[14]提出的方法未集成更多质量属性。因此，阶段2中的函数依赖已足够。

在阶段4，该模型通过由[14]开发的算法应用，以找到一个单个微服务候选。主要原因是由于工作流所导致的高耦合被建模。

基于“stream‐MSA：用于创建短周期、快节奏的流处理管道的微服务方法”进行的第二次迭代[25]

由[25]提出的方法与之前的方法类似。首先，原子单元同样是函数。函数调用建模了函数依赖（见图3）。因此，阶段1到3几乎相同。然而，在执行我们提出的流程模型的阶段4时，[25]建议每个函数对应一个微服务候选。因此，可以推断出五个微服务候选。该微服务架构可以通过在实验期间测量数据速率来评估，如[25]所述。

基于“服务切割器：一种系统化的服务分解方法”的第三次迭代，作者为[13]

服务切割器是一种基于准则的方法和架构知识的结构化方法。本案例研究中采用的方法列于表II。这些实体源自数据集以及来自[24]的工作流实体。服务切割器方法基于原子单元的数据、操作或制品。在我们的案例研究中，我们选择由实体表示的数据。我们根据对数据集的了解识别出这些实体。由于具有特征和类别，我们区分了信用数据和信用评分。我们并未进一步具体化信用数据实体，例如客户数据、账户数据等，也不展示实体的属性。在这种情况下，该粒度足以降低案例研究的复杂性。训练实体包含所使用的模型算法的信息，并与预处理的信用数据存在关联关系，从而表明训练是基于该数据的。实体关系模型如图7所示。我们将实体之间的关系建模为“拥有”或“基于”依赖关系。

[13]列出了许多耦合标准。软件架构师必须手动根据相关耦合标准，在预定义的评分尺度上对阶段2模型中的每个依赖进行评估。例如，我们可以将信用数据与信用评分之间的依赖建模为强依赖。层次聚类算法为微服务候选者计算聚类。因此，本例中微服务候选者的范围从单个微服务到七个微服务不等。具体数量取决于软件架构师的偏好，即认为多少个微服务是合适的或必需的。

C. 比较与讨论

总之，这三种识别方法得出了不同的解决方案。提出的过程模型有助于使这些方法更具可比性。首先，可以明确指出原子单元。原子单元对具体识别方法的选择有重要影响[12]。然而，我们过程模型的第一阶段可以在尚未选定具体识别方法的情况下进行。根据案例研究，如果只知道以函数作为原子单元，则[13]的方法并不合适，因为它需要实体。此外，建模可以采用不同的方式，并且可以使用多个标准。提出的流程模型支持微服务的设计与识别的主要活动。

假设在第三次迭代后仍未获得合适的微服务架构，则可以启动进一步的迭代。在此迭代中，也可以实施一种新方法。因此，该新方法也意味着存在一个研究空白，并可进行深入研究。此类方法也可能是现有识别方法的组合。

五、结论

为实现一致且易于理解的过程，本文提出了一种用于微服务设计与识别的过程模型。该过程模型应支持微服务的开发以及合适的识别方法的选择。该过程模型是基于文献中现有的识别方法通过演绎推导得出的，旨在将这些方法分类到所提出过程模型的各个阶段，并识别研究空白和新方法。

首先，通过将现有的识别方法整合到该模型中来评估该过程模型。其次，一项案例研究表明，该过程模型允许多角度看待微服务架构，从而产生不同的架构替代方案。因此，软件架构师可以更充分地论证和制定微服务架构决策，因为它允许以标准化方式比较设计过程和微服务架构本身。我们还表明，该过程模型可以集成到现有的软件开发流程中。

本文存在两个局限性。首先，我们的研究方法仅考虑了来自相关科学数据库的文献，尽管未来的研究也可能关注博客文章等灰色文献。其次，该过程模型由作者开发，并至少由作者进行了评估。

未来，该过程模型将由软件架构师进行评估，以展示该过程模型如何实现更具可比性的微服务架构，并应用于其他领域或更复杂的软件开发项目中。此外，未来研究的重点是基于提出的流程模型开发新的识别方法。

本文具有理论和实践意义。理论上，可以识别研究空白。实践中，该过程模型允许对不同的识别方法和微服务架构进行清晰、有结构的比较和验证。因此，架构决策可以得到更好的对比和验证。