微服务架构把系统拆成独立服务与独立发布节奏，代理的角色随之从"改一个仓库"变成"先理清契约与依赖，再在多个边界内并行实现并保证兼容"。本节聚焦协作方法与安全边界，不绑定具体框架的专有命令。
一、动手前先梳理依赖关系
- 识别服务边界：每个服务的职责、数据归属、对外接口与下游依赖。
- 区分通信方式：同步调用、异步事件/消息、共享数据存储；不同方式的兼容策略不同。
- 定位契约：请求/响应结构、事件结构、错误约定与版本策略，找出所有调用点与生产/消费方。
- 标注高影响面改动：跨服务契约、公共数据结构、鉴权与限流规则属于必须先规划的部分。
这一步优先交给只读探索能力完成，输出结构化影响清单（服务、调用点、兼容风险、测试缺口），作为后续分工依据。
二、契约兼容优先：向后兼容的演进顺序
| 变更类型 | 安全做法 |
|---|
| 新增字段/能力 | 提供默认值、保持可选，旧消费方不受影响 |
| 调整既有行为 | 先双轨或灰度，明确过渡窗口，避免消费方同时被迫更新 |
| 删除/重命名字段或接口 | 先确认所有消费方迁移完毕再下线，单独列为破坏性变更评审 |
| 事件结构变更 | 生产者与消费者解耦升级，确认旧消息兼容解析 |
三、分工与并行实现
- 主会话负责统一影响面清单、契约约定与验收标准；各服务在独立工作副本中并行实现（呼应第 11 章并行会话方法）。
- 对只读引入的相邻服务/共享契约目录，可用添加目录方式访问；默认不加载其个人规则，避免混淆作用域。
- 统一技术约定入库共享（错误处理、日志关联、超时与重试、幂等要求），让并行结果风格一致。
- 每个服务先补/跑自身单元测试；跨服务行为用少量契约级或集成级冒烟用例验证，避免只测单服务就判定成功。
四、发布、回滚与人机边界
- 采用小步、可灰度、可回退的发布节奏；代理产出变更说明、风险点与回滚建议，合并与发布决策由人确认。
- 安全边界上，无人值守自动化不应直接执行合并、发布与外部系统变更（呼应第 10、11 章权限原则）。
- 审查重点：超时/重试是否会放大级联故障、幂等性、失败路径、敏感数据是否外泄、错误信息是否泄露内部细节。
- 跨服务改动保留清晰变更记录与依赖版本关系，便于追溯问题来源与定位回归服务。
五、常见失败模式
- 只改提供方、不排查全部消费方，造成线上调用失败。
- 把破坏性变更当作普通小改直接上线，缺乏兼容过渡。
- 并行实现缺少统一契约约定，联调阶段才发现结构不一致。
- 用单服务测试代替集成验证，漏掉跨服务数据流与错误传播问题。
本节小结与下一节预告
本节明确了微服务协作中的契约梳理、兼容演进与并行安全边界。下一节讲遗留系统：如何先读懂、再保护、后渐进现代化，而不是盲目重写。