|
| 1 | +--- |
| 2 | +title: "开源之夏经验分享|Koupleless 社区黄兴抗:在开源中培养工程思维" |
| 3 | +authorlink: "https://github.com/sofastack" |
| 4 | +description: "本项目的核心目标是建设存量应用的自动化模块改造工具,使得应用能够实现传统应用向模块化的低成本升级,兼顾代码兼容性,同时支持独立启动与合并部署。" |
| 5 | +categories: "SOFAStack" |
| 6 | +tags: ["SOFAStack"] |
| 7 | +date: 2024-12-31T15:00:00+08:00 |
| 8 | +cover: "https://img.alicdn.com/imgextra/i2/O1CN01j3AhW71OAA5e138g4_!!6000000001664-0-tps-1215-517.jpg" |
| 9 | +--- |
| 10 | + |
| 11 | +# 开源之夏经验分享|Koupleless 社区黄兴抗:在开源中培养工程思维 |
| 12 | + |
| 13 | +**文|黄兴抗** |
| 14 | +电子信息工程专业 |
| 15 | +Koupleless 社区贡献者 |
| 16 | + |
| 17 | +就读于南昌师范学院,电子信息工程专业的大三学生。 |
| 18 | + |
| 19 | +**本文 2634 字,预计阅读 7 分钟** |
| 20 | + |
| 21 | +今天 SOFAStack 邀请到了开源之夏 2024 Koupleless 社区的中选学生**黄兴抗**同学!在本项目中,他参与完成了**存量应用自动改造成模块**。希望他分享的这段经历,能让更多人了解到 Koupleless 开源社区,感受开源的魅力~ |
| 22 | + |
| 23 | +**项目链接**:[https://summer-ospp.ac.cn/org/prodetail/2495a0376?lang=zh&list=pro](https://summer-ospp.ac.cn/org/prodetail/2495a0376?lang=zh&list=pro) |
| 24 | + |
| 25 | +## 项目信息 |
| 26 | + |
| 27 | +**项目名称**:存量应用自动改造成模块 |
| 28 | + |
| 29 | +**项目导师**:赵真灵 |
| 30 | + |
| 31 | +**项目背景**:在参与 Koupleless 社区项目之前,我就在社区文章中了解到,当前企业在向云原生转型的过程中往往面临着一个重要痛点——**存量应用改造成本高**。特别是对于大量已经运行的 SpringBoot/SOFABoot 应用,「如何低成本地实现模块化改造」成为一个急需解决的问题。 |
| 32 | + |
| 33 | +**项目目的**:本项目的核心目标是建设存量应用的自动化模块改造工具,使得应用能够实现传统应用向模块化的低成本升级,兼顾代码兼容性,同时支持独立启动与合并部署。 |
| 34 | + |
| 35 | +## 技术方案设计 |
| 36 | + |
| 37 | +** 整体架构** |
| 38 | + |
| 39 | +为了实现目标,我们通过 `<span>arkctl</span>` 命令行工具提供简单易用的入口,将核心逻辑封装在一个包含以下 4 个主要组件的 JAR 包中: |
| 40 | + |
| 41 | +1. Launcher—作为整个工具的统一入口 |
| 42 | +2. ApplicationPropertiesModifier—用于扫描并修改应用配置 |
| 43 | +3. SlimmingConfiguration—负责模块瘦身和依赖管理 |
| 44 | +4. PomModifier—专门处理 Maven 配置相关的逻辑 |
| 45 | + |
| 46 | +### 关键技术点 |
| 47 | + |
| 48 | +**1. 配置文件自动化处理** |
| 49 | + |
| 50 | +自动扫描和修改配置文件,支持多环境配置合并,确保改造过程安全、可回滚。 |
| 51 | + |
| 52 | +**2. POM 文件智能改造** |
| 53 | + |
| 54 | +自动添加必要的依赖和插件,实现版本兼容检测和适配。 |
| 55 | + |
| 56 | +**3. 模块瘦身方案** |
| 57 | + |
| 58 | +实现依赖隔离,优化模块体积,保证改造后的应用在运行时的兼容性。 |
| 59 | + |
| 60 | +### 模块改造的核心要素 |
| 61 | + |
| 62 | +**1. 模块打包插件的引入** |
| 63 | +POM 文件中的关键配置如下: |
| 64 | + |
| 65 | +```bash |
| 66 | +<plugin> |
| 67 | +<groupId>com.alipay.sofa</groupId> |
| 68 | +<artifactId>sofa-ark-maven-plugin</artifactId> |
| 69 | +<configuration> |
| 70 | +<skipArkExecutable>true</skipArkExecutable> |
| 71 | +<declaredMode>true</declaredMode> |
| 72 | +</configuration> |
| 73 | +</plugin> |
| 74 | +``` |
| 75 | + |
| 76 | +> **Q:为什么需要引入模块打包插件?** |
| 77 | +> 传统的 Spring Boot 应用打包后是一个可独立运行的 JAR,sofa-ark-maven-plugin 能够将应用打包成符合模块规范的格式,模块化部署需要特殊的类加载隔离机制,通过 declaredMode 实现精确的类隔离,避免多模块间的冲突。 |
| 78 | +
|
| 79 | +**2. 模块瘦身的必要性** |
| 80 | +模块瘦身配置示例: |
| 81 | + |
| 82 | +```bash |
| 83 | +slimming.excludeGroupIds=org.springframework,org.apache.commons |
| 84 | +slimming.excludeArtifactIds=commons-lang,commons-io |
| 85 | +``` |
| 86 | + |
| 87 | +> **Q:为什么需要模块瘦身?** |
| 88 | +> 基座已包含大量公共依赖,模块无需重复打包。重复依赖会导致类加载冲突,模块体积过大影响启动性能和资源利用,通过瘦身可以优化模块大小,提高部署效率。 |
| 89 | +
|
| 90 | +**3. 配置文件改造的意义** |
| 91 | +配置文件处理的核心逻辑如下: |
| 92 | + |
| 93 | +```bash |
| 94 | +public static void modifyApplicationProperties(String directoryPath, String applicationName) { |
| 95 | +Properties props = new Properties(); |
| 96 | +props.setProperty("spring.application.name", applicationName); |
| 97 | +} |
| 98 | +``` |
| 99 | + |
| 100 | +> **Q:为什么需要改造配置文件?** |
| 101 | +> 模块需要独立的应用名称和上下文路径,避免多模块间的配置冲突,确保模块能够在合并部署环境中正确运行,支持模块的动态部署和热更新。 |
| 102 | +
|
| 103 | +## 项目实现思路 |
| 104 | + |
| 105 | +针对传统的存量应用手动改造成模块的方式,对其相关步骤进行拆解和分析后,可感知到三个挑战:配置文件改造、依赖管理和构建适配。 |
| 106 | + |
| 107 | +* **配置文件改造**方面,挑战主要在于配置文件分散在不同目录、多环境*(如开发、测试、生产)*配置的复杂性,以及可能存在的配置冲突。为了解决这些问题,我们通过递归扫描定位所有配置文件,利用 Java Properties API 确保读写的安全性,同时采用追加写入的方式,避免覆盖已有配置内容。 |
| 108 | +* **依赖管理**方面,我们需要处理模块与基座依赖的重复问题、版本冲突的风险,以及模块体积过大导致加载性能下降的情况。针对这些问题,我们设计了预设排除规则,精确分析依赖关系,添加必要依赖,并将有冲突的模块默认调整为经过测试的稳定版本。此外,我们在配置文件中增加了黑白名单规则,以实现模块瘦身。 |
| 109 | +* **构建适配**方面,主要难点在于多模块项目复杂的依赖关系以及构建效率的优化。我们通过 `<span>declaredMode</span>` 实现类加载隔离,统一管理版本号,并合理配置构建参数,优化插件的执行顺序,减少了不必要的构建步骤。 |
| 110 | + |
| 111 | +## 开源之夏个人随访 |
| 112 | + |
| 113 | +### 自我介绍 |
| 114 | + |
| 115 | +大家好,我是**黄兴抗**,目前就读于南昌师范学院电子信息工程专业,大三学生。虽然我的专业和计算机软件领域并不完全对口,但我对软件开发也颇感兴趣,因此也十分向往接触云原生技术、微服务架构等前沿技术领域。接触开源是大二下学期时开始,自那之后我就经常关注开源社区的技术动态。 |
| 116 | + |
| 117 | +### 参与该项目的原因 |
| 118 | + |
| 119 | +选择 SOFAStack 社区主要有基于以下几点的考虑: |
| 120 | + |
| 121 | +**1. 技术积累** |
| 122 | + |
| 123 | +SOFAStack 作为蚂蚁集团开源的金融级云原生架构,拥有丰富的企业级实践经验。社区项目涵盖了微服务、云原生等热门技术领域,与我未来想从事的就业发展方向高度契合。 |
| 124 | + |
| 125 | +**2. 社区氛围** |
| 126 | + |
| 127 | +SOFAStack 社区有着完善的新人引导机制,仓库所有者也会为新人提供适合入手的 issue 作为开始。使得我在相关课题正式开发之前,就可以对其中的模块瘦身白名单实现的相关 issue 做一定贡献,让我能够切身感受到解决问题过程中完善的反馈机制。同时社区维护者积极响应,使我能够及时获得技术指导。 |
| 128 | + |
| 129 | +**3. 项目价值** |
| 130 | + |
| 131 | +Koupleless 项目致力于解决企业实际痛点,具有明确的商业价值。自动化改造工具的开发也能够帮助我积累工程化经验。此外,项目涉及多个技术领域,有助于拓展技术视野。 |
| 132 | + |
| 133 | +### 如何克服项目过程中的困难与挑战 |
| 134 | + |
| 135 | +在开发过程中少不了各种大大小小的困难与挑战,其中不仅有代码实现部分,也有许多非代码要求的项目流程,如文档编写、工作流的设计、测试用例等工作。这些实际面向企业的开发流程规范,让尚未就业的我时常感到困惑和阻碍。在这一情况下,导师给到我很多指导和建议,如参考一些优秀的活跃社区,这让我收获颇多。 |
| 136 | + |
| 137 | +在项目开发的初期阶段,导师会细心引导我深入了解项目的愿景、业务背景以及代码的整体架构,帮助我整体紧抓课题的方向,为后续开发奠定了坚实的基础。 |
| 138 | + |
| 139 | +在实际开发过程中,每当我遇到困难或卡点时,导师总是耐心地为我提供具体的建议和可行的改进方向,帮助我快速找到解决问题的思路。此外,社区还定期举办双周例会,大家在会上同步开发进展、交流心得,针对开发中遇到的难题展开讨论,并集思广益寻找高效的解决方案。这种机制不仅增强了团队协作,也让我更好地在学习中成长。 |
| 140 | + |
| 141 | +最让我印象深刻的挑战之一,是如何处理各种不同项目的**配置文件差异**和**版本兼容性**问题。针对前者,我采用了递归扫描的方式,并实现了智能合并策略,确保改造过程不会破坏原有配置。针对后者,面对不同版本的 Spring Boot 和 SOFABoot 应用,需要确保工具的通用性,最终通过实现版本检测和适配机制解决了这个问题。 |
| 142 | + |
| 143 | +### 有哪些收获 |
| 144 | + |
| 145 | +**1. 技术积累** |
| 146 | + |
| 147 | +通过这个项目,我锻炼了编码能力,更重要的是学会了如何设计一个自动化工具来解决实际问题。尤其是在处理配置文件、管理依赖等方面积累了宝贵经验。 |
| 148 | + |
| 149 | +**2. 开源精神** |
| 150 | + |
| 151 | +参与社区让我深刻体会到开源的协作精神。从社区成员的热情帮助到积极的反馈机制,都让我在解决问题的同时感受到了团队合作的力量。 |
| 152 | + |
| 153 | +**3. 工程思维** |
| 154 | + |
| 155 | +项目让我开始从更全面的角度看问题:功能的实现只是第一步,如何保证工具的可维护性、扩展性,甚至用户体验,都是需要考虑的重要因素。 |
0 commit comments