微服务之间，如何处理常量、DTO 冗余问题？

[justdoit123]

我们的微服务(都是 python3)，每个服务单独一个 repo 。在写一些跨服务的代码的时候，会遇到常量代码共享的问题。


比如，某个实体某字段的 flag 。这样的常量，在本服务的代码里，肯定是定义了一堆这个字段的 flag 。但是，到了另一个服务的时候，没有这些定义。以往都是在别的服务就地再写一遍。


我感觉这种做法实在是很不方便，而且很脏。

我的想法是，应该把这些没有什么逻辑的“常量”代码（不限于常量，还有各种数据封装的 class ）放在一个 repo 里，单独发包，让其它服务引用。至于是每个服务单独有一个常量库，还是所有服务共享一个常量库，则可以视情况而定。

想请教各位，这种做法如何？以及有没有更好的实践。感谢！

[Maboroshii]

protobuf 和 grpc 呗

[kapr1k0rn]

monorepo

[qxmqh]

换成单体。

[pxiphx891]

没写过 python ，不过 java 一直是这样的，打一个单独的包，所有人依赖这个包

[pigspy]

服务不多的情况下直接用 monorepo

[MIUIOS]

参考 java 暴露出 dto do vo 这些单独一个包，其他模块随便引入

[NoKey]

团队执行力强（盖的住成本）的话，搞公共包，内网搭 maven 仓，拉下来就能用，不过这需要额外的人力去维护这一套；一般的团队，重复写就重复写，要么就是相互复制，除了消耗人力，又不会怎么样😂

[justdoit123]

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

[justdoit123]

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

[justdoit123]

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

[blackmatch]

1.抽成一个公共包，各个服务引入调用即可。
2.做一个配置中心服务，所有服务统一读取同一份配置，做好更新和兜底策略。好处是修改配置不用发版，在配置中心改一下就可以了。

[patrickpu]

需要一个 common 的基础包

[iyaozhen]

一般是吧这些和 idl 绑定，idl （比如 pb 描述）生成这个仓库，各方来引用

不过怎么说呢，没必要强行微服务。特别是 python 。python 4 个服务一个分 1c 。还不如一起在 4c 的机器性能好

[sampeng]

你这就属于，想用微服务规范和隔离开发，但又已经看到微服务最大的蛋疼。
最好 code reviewer ，你说的问题都不是问题。monorepo 又不是想怎么写怎么写

[justdoit123]

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

[Rickkkkkkk]

common 包用起来其实没那么方便，远远不如代码里直接写一个 const 来的简单。

[justdoit123]

@sampeng 几乎没有 code review 。

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

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

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


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

[midsolo]

抽出来打一个 common 包，每个服务引入即可。

common/
├── inner/
│ ├── dto
│ ├── vo
│ └── ...
├── outer/
│ ├── dto
│ ├── vo
│ └── ...
└──

[183shl]

我的偏好是只把用到的或可能用到的再写一遍，可以硬编码的就直接写再放个注释。费点力气但是感觉体验很好。如果复用很强的再抽到 common ，因为不喜欢跳来跳去😁

[justdoit123]

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

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

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

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


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