MuJianxuan
commented
2 years ago 好想法，目前这个也是我正在思考的问题，我的想法是 接口包放在当前项目中，不需要改变版本号，当我们启动当前功能分支的代码时，由于本地项目编译，不会加载远程的 api 包，因此可以启动成功；假设当前功能分支涉及到多个服务，如A 与 B，我们可以本地开发完 A 后，把 A 的 api 接口 install 到本地，这样，B刷新快照版本后，依旧能读取到A刚暴露的接口，此外，我们还可以麻烦一些，A 的api 接口开发，完成，做好测试，即合并到 dev 分支，并推送到远程，再去开发 B 服务功能依赖 A 的 api 接口，由于已经推送到远程，此时接口方法是可见的，当我们想本地启动 A 服务，即切换到功能分支后，本地编译，不回加载 dev 分支已推送到远程的 api；由于 rpc api 接口是必须要做实现的，因此我认为是不能像 http api 那样做成公共的模块包；在同一个项目。 非常感谢你的提问，让我知道会有人一起思考这个问题. 若是有好的建议，希望大家可以一起思考一下，一起得出最佳实践
qinglo
按推荐作法，在服务提供方和服务消费方间抽取公共api工程，服务消费方和服务提供方均依赖此api工程，在使用基于dubbo的微服务架构时，不可避免出现了服务互相调用的问题，会出现工程依赖于多个api工程。我们使用jenkins对所有api使用poll scm检测代码发生变更时将api自动打包到内网nexus私服。 使所有服务提供方及消费方均能顺便依赖这些api工程，当团队协作时，不可避免需要拉多个分支进行并行开发。此时api版本的依赖管理如何作？ 假设有分支dev及rel 两个分支的api均可能被修改，此时如果dev及rel分支的api版本号是不是应该区分开，两个分支的api设置不同的版本号吗，然后dev/rel均设置poll scm自动打包nexus,这样的话在代码合并的时侯不可避免带来版本号手工维护问题。请问有其它更好的方法吗？