1. 项目概述从学生到工程师的蜕变之路去年夏天当我完成最后一个功能模块的单元测试时突然意识到这个持续了8个月的个人项目已经悄然改变了我对软件开发的认知。这个始于课程作业的电商系统最终演变成了包含23个微服务、采用CI/CD自动化部署的完整产品。今天我想分享这个项目带给我的工程实践启示特别是那些教科书上不会写的血泪教训。这个项目最初只是软工课程的结课作业要求实现一个基础的图书商城。但在开发过程中我逐渐加入了OAuth2.0认证、Elasticsearch商品检索、Redis缓存优化等企业级功能。最让我自豪的是整个系统最终实现了99.2%的单元测试覆盖率并通过SonarQube的质量门禁。这些实践让我深刻理解了工程化与写代码的本质区别。2. 技术架构演进历程2.1 从单体到微服务的痛苦转型项目初期采用的是经典的Spring Boot单体架构这在MVP阶段确实快速实现了核心功能。但当商品模块需要支持多规格SKU时代码库开始出现严重的耦合问题。记得有一次修改支付接口意外导致购物车功能异常这促使我下决心进行架构改造。微服务拆分过程远比想象中复杂。我采用领域驱动设计DDD原则按照业务边界划分服务模块。关键教训包括接口版本控制在API网关(Nginx)中配置/v1,/v2路由规则分布式事务最终选用Seata的AT模式替代本地事务服务发现Consul比Eureka更适合小规模部署日志收集ELK栈需要至少8GB内存后来改用轻量级的LokiGranfa方案重要提示微服务不是银弹如果团队规模小于5人建议采用模块化单体架构。我花了整整三周才让分布式调试正常工作。2.2 持续集成流水线搭建实录自动化部署是另一个分水岭时刻。当我第五次因为手动部署漏掉依赖项导致服务崩溃后终于搭建了完整的GitLab CI/CD流水线stages: - test - build - deploy unit_test: stage: test script: - mvn test - python coverage.py --threshold95 docker_build: stage: build only: - master script: - docker build -t registry.example.com/app:$CI_COMMIT_SHA . - docker push registry.example.com/app:$CI_COMMIT_SHA k8s_deploy: stage: deploy environment: production script: - kubectl set image deployment/app *registry.example.com/app:$CI_COMMIT_SHA这个配置实现了提交即部署的完整流程但需要注意测试阶段必须设置退出码检查我们的流水线曾因一个被忽略的测试失败导致生产环境事故Docker镜像需要定期清理否则磁盘空间会爆炸式增长Kubernetes的滚动更新策略需要配置健康检查否则会出现服务中断3. 工程质量保障体系3.1 测试驱动开发的实践反思项目中期引入TDD后代码质量显著提升。但真实情况远没有教科书描述的那么美好初期测试代码与实现高度耦合每次业务逻辑变更都要重写测试过度追求覆盖率导致大量无意义测试如getter/setter集成测试启动时间从30秒逐渐增长到8分钟严重拖慢开发节奏后来我们优化为分层测试策略单元测试核心算法/工具类覆盖率要求100%契约测试服务间接口使用Pact框架组件测试单个服务的完整功能E2E测试仅关键用户旅程3.2 代码审查的隐藏成本使用GitLab MR机制进行代码审查时发现了几个反模式LGTM式敷衍审查通过配置必须至少2人评论才能合并超大变更集现在强制要求单次MR不超过400行代码缺乏标准后来制定了《代码审查清单》包括是否包含适当日志错误处理是否完整数据库查询是否有索引支持是否考虑并发场景最意外的发现是约30%的缺陷是在代码审查讨论过程中作者自己发现的。这说明审查的核心价值在于促进思考而非单纯找错。4. 项目管理中的认知升级4.1 需求管理的血泪史初期采用纯敏捷开发结果陷入迭代地狱每个sprint都在做新功能技术债务越积越多。后来调整为混合模式产品路线图季度级别的目标规划双周迭代聚焦可交付成果每月1个技术冲刺专门处理债务需求变更的处理流程也经过多次优化graph TD A[变更请求] -- B{影响范围评估} B --|小变更| C[直接开发] B --|重大变更| D[需求评审会] D -- E[更新PRD/原型] E -- F[调整迭代计划]4.2 文档即产品的理念转变曾经认为代码即文档直到新成员花了三天才弄明白认证流程。现在我们要求OpenAPI规范的接口文档必须随代码更新架构决策记录(ADR)存放在docs/decisions目录每个服务都有README.md说明本地开发环境配置复杂业务逻辑必须添加代码注释特别是那些反直觉的实现最有效的文档是故障处理手册记录了历史上所有生产事故的现象描述排查过程根本原因修复方案预防措施5. 个人成长的关键收获技术能力提升只是最基础的收获更重要的是工程思维的建立成本意识现在评估需求时会计算开发成本人日运维成本服务器费用机会成本做A就不能做B风险思维重要变更一定会考虑回滚方案灰度发布策略监控指标用户视角日志和错误信息会站在用户角度思考这个错误信息能帮助快速定位问题吗需要联系客服时我们能否提供足够上下文最后给在校生的建议不要满足于能运行要用工程化的标准要求自己。我简历上最亮眼的不是这个项目的技术栈而是从零构建并维护了日均1000访问量的完整系统这样的工程实践经历。
从学生项目到工程实践：微服务与CI/CD的实战经验
1. 项目概述从学生到工程师的蜕变之路去年夏天当我完成最后一个功能模块的单元测试时突然意识到这个持续了8个月的个人项目已经悄然改变了我对软件开发的认知。这个始于课程作业的电商系统最终演变成了包含23个微服务、采用CI/CD自动化部署的完整产品。今天我想分享这个项目带给我的工程实践启示特别是那些教科书上不会写的血泪教训。这个项目最初只是软工课程的结课作业要求实现一个基础的图书商城。但在开发过程中我逐渐加入了OAuth2.0认证、Elasticsearch商品检索、Redis缓存优化等企业级功能。最让我自豪的是整个系统最终实现了99.2%的单元测试覆盖率并通过SonarQube的质量门禁。这些实践让我深刻理解了工程化与写代码的本质区别。2. 技术架构演进历程2.1 从单体到微服务的痛苦转型项目初期采用的是经典的Spring Boot单体架构这在MVP阶段确实快速实现了核心功能。但当商品模块需要支持多规格SKU时代码库开始出现严重的耦合问题。记得有一次修改支付接口意外导致购物车功能异常这促使我下决心进行架构改造。微服务拆分过程远比想象中复杂。我采用领域驱动设计DDD原则按照业务边界划分服务模块。关键教训包括接口版本控制在API网关(Nginx)中配置/v1,/v2路由规则分布式事务最终选用Seata的AT模式替代本地事务服务发现Consul比Eureka更适合小规模部署日志收集ELK栈需要至少8GB内存后来改用轻量级的LokiGranfa方案重要提示微服务不是银弹如果团队规模小于5人建议采用模块化单体架构。我花了整整三周才让分布式调试正常工作。2.2 持续集成流水线搭建实录自动化部署是另一个分水岭时刻。当我第五次因为手动部署漏掉依赖项导致服务崩溃后终于搭建了完整的GitLab CI/CD流水线stages: - test - build - deploy unit_test: stage: test script: - mvn test - python coverage.py --threshold95 docker_build: stage: build only: - master script: - docker build -t registry.example.com/app:$CI_COMMIT_SHA . - docker push registry.example.com/app:$CI_COMMIT_SHA k8s_deploy: stage: deploy environment: production script: - kubectl set image deployment/app *registry.example.com/app:$CI_COMMIT_SHA这个配置实现了提交即部署的完整流程但需要注意测试阶段必须设置退出码检查我们的流水线曾因一个被忽略的测试失败导致生产环境事故Docker镜像需要定期清理否则磁盘空间会爆炸式增长Kubernetes的滚动更新策略需要配置健康检查否则会出现服务中断3. 工程质量保障体系3.1 测试驱动开发的实践反思项目中期引入TDD后代码质量显著提升。但真实情况远没有教科书描述的那么美好初期测试代码与实现高度耦合每次业务逻辑变更都要重写测试过度追求覆盖率导致大量无意义测试如getter/setter集成测试启动时间从30秒逐渐增长到8分钟严重拖慢开发节奏后来我们优化为分层测试策略单元测试核心算法/工具类覆盖率要求100%契约测试服务间接口使用Pact框架组件测试单个服务的完整功能E2E测试仅关键用户旅程3.2 代码审查的隐藏成本使用GitLab MR机制进行代码审查时发现了几个反模式LGTM式敷衍审查通过配置必须至少2人评论才能合并超大变更集现在强制要求单次MR不超过400行代码缺乏标准后来制定了《代码审查清单》包括是否包含适当日志错误处理是否完整数据库查询是否有索引支持是否考虑并发场景最意外的发现是约30%的缺陷是在代码审查讨论过程中作者自己发现的。这说明审查的核心价值在于促进思考而非单纯找错。4. 项目管理中的认知升级4.1 需求管理的血泪史初期采用纯敏捷开发结果陷入迭代地狱每个sprint都在做新功能技术债务越积越多。后来调整为混合模式产品路线图季度级别的目标规划双周迭代聚焦可交付成果每月1个技术冲刺专门处理债务需求变更的处理流程也经过多次优化graph TD A[变更请求] -- B{影响范围评估} B --|小变更| C[直接开发] B --|重大变更| D[需求评审会] D -- E[更新PRD/原型] E -- F[调整迭代计划]4.2 文档即产品的理念转变曾经认为代码即文档直到新成员花了三天才弄明白认证流程。现在我们要求OpenAPI规范的接口文档必须随代码更新架构决策记录(ADR)存放在docs/decisions目录每个服务都有README.md说明本地开发环境配置复杂业务逻辑必须添加代码注释特别是那些反直觉的实现最有效的文档是故障处理手册记录了历史上所有生产事故的现象描述排查过程根本原因修复方案预防措施5. 个人成长的关键收获技术能力提升只是最基础的收获更重要的是工程思维的建立成本意识现在评估需求时会计算开发成本人日运维成本服务器费用机会成本做A就不能做B风险思维重要变更一定会考虑回滚方案灰度发布策略监控指标用户视角日志和错误信息会站在用户角度思考这个错误信息能帮助快速定位问题吗需要联系客服时我们能否提供足够上下文最后给在校生的建议不要满足于能运行要用工程化的标准要求自己。我简历上最亮眼的不是这个项目的技术栈而是从零构建并维护了日均1000访问量的完整系统这样的工程实践经历。
