@JoeDH 没人比我更懂售票！ 没！！！人！！！

请加速进入 “水深火热”。

@qxmqh 我们现在是有业务开发的时候。尽量做一些清理工作。太多太多功能了，其实可以不要的。这些僵尸功能不清除，要合并单体也是够麻烦的。

我们核心的功能是个人数据同步、社区、会员三个业务模块。但是却附着大量产品经理们的“快速实验功能”。

@kuanat 非常感谢老哥的经历分享！

我们的 common 库（基本等于工具库）也有类似你说的不一致问题。

1. 改动不兼容。依赖的地方迁移不干净。后来要求，尽量不做不兼容改动。实在要兼容，旧的别动，写个新的。扩展到本主题的常量、DTO 代码，也是这样的道理。不过这种事情，就怕人偷懒。一偷懒，埋下运行时的雷。

2. 这个 common 库，在各个业务 repo 里是以 git tag 的形式进行版本依赖声明的。类似你说的 ”对应的 commit“。但是因为各种“时过境迁”的原因，大家不得不共用一个测试环境。测试环境的代码，经常是开发分支合并在一起的。还有很多细节没必要展开来说。 总之最终导致，这个 common 库的 git tag 不对，在测试环境未必会暴露出来。基建支撑不足的弊端就体现在这里了。现在只能用千叮咛万嘱咐的方式，告诉大家。改了 common ，第一时间去升级依赖。

后续把常量代码也迁移到 common 库后，这样的问题依然会发生。不过，总比现在会好一些。现在的维护心智负担更大。

@183shl 这个方案的阻力就在这里。

我们其实有一个 common 库，里面放了一堆 utils 、架构 base 之类的代码。之前的 leader 强调，这里面不允许放入任何业务逻辑相关的代码。所以以前常量也没放这里。

团队的人会觉得改这里面的代码，还要去升版本，很麻烦。

有时候就直接在业务 repo 里，也写个 xxx utils 。


我觉得你说的最后一句是有道理的，复用很强的再抽到 common 。这样就比较平衡。偶尔一两次的依赖，就直接抄一遍。依赖次数多了，再抽到 common 。很明显一定会被依赖很多次的，一开始就直接写 common 里。

@sampeng 几乎没有 code review 。

说得难听点，现在最好的 "code review" 就是测试 + 一上生产环境就挂掉。没埋雷，半夜爆炸就不错。

所以，我才想多引入一下非人工的花销来尽量保证稳定。比如：

1. type hint 。有点作用。
2. 写 DTO 而不是一个 dict 满天飞。不然回头维护的时候很慢热，记不住 key ，经常导致 KeyError 。也算有点作用。
3. 常量共享而不是用到就“手抄”一遍，这种手抄还会抄错。


不怕各位笑话。我们还有一个“运行时的常量共享方案”是这样的：每个服务提供一个接口返回本服务的一些常量定义，然后服务启动的时候，去请求一遍这些常量定义。 我感觉是很难用。运行时、纯动态，你写代码的时候，根本不知道自己引用的值存不存在。IDE 也无法给你补全。

@iyaozhen 微服务是既定现状，前人拆分的，至少已经快 8 年了，暂时没资源去改回单体。

综合上面的回答，可能适合的方案还是服务的“常量”代码抽成一个包。

monorepo 倒是也可以。但是我感觉组员有时候写得很野，跨服务乱引用。综合来看，不太适用我们。

@Maboroshii grpc 可以上。但是需要共享的代码，不局限于 protobuf 描述的数据。

容器一定是有额外开销的。对于这种有状态的服务。用普通的容器化方案能更快、更好的实现高可用与高稳定性吗？我感觉弊大于利。

抛开服务负载谈这些都是无效讨论。我感觉面试官没把问题问好。

另外，就算是大厂，也有小负载、低价值的服务。那么也就没必要什么服务都上岗上线，这时候直接使用 docker/k8s 搭建一个 mysql ，这才是务实的做法。

还有云台监控也是，也有小毛病。再高级的东西倒是没买过了。

智能插头、塔扇（这个塔扇真是没什么大用）倒是没什么问题。