百川云璟 Java 后端实习一面：微服务改造与 AI 编码追问

《面试题目》

1. 请做一下自我介绍。
2. 实习时长多久？实习期间还要开组会吗？
3. 为什么要将单体项目拆分成微服务？是按功能还是按模块拆的？拆成了几个微服务？
4. 具体怎么把单体项目变成微服务项目的？
5. 购物车功能是在拆分之前就在单体里，还是拆分之后才做的？
6. 拆微服务是为了学习，还是单体已经无法满足项目需求？
7. 单体项目和微服务项目在开发过程中有什么区别？
8. 项目里用 Linux 和 Docker 部署，你有自己的服务器吗？
9. 你学过 Linux 吗？做过虚拟机吗？
10. 底层框架是学习包自带的，还是自己开发的？用户权限体系是原有代码还是自己写的？
11. 这个系统有几个角色？平台上总共分几个角色？
12. 这些角色当时是怎么设计的？
13. 权限体系由哪几个模块组成？
14. Nacos 在微服务里主要起什么作用？
15. MyBatis-Plus 和 MyBatis 有什么区别？
16. 你会前端吗？能接受全栈开发吗？会哪些前端技术？
17. 开发过程中用过 AI 写代码吗？大概多少代码是 AI 写的？基础 CRUD 是手写还是生成的？
18. 你觉得 AI 写的代码怎么样？两个人用同一个 AI，代码质量不一样，核心原因是什么？
19. 一个月大概用多少 token？花多少钱？
20. 反问环节。

《参考解析》

拆微服务要讲“边界”和“代价”，不能只讲“更先进”。 单体拆服务的正当理由通常是三件事：不同模块的发布频率和伸缩需求差异大、团队规模变大后代码所有权不清、单体的构建和故障隔离已经到了瓶颈。拆分粒度按业务能力走，而不是按 controller/service/dao 技术分层去切；购物车这种围绕用户购买链路的 capability 可以独立，但订单、库存、支付之间强一致的地方不能为了“看起来像微服务”硬拆。拆完的代价也要主动说：远程调用带来的网络失败、分布式事务、链路追踪、配置和部署复杂度都会上升。用购物车举例时，要能说清拆之前它依赖哪些表、拆之后用户、商品、价格这些数据从哪来，而不是只说“独立部署了”。

改造路径用绞杀者模式更容易讲清楚。 先在单体内部把模块边界和接口理出来，把跨模块调用收口到明确的服务接口；然后按优先级抽第一个服务，网关做路由，老代码继续跑，新流量逐步切过去；数据层先共享库、再按服务拆表，跨库一致性用本地消息表、事务消息或 Saga 这类可补偿方案，避免大爆炸式重写。Nacos 在这里承担注册中心和配置中心两件事：服务实例启动后注册、消费者按服务名发现实例，配置变更可以热更新；临时实例靠心跳保活，永久实例靠服务端主动探测。还要能说出它的边界——Nacos 解决的是发现和配置，不解决熔断、限流和链路追踪，那些要配合 Sentinel、网关和可观测性体系。

MyBatis-Plus 不是另一个 ORM，而是在 MyBatis 上做增强。 它保留了 MyBatis 的 SQL 映射能力，同时提供通用 Mapper、条件构造器、分页插件、逻辑删除、乐观锁等能力，简单 CRUD 可以少写 XML；复杂多表查询、窗口函数、特殊优化仍然应该写 XML 或原生 SQL。被追问时最好补一个坑：updateById 默认会忽略 null 字段，想清空某列要显式配置或写 SQL；逻辑删除后唯一索引、关联查询和统计口径都要跟着调整。权限体系则按“用户—角色—权限点”或“用户—角色—菜单/按钮/数据范围”来讲，认证解决“你是谁”，授权解决“你能做什么”，数据权限再单独一层，不要把三者混成一个角色字段。

AI 代码质量差异的核心不在模型，而在输入和验收。 同一个模型，给它的需求描述、上下文、约束和示例不同，产出会差很多；有没有把项目规范、接口契约、错误处理要求讲清楚，有没有让它先读现有代码再改，都会直接影响结果。更关键的是人有没有做 review、有没有测试和静态检查兜底。回答时可以讲自己的做法：小步生成、每步跑测试、关键路径手写、生成代码必须过 lint 和 code review；再用缺陷率、返工次数、线上问题这些指标判断 AI 是否真的提效。token 花多少不是质量指标，只能说明用量。