多租户架构下共享微服务设计：垂直业务线代码解耦方案咨询

1. 公共代码抽离与版本化管理 #

• 把三个微服务中所有跨团队复用的公共逻辑（工具类、通用接口定义、通用数据模型等）从原微服务仓库完全抽离，独立成单独的公共组件仓库
• 公共组件采用语义化版本号管理，每个团队可根据自身需求选择兼容的版本依赖，无需强制跟随最新版本迭代，避免其他团队的公共代码修改直接影响自身业务
• 公共组件的变更只需要由指定的架构委员会（可从各团队抽调核心开发轮值）评审即可，无需所有业务线签字确认

2. 微服务边界拆分与权责划分 #

• 按照业务域归属重新明确三个微服务的责任团队：比如Customer MS归属用户相关业务占比最高的团队，Document MS归属文档业务占比最高的团队，每个微服务设置唯一的Owner团队
• 非Owner团队如果需要修改对应微服务的逻辑，优先通过接口扩展的方式实现：比如在微服务中预留可配置的扩展点、钩子函数，非Owner团队只需提交扩展逻辑的代码，由Owner团队负责评审合并，无需所有团队签字
• 如果现有扩展点无法满足需求，由需求方团队提交设计方案，和Owner团队单独评审即可，不需要拉上其他无关业务线确认

3. 分支策略优化 #

• 废除所有团队共用单一master分支的模式，每个微服务保留核心master分支作为正式发布分支，各业务线基于master拉取独立的长期特性分支，各自的迭代代码先提交到自身的特性分支，无需每次rebase最新master
• 只有当业务线需要上线正式公共版本时，才将自身特性分支的代码合并到master，合并只需要微服务Owner团队评审即可
• 各业务线独立的集群环境直接部署自身的特性分支代码，不需要和其他业务线的代码做强制同步，避免相互干扰

4. 接口兼容保障机制 #

• 所有微服务对外暴露的接口必须做向下兼容，禁止随意修改已有接口的入参、出参结构，必须修改时要先做新版本接口发布，通知相关依赖方逐步迁移，旧接口保留至少3个版本迭代周期再下线
• 每个微服务单独做自动化接口兼容性测试，每次代码合并前自动跑通用例，只要兼容测试通过，就不会影响其他业务线的正常调用，无需其他团队签字确认

内容的提问来源于stack exchange，提问作者Aditya Goel