在开发过程中，如何处理需求变更（如从1月第三期扩展到多期推荐，或增加单位类型筛选）？请说明敏捷开发流程、技术选型灵活性及版本控制方案。

1) 【一句话结论】需求变更时，按变更类型（紧急/常规）分类处理，通过敏捷迭代快速响应；采用微服务架构隔离变更影响，结合Git分支管理实现版本控制，并辅以自动化测试和灰度发布降低风险。

2) 【原理/概念讲解】老师口吻：首先，需求变更需按规模分类处理——紧急变更（如系统核心功能故障）通过紧急迭代（1周内完成），常规变更（如增加单位类型筛选）纳入下一个2周迭代周期。敏捷流程强调“迭代开发+持续反馈”，每个周期包含需求评审、开发、测试、上线，变更通过短周期循环快速响应。技术选型上，微服务拆分需权衡业务复杂度和调用频率，比如将系统拆分为数据服务（多期数据获取）、推荐服务（单位类型筛选逻辑）、界面服务（展示），拆分粒度避免过细（如每个功能独立服务导致调用开销大）或过粗（如一个服务包含多个不相关功能，变更影响范围大）。版本控制用Gitflow模式，特性分支开发新功能，合并后通过测试，确保版本清晰。自动化测试包括单元测试（覆盖核心逻辑，≥80%覆盖率）和集成测试（验证服务间交互，≥70%覆盖率），灰度发布步骤为K8s滚动更新，1%流量验证，指标达标后逐步增加。

3) 【对比与适用场景】

处理模式	定义	特性	使用场景	注意点
单体架构	整个系统为一个应用，代码集中管理	代码耦合度高，变更影响全局	需求稳定、模块较少的项目	需求变更时需修改整个系统，风险高
微服务架构	系统拆分为独立服务，通过API通信	模块解耦，变更影响局部	需求频繁变更、模块复杂的项目	需要服务治理（注册发现、配置中心），服务数量增加后运维难度提升（如Nacos配置管理、服务注册发现）

4) 【示例】初始需求：单体系统，API为 GET /recommendations?period=3 返回1月第三期数据。需求变更：扩展多期+单位类型筛选。处理：拆分为微服务，数据服务新增period参数，推荐服务新增unitType参数。版本控制：创建feature/multi-period-unit-filter分支，开发后合并到develop，测试通过后合并到main。灰度发布：K8s部署新版本，流量切分1%，监控指标（错误率<1%，响应时间<200ms）达标后，逐步增加至100%。变更后API请求：GET /data-service/recommendations?period=3&unitType=机关（数据服务返回多期数据，推荐服务处理单位类型筛选，界面服务展示结果）。

5) 【面试口播版答案】面试官您好，关于需求变更处理，核心是通过分类响应（紧急/常规）结合敏捷迭代，用微服务隔离影响，用Git控制版本。首先，按变更规模分类：紧急变更（如系统核心功能故障）通过紧急迭代（1周内完成），常规变更（如增加单位类型筛选）纳入下一个2周迭代周期。技术选型上，采用微服务拆分，比如数据服务（处理多期数据）、推荐服务（单位类型筛选逻辑），这样变更仅影响数据服务，不影响其他模块。版本控制用Gitflow，创建特性分支开发新功能，合并后通过单元测试（覆盖核心逻辑）和集成测试（验证服务间交互），再灰度发布（K8s 1%流量验证，指标达标后全量上线）。比如，增加单位类型筛选时，数据服务API新增unitType参数，开发后测试通过，灰度发布验证后合并到主分支。

6) 【追问清单】

• 问题1：微服务拆分时，如何权衡服务粒度？回答要点：根据业务复杂度和调用频率，避免过细（如每个功能独立服务导致调用开销大）或过粗（如一个服务包含多个不相关功能，变更影响范围大），比如数据服务负责数据获取，推荐服务负责逻辑处理，界面服务负责展示，符合业务边界。
• 问题2：灰度发布中，流量切分比例如何确定？回答要点：根据系统负载和风险承受能力，初期1%-5%流量，监控指标（如错误率<1%，响应时间<200ms）达标后，逐步增加至100%。
• 问题3：自动化测试中，单元测试和集成测试的覆盖率如何保证？回答要点：单元测试覆盖核心业务逻辑（如数据查询、单位类型筛选算法），集成测试覆盖服务间API调用（如数据服务返回数据后，推荐服务正确处理），通过CI/CD流水线自动执行，确保每次变更后测试通过。

7) 【常见坑/雷区】

• 忽略需求变更分类，导致紧急变更响应不及时，影响系统可用性。
• 微服务拆分过细，导致服务间通信开销大，维护成本高。
• 灰度发布步骤不明确，直接全量上线导致系统故障。
• 自动化测试覆盖率不足，变更后回归测试耗时，影响开发效率。
• 版本控制分支混乱，合并冲突多，影响开发进度。