面向微服务架构的实现与代码格式化研究
面向微服务架构的实现
在将面向对象的单体应用迁移到微服务架构的过程中,这是一个复杂的两步过程。下面我们将详细探讨相关的研究成果、面临的威胁以及相关的工作。
研究成果
-
RQ1:Mono2Micro方法是否适用于不同类型的面向对象应用?
- 违反情况:违反定义为一个类依赖于属于不同微服务的类。在实验中,手动转换了与Java反射机制使用相关的两个封装违规情况。
- 结果分析:通过对多个应用的重构,发现所有应用的单体和微服务两个版本在执行时都没有编译或运行时错误。这表明所提出的转换使得消除集群之间的直接依赖成为可能,保证了微服务在各种应用中的封装特性。
-
相关数据:
| 应用 | 微服务数量 | 数据类数量 | 违规数量 |
| — | — | — | — |
| Findsportmates | 3 | 2 | 9 |
| JPetStore | 4 | 9 | 21 |
| PetClinic | 3 | 7 | 26 |
| SpringBlog | 4 | 8 | 104 |
| IMS | 5 | 18 | 113 |
| JForum | 8 | 37 | 1031 |
| 应用 | 实例数量 | 继承数量 | 异常数量 |
|---|---|---|---|
| Findsportmates | 9 | 0 | 0 |
| JPetStore | 20 | 0 | 0 |
| PetClinic | 24 | 2 | 0 |
| SpringBlog | 95 | 7 | 2 |
| IMS | 110 | 3 | 0 |
| JForum | 1013 | 16 | 2 |
-
RQ2:Mono2Micro方法在实现微服务架构时的精度如何?
- 实验结果:对于FindSportMates、JPetStore和InventoryManagementSystem,该方法在语法和语义正确性方面具有100%的精度,能够高精度地保留业务逻辑。
-
RQ3:Mono2Micro方法在实现微服务架构时的召回率如何?
- 实验结果:对于FindSportMates、JPetStore和InventoryManagementSystem,该方法具有100%的召回率。不过,对于JPetStore,Selenide测试“testOrder”在单体版本和MSA版本中都失败了,原因是测试环境的小数点分隔符与应用检查的不一致。
-
相关数据:
| 应用 | 测试数量 | 精度 | 召回率 |
| — | — | — | — |
| Findsportmates | 7 | 100% | 100% |
| JPetStore | 34 | 100% | 100% |
| IMS | 36 | 100% | 100% |
-
RQ4:Mono2Micro对性能有什么影响?
- 性能表现:引入微服务架构的扩展后,性能有小幅度提升。原本预期引入额外的网络调用会对迁移应用的性能产生负面影响,但实际并非如此。这可能是由于扩展请求服务的并行化方面,通过调整微服务实例的数量,微服务架构能够处理增加的请求并补偿额外的网络层。随着并行请求数量的增加,微服务架构的平均性能优于单体架构。
有效性威胁
-
内部有效性威胁
- 静态分析的局限性 :转换方法使用静态分析来检测和转换现有源代码,静态分析在识别实例封装违规时无法检测动态绑定和多态性。可以通过为每个子类型创建实例依赖来考虑最坏情况以避免此问题。
- 未使用代码的检测问题 :静态分析无法检测未使用的源代码,可能导致检测到比实际更多的依赖关系。在维护良好的应用中可以缓解此问题,也可以在检测步骤中进行混合分析,但动态分析需要大量的测试用例,这在大型工业代码库中并不总是可行的。
- 框架和语言特性的考虑不足 :该方法适用于不依赖强大框架的源代码,不考虑依赖注入和某些语言的反射性,在实验中手动解决了这些封装违规问题。
-
外部有效性威胁
- 架构恢复方法的影响 :使用特定的架构恢复方法会对转换阶段产生影响,识别的依赖数量和整体性能高度依赖于架构恢复阶段的结果。但研究的目标是在保留应用预期行为的同时进行迁移,而不是分析转换对生成架构的影响。
- 语言的局限性 :实验中的单体应用都用JAVA实现,但结果可以推广到任何面向对象语言,因为所有面向对象语言在类的结构和关系实现机制上是相似的。
相关工作
-
基于微服务的架构恢复
- 架构恢复对于促进软件重用、提高软件理解和支持软件演化至关重要。以前的架构恢复主要集中在恢复组件,近年来,许多工作致力于从面向对象软件中提取微服务架构。
-
不同的方法包括:
- 数据流驱动的方法:如Chen等人提出的从单体到微服务的数据流驱动方法。
- 聚类技术:从业务流程进行聚类,如Amiri提出的方法。
- 功能独立性方法:Jin等人提出的基于执行跟踪聚类的面向功能的微服务提取方法。
- 服务分解工具:如Service Cutter,辅助软件架构师进行设计决策。
- 自动化工具:分析应用的OpenAPI接口来提取微服务,如Baresi等人提出的方法。
- 聚类方法:用图表示单体,节点表示类,边的权重与类之间的耦合相关,如Mazlami等人的方法。
- 启发式方法:如De Alwis等人提出的功能拆分启发式方法。
-
向微服务应用的转换
- 重构的目标是通过代码转换来延长现有软件产品的生命周期,同时保留其功能行为。目前在向微服务转换的自动化过程方面的工作较少。
-
相关工作包括:
- 向组件架构的转换:如Allier等人将面向对象应用转换为面向组件的应用,Alshara等人将大型面向对象应用迁移到基于组件的应用。
- 模块提取方法:Terra等人提出的从单体软件架构中提取模块的方法,但未专注于可独立部署为微服务的模块转换。
- 手动转换的见解:如Fan等人分享的迁移过程实验报告,Amiri提出的提取方法并辅以手动转换来验证其方法。
个性化代码格式化:检测与修复
在软件开发中,源代码的可读性对于开发者来说至关重要,尤其是在基于组件的软件工程方案下工作的开发者。下面我们将探讨代码可读性的重要性、现有方法的局限性以及提出的自动化机制。
代码可读性的重要性
源代码可读性是一个复杂的概念,包括对控制流、功能和软件组件目的的理解。它与软件质量的支柱方面,如可维护性和可重用性高度相关。选择正确的格式化方法和合适的代码样式可以显著提高开发者对源代码的理解能力,而使用不同的编码样式会影响整体可读性,代码格式化的各个方面,如缩进,也会影响源代码的可理解性。
现有方法的局限性
许多研究试图对代码样式和格式化进行建模,主要是识别样式错误、提供样式修复或检测与预先接受的一组格式化规则的偏差。但大多数方法使用预定义的格式化规则集,这些规则通常是全球接受的,只能开启或关闭,无法更改或添加新规则。同时,一些方法主要关注程序理解,而不是从代码样式的角度关注可读性。由于团队和开发者的技能、需求和开发方式不同,并非所有的样式指南都适用于每个团队或开发者,团队可能需要花费大量时间来配置这些方法和工具以满足自身需求。
自动化机制的提出
为了克服上述局限性,提出了一种自动化机制,该机制可以通过完全无监督的方式检查项目或存储库中使用的代码样式,来建模个人或开发团队所需的代码格式化。具体步骤如下:
1.
代码标记化
:将源代码转换为小的有意义的片段,称为标记,用于训练机制的模型。
2.
错误定位预测
:通过训练模型来预测标记被错误定位的概率。
3.
修复建议
:检查多个可能的修复方案作为错误定位标记的替换,并根据评分函数给出最适合的修复建议给开发者。初步评估表明,该方法能够有效地检测项目代码样式中的格式化偏差,并为开发者提供可操作的建议。
面向微服务架构的实现与代码格式化研究
自动化机制的优势与应用示例
自动化机制在代码格式化方面具有显著优势,下面通过一个简单示例来展示其应用过程。
假设我们有一个简单的Python代码文件,其中存在一些代码样式上的偏差。以下是原始代码:
def add_numbers(a,b):
return a + b
result = add_numbers(3,4)
print(result)
在这个代码中,函数定义处参数之间缺少空格,不符合常见的代码样式规范。
自动化机制的处理过程如下:
1.
代码标记化
:将代码拆分为标记,例如
def
、
add_numbers
、
(
、
a
、
,
、
b
、
)
等。
2.
错误定位预测
:模型通过学习项目中其他代码文件的样式,发现参数之间缺少空格的情况不符合整体样式,预测此处标记存在错误定位。
3.
修复建议
:根据评分函数,建议在参数之间添加空格,修复后的代码如下:
def add_numbers(a, b):
return a + b
result = add_numbers(3, 4)
print(result)
通过这个示例可以看出,自动化机制能够快速准确地检测出代码样式中的偏差,并提供合理的修复建议。
总结与展望
将面向对象的单体应用迁移到微服务架构以及实现个性化的代码格式化,都是软件开发领域中重要的研究方向。
在面向微服务架构的实现方面,Mono2Micro方法在不同类型的面向对象应用中展现出了良好的适用性,能够保证微服务的封装特性,并且在精度、召回率和性能方面都有不错的表现。尽管存在一些内部和外部的有效性威胁,但通过合理的处理和考虑,这些问题可以得到一定程度的缓解。相关的架构恢复和转换工作也为微服务架构的实现提供了多种思路和方法。
在代码格式化方面,提出的自动化机制能够有效地解决现有方法的局限性,通过无监督的方式建模代码样式,为开发者提供可操作的建议,提高代码的可读性和可维护性。
未来的研究可以进一步考虑以下方面:
1.
微服务架构
:
- 考虑更多面向对象语言的特定属性,如反射性、多重继承等。
- 研究依赖于框架的应用中的依赖关系和转换模式。
- 应用模型驱动工程技术,将方法推广到更多的语言和框架。
2.
代码格式化
:
- 优化自动化机制的模型,提高检测偏差和提供建议的准确性。
- 扩展机制的适用范围,支持更多类型的代码文件和编程语言。
- 与开发工具集成,实现实时的代码样式检测和修复。
以下是一个总结上述研究内容的mermaid流程图:
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A(面向对象单体应用迁移):::process --> B(微服务架构实现):::process
B --> C(研究成果评估):::process
C --> C1(RQ1适用性):::process
C --> C2(RQ2精度):::process
C --> C3(RQ3召回率):::process
C --> C4(RQ4性能):::process
B --> D(有效性威胁分析):::process
D --> D1(内部威胁):::process
D --> D2(外部威胁):::process
B --> E(相关工作参考):::process
E --> E1(架构恢复):::process
E --> E2(转换方法):::process
F(代码可读性问题):::process --> G(自动化代码格式化机制):::process
G --> G1(代码标记化):::process
G --> G2(错误定位预测):::process
G --> G3(修复建议):::process
G --> H(应用示例):::process
H --> H1(原始代码):::process
H --> H2(修复后代码):::process
I(未来研究展望):::process
I --> I1(微服务架构扩展):::process
I --> I2(代码格式化优化):::process
通过以上的研究和探索,我们可以更好地实现面向微服务架构的迁移和代码的有效格式化,提高软件开发的质量和效率。
超级会员免费看
29

被折叠的 条评论
为什么被折叠?



