tom

1 个固定分支：

- **master**：主分支。所有的 feature 和 bugfix 分支都从该分支创建。该分支受保护，不允许直接向该分支提交代码

3 个短期分支，完成功能开发之后需要删除：

- **feature/\***：功能分支。用于开发新的功能，不同的功能创建不同的功能分支，功能分支开发完成并自测通过之后，需要合并到 master 分支，之后删除该分支
- **bugfix/\***：bug 修复分支。用于修复不紧急的 bug ，普通 bug 均需要创建 bugfix 分支开发，开发完成自测没问题后合并到 master 分支，之后删除该分支
- **release/\***：发布分支。用于代码上线准备，该分支从 master 分支创建，创建之后发布到测试环境进行测试，测试过程中发现 bug 需要开发人员在该 release 分支上进行 bug 修复，所有 bug 修复完后，在上线之前，需要合并该 release 分支到 master 分支。release 分支可以长期保留

1 楼 @florentino 说的“本质就是通过 http 调用,至于你说的 VO,DTO 那些东西,可以放在 api 里面让其他服务依赖,也可以不放,调用方自己实现,反正最后都是会被序列化和反序列化的”

以及 4 楼 @123zouwen 说的“我觉得这是把单体思维代入到了微服务中. 分布式事务中间件个人觉得没有任何必要, 但很多 java 总希望能跟写单体服务一样直接 rpc 调用还能处理好事务.”

都非常对，是非常正确的微服务理念。基本上你从网上看到的绝大部分理论，都是指导你灵活使用，因为脱离了实际使用场景，并不会存在一个最佳实践。

而你困惑的地方在于，你没描述出来你们完整的工程场景，上面他们所说的都不足以解答你的疑惑，feign 用起来总是感觉有点不伦不类，对不对

我猜你是做 toB 的行业软件，业务逻辑复杂，功能点多，架构师又采用微服务形式，然后甚至一个功能模块一个微服务，从功能划分上倒是合理，但是呢，各模块之间的交付是很频繁及复杂的，互相调用的情况非常多， 硬套上微服务， 很难复用代码 & 控制事务， 如果各自解析 feign 的返回，还容易造成混乱（各种业务逻辑频繁变动、数据模型满天飞， 有些对象能有 200 多个属性）。

我是非常不建议也不喜欢大部分 toB 业务使用微服务开发的，不合适。

当然你们已经这么做了，我的建议是，各自模块的 DTO 、VO 、等 POJO ，自行维护。需要被其他模块调用的，复制一份 POJO 到 api 模块中，写好文档，做好代码同步即可。这样调用方不用关心如何解析，调用结果会自动转换为 POJO 对象，省心省事，又贴合单体应用的使用习惯。

有条件的话，还是从微服务的巨坑里爬出来吧。

@israinbow 这个小屏幕和支架能推荐一下吗？

过段时间再出个超级 vip

不止搜索难用，在收件箱下新建文件夹时，输入名称，回车，100%崩溃

堆屎山、维护屎山

mac 版打开即常驻菜单栏，能否增加一个开关，允许不在菜单栏显示&不常驻后台？

arco-design
https://arco.design/vue/docs/start