-
Notifications
You must be signed in to change notification settings - Fork 191
Create koupleless-community-cultivating-an -engineering-mindset-in-op… #1313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,147 @@ | ||||||
# 开源之夏经验分享|Koupleless 社区黄兴抗:在开源中培养工程思维 | ||||||
|
||||||
**文|黄兴抗** | ||||||
|
||||||
电子信息工程专业 | ||||||
|
||||||
Koupleless 社区贡献者 | ||||||
|
||||||
就读于南昌师范学院,电子信息工程专业的大三学生。 | ||||||
|
||||||
**本文 2634 字,预计阅读 7 分钟** | ||||||
|
||||||
今天 SOFAStack 邀请到了开源之夏 2024 Koupleless 社区的中选学生**黄兴抗**同学!在本项目中,他参与完成了**存量应用自动改造成模块**。希望他分享的这段经历,能让更多人了解到 Koupleless 开源社区,感受开源的魅力~ | ||||||
|
||||||
**项目链接**:[https://summer-ospp.ac.cn/org/prodetail/2495a0376?lang=zh&list=pro](https://summer-ospp.ac.cn/org/prodetail/2495a0376?lang=zh&list=pro) | ||||||
|
||||||
## 项目信息 | ||||||
|
||||||
**项目名称**:存量应用自动改造成模块 | ||||||
|
||||||
**项目导师**:赵真灵 | ||||||
|
||||||
**项目背景**:在参与 Koupleless 社区项目之前,我就在社区文章中了解到,当前企业在向云原生转型的过程中往往面临着一个重要痛点——**存量应用改造成本高**。特别是对于大量已经运行的 SpringBoot/SOFABoot 应用,「如何低成本地实现模块化改造」成为一个急需解决的问题。 | ||||||
|
||||||
**项目目的**:本项目的核心目标是建设存量应用的自动化模块改造工具,使得应用能够实现传统应用向模块化的低成本升级,兼顾代码兼容性,同时支持独立启动与合并部署。 | ||||||
|
||||||
## 技术方案设计 | ||||||
|
||||||
** 整体架构** | ||||||
|
||||||
为了实现目标,我们通过 `<span>arkctl</span>` 命令行工具提供简单易用的入口,将核心逻辑封装在一个包含以下 4 个主要组件的 JAR 包中: | ||||||
|
||||||
1. Launcher—作为整个工具的统一入口 | ||||||
2. ApplicationPropertiesModifier—用于扫描并修改应用配置 | ||||||
3. SlimmingConfiguration—负责模块瘦身和依赖管理 | ||||||
4. PomModifier—专门处理 Maven 配置相关的逻辑 | ||||||
|
||||||
### 关键技术点 | ||||||
|
||||||
**1. 配置文件自动化处理** | ||||||
|
||||||
自动扫描和修改配置文件,支持多环境配置合并,确保改造过程安全、可回滚。 | ||||||
|
||||||
**2. POM 文件智能改造** | ||||||
|
||||||
自动添加必要的依赖和插件,实现版本兼容检测和适配。 | ||||||
|
||||||
**3. 模块瘦身方案** | ||||||
|
||||||
实现依赖隔离,优化模块体积,保证改造后的应用在运行时的兼容性。 | ||||||
|
||||||
### 模块改造的核心要素 | ||||||
|
||||||
**1. 模块打包插件的引入** | ||||||
POM 文件中的关键配置如下: | ||||||
|
||||||
```bash | ||||||
<plugin> | ||||||
<groupId>com.alipay.sofa</groupId> | ||||||
<artifactId>sofa-ark-maven-plugin</artifactId> | ||||||
<configuration> | ||||||
<skipArkExecutable>true</skipArkExecutable> | ||||||
<declaredMode>true</declaredMode> | ||||||
</configuration> | ||||||
</plugin> | ||||||
``` | ||||||
|
||||||
> **Q:为什么需要引入模块打包插件?** | ||||||
> 传统的 Spring Boot 应用打包后是一个可独立运行的 JAR,sofa-ark-maven-plugin 能够将应用打包成符合模块规范的格式,模块化部署需要特殊的类加载隔离机制,通过 declaredMode 实现精确的类隔离,避免多模块间的冲突。 | ||||||
|
||||||
**2. 模块瘦身的必要性** | ||||||
模块瘦身配置示例: | ||||||
|
||||||
```bash | ||||||
slimming.excludeGroupIds=org.springframework,org.apache.commons | ||||||
slimming.excludeArtifactIds=commons-lang,commons-io | ||||||
``` | ||||||
|
||||||
> **Q:为什么需要模块瘦身?** | ||||||
> 基座已包含大量公共依赖,模块无需重复打包。重复依赖会导致类加载冲突,模块体积过大影响启动性能和资源利用,通过瘦身可以优化模块大小,提高部署效率。 | ||||||
|
||||||
**3. 配置文件改造的意义** | ||||||
配置文件处理的核心逻辑如下: | ||||||
|
||||||
```bash | ||||||
public static void modifyApplicationProperties(String directoryPath, String applicationName) { | ||||||
Properties props = new Properties(); | ||||||
props.setProperty("spring.application.name", applicationName); | ||||||
} | ||||||
``` | ||||||
Comment on lines
+86
to
+90
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion Complete the implementation example for configuration file modification. The method implementation is incomplete. It creates a Properties object and sets a property, but doesn't save changes or interact with actual files. This could be misleading for readers trying to understand the actual implementation. -```bash
+```java
public static void modifyApplicationProperties(String directoryPath, String applicationName) {
Properties props = new Properties();
props.setProperty("spring.application.name", applicationName);
+
+ // Load existing properties
+ File propsFile = new File(directoryPath + "/application.properties");
+ if (propsFile.exists()) {
+ try (FileInputStream in = new FileInputStream(propsFile)) {
+ props.load(in);
+ }
+ }
+
+ // Save updated properties
+ try (FileOutputStream out = new FileOutputStream(propsFile)) {
+ props.store(out, "Updated by Koupleless module converter");
+ }
} |
||||||
|
||||||
> **Q:为什么需要改造配置文件?** | ||||||
> 模块需要独立的应用名称和上下文路径,避免多模块间的配置冲突,确保模块能够在合并部署环境中正确运行,支持模块的动态部署和热更新。 | ||||||
|
||||||
## 项目实现思路 | ||||||
|
||||||
针对传统的存量应用手动改造成模块的方式,对其相关步骤进行拆解和分析后,可感知到三个挑战:配置文件改造、依赖管理和构建适配。 | ||||||
|
||||||
* **配置文件改造**方面,挑战主要在于配置文件分散在不同目录、多环境*(如开发、测试、生产)*配置的复杂性,以及可能存在的配置冲突。为了解决这些问题,我们通过递归扫描定位所有配置文件,利用 Java Properties API 确保读写的安全性,同时采用追加写入的方式,避免覆盖已有配置内容。 | ||||||
* **依赖管理**方面,我们需要处理模块与基座依赖的重复问题、版本冲突的风险,以及模块体积过大导致加载性能下降的情况。针对这些问题,我们设计了预设排除规则,精确分析依赖关系,添加必要依赖,并将有冲突的模块默认调整为经过测试的稳定版本。此外,我们在配置文件中增加了黑白名单规则,以实现模块瘦身。 | ||||||
* **构建适配**方面,主要难点在于多模块项目复杂的依赖关系以及构建效率的优化。我们通过 `<span>declaredMode</span>` 实现类加载隔离,统一管理版本号,并合理配置构建参数,优化插件的执行顺序,减少了不必要的构建步骤。 | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🛠️ Refactor suggestion Fix HTML rendering issue with inline span tag. Similar to line 31, the HTML span tag will be rendered as HTML rather than displayed as code. -* **构建适配**方面,主要难点在于多模块项目复杂的依赖关系以及构建效率的优化。我们通过 `<span>declaredMode</span>` 实现类加载隔离,统一管理版本号,并合理配置构建参数,优化插件的执行顺序,减少了不必要的构建步骤。
+* **构建适配**方面,主要难点在于多模块项目复杂的依赖关系以及构建效率的优化。我们通过 `declaredMode` 实现类加载隔离,统一管理版本号,并合理配置构建参数,优化插件的执行顺序,减少了不必要的构建步骤。 📝 Committable suggestion
Suggested change
|
||||||
|
||||||
## 开源之夏个人随访 | ||||||
|
||||||
### 自我介绍 | ||||||
|
||||||
大家好,我是**黄兴抗**,目前就读于南昌师范学院电子信息工程专业,大三学生。虽然我的专业和计算机软件领域并不完全对口,但我对软件开发也颇感兴趣,因此也十分向往接触云原生技术、微服务架构等前沿技术领域。接触开源是大二下学期时开始,自那之后我就经常关注开源社区的技术动态。 | ||||||
|
||||||
### 参与该项目的原因 | ||||||
|
||||||
选择 SOFAStack 社区主要有基于以下几点的考虑: | ||||||
|
||||||
**1. 技术积累** | ||||||
|
||||||
SOFAStack 作为蚂蚁集团开源的金融级云原生架构,拥有丰富的企业级实践经验。社区项目涵盖了微服务、云原生等热门技术领域,与我未来想从事的就业发展方向高度契合。 | ||||||
|
||||||
**2. 社区氛围** | ||||||
|
||||||
SOFAStack 社区有着完善的新人引导机制,仓库所有者也会为新人提供适合入手的 issue 作为开始。使得我在相关课题正式开发之前,就可以对其中的模块瘦身白名单实现的相关 issue 做一定贡献,让我能够切身感受到解决问题过程中完善的反馈机制。同时社区维护者积极响应,使我能够及时获得技术指导。 | ||||||
|
||||||
**3. 项目价值** | ||||||
|
||||||
Koupleless 项目致力于解决企业实际痛点,具有明确的商业价值。自动化改造工具的开发也能够帮助我积累工程化经验。此外,项目涉及多个技术领域,有助于拓展技术视野。 | ||||||
|
||||||
### 如何克服项目过程中的困难与挑战 | ||||||
|
||||||
在开发过程中少不了各种大大小小的困难与挑战,其中不仅有代码实现部分,也有许多非代码要求的项目流程,如文档编写、工作流的设计、测试用例等工作。这些实际面向企业的开发流程规范,让尚未就业的我时常感到困惑和阻碍。在这一情况下,导师给到我很多指导和建议,如参考一些优秀的活跃社区,这让我收获颇多。 | ||||||
|
||||||
在项目开发的初期阶段,导师会细心引导我深入了解项目的愿景、业务背景以及代码的整体架构,帮助我整体紧抓课题的方向,为后续开发奠定了坚实的基础。 | ||||||
|
||||||
在实际开发过程中,每当我遇到困难或卡点时,导师总是耐心地为我提供具体的建议和可行的改进方向,帮助我快速找到解决问题的思路。此外,社区还定期举办双周例会,大家在会上同步开发进展、交流心得,针对开发中遇到的难题展开讨论,并集思广益寻找高效的解决方案。这种机制不仅增强了团队协作,也让我更好地在学习中成长。 | ||||||
|
||||||
最让我印象深刻的挑战之一,是如何处理各种不同项目的**配置文件差异**和**版本兼容性**问题。针对前者,我采用了递归扫描的方式,并实现了智能合并策略,确保改造过程不会破坏原有配置。针对后者,面对不同版本的 Spring Boot 和 SOFABoot 应用,需要确保工具的通用性,最终通过实现版本检测和适配机制解决了这个问题。 | ||||||
|
||||||
### 有哪些收获 | ||||||
|
||||||
**1. 技术积累** | ||||||
|
||||||
通过这个项目,我锻炼了编码能力,更重要的是学会了如何设计一个自动化工具来解决实际问题。尤其是在处理配置文件、管理依赖等方面积累了宝贵经验。 | ||||||
|
||||||
**2. 开源精神** | ||||||
|
||||||
参与社区让我深刻体会到开源的协作精神。从社区成员的热情帮助到积极的反馈机制,都让我在解决问题的同时感受到了团队合作的力量。 | ||||||
|
||||||
**3. 工程思维** | ||||||
|
||||||
项目让我开始从更全面的角度看问题:功能的实现只是第一步,如何保证工具的可维护性、扩展性,甚至用户体验,都是需要考虑的重要因素。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Fix HTML rendering issue with inline span tags.
The
<span>
HTML tags will be rendered as HTML rather than displayed as code or text. This will likely cause rendering issues when the blog is published.📝 Committable suggestion