crud + 微服务，如何解放重复劳动？

[vevlins]

三十多个服务多数都是 crud，一般每个服务的实体不会超过三个，实体之间相对独立。参与开发的人也很多，不仅重复劳动比较大，各个服务内的代码统一也是个大问题。

现在在考虑：

1. vscode 代码片段
2. 根据 rpc 定义和 sql ddl 更深一点的代码自动生成

你们在实践中有什么好的方案吗？

[dbskcnc]

protobuf 定义表，grpc 直接模块生成

[xcstream]

自定义 dsl 代码生成代码

[vevlins]

我再提供一个思路，可以利用元编程组装 sql，不过有弊端。

[1490213]

有较多人力，可以考虑低代码方式，使用 DSL，甚至是可视化网页加部分自定义代码的方式。
有少量人力，进一步封装一些框架代码。

[xizismile]

每个服务三个实体，不用拆这么细吧。。

[hooopo]

在做一个根据 db 结构自动生成 graphql 接口的服务

[Yuicon]

你这是什么鬼微服务

[fx]

@hooopo 老期待了, 可以付费

[hooopo]

@fx 卧槽？商机来了

[oneisall8955]

一个服务 3 张表左右，我去，感觉太神奇了。按业务模块划分一个业务三张表左右，这也太细了

[passerbytiny]

我注意到你说了“相对独立”，这样只有 crud 的话，大概现在还好，不出两个月就会出现大量数据不同步问题。
而如果完全独立，又都是重复工作的话，一百多个实体完全可以放到一个微服务中。

[dingyaguang117]

学习 django 制作脚手架框架

[swulling]

相信我，把三十多个微服务改成一个或数个大服务，才是正道。

过度微服务就是天坑

[xuanbg]

服务拆细本身没有问题，只要服务能够独立，不过度依赖其他服务就行。数据库我的建议是按领域拆分，不一定要一个服务一个库，可以多个相同领域的服务使用同一个库。

为什么同一个领域还要拆分服务，我的经验是为了平衡稳定性和灵活性。基本上是领域服务和管理服务拆开，领域服务负责稳定，发布后基本不动，管理服务负责灵活，可以随时迭代。而且这两个服务本来就是同一个业务，用的是相同的数据，你数据库怎么能不一样呢。

搞微服务不能教条主义，要按业务的实际需求来。

[xuanbg]

楼主这种情况我们开发过程中也遇到很多，这其实是一个代码规范的问题，如果像我们这种代码都是套同一个模板的话。复制粘贴改一改就是一个新服务了呀……

[yangxin0]

服务越多状态越多出错的概率越大。而且你搞为服务可以但是别拆成几十个 repo 啊。放在一个 repo 里面不就好了。

[slyang5]

@swulling 如果人多 开发一个大项目 简直是 灾难

[swulling]

@slyang5 几千人开发 linux kernel 也没见有啥灾难。

项目管理做不好，你拆分微服务是缘木求鱼，这不楼主就碰到问题了吗

[vevlins]

我对微服务的理解确实不深。解释下现状由来：

1. 我们是负责广告投放的，服务都是管理端使用的服务，有很多纯粹是小工具性质，比如管理预览白名单\媒体操作服务。
2. 开发的成员不专业，我们是前端组管理了 30+的 rpc 服务，对于服务拆分的思考可能不够，也有服务过大过于混乱的担心。
3. 版本迭代非常频繁且存在很严重的并行，因为我们是开发管理端不是对外服务，基本上是有需求就做，做完每周两个窗口发布。当然这跟管理制度有关，但我也没法解决。如果把多个功能放在一个服务，测试环境占用\git 管理冲突都很麻烦(巅峰时期一个服务有三四个需求同时开发和测试)，当然这也是技术上可以解决的，但是从人员现状来看，很难做。

大家在实践中对于微服务如何理解呢？一般有几个实体？如果不存在关联的实体（比如上面提到的预览服务和媒体操作服务）也会因为业务靠近放在一个服务内吗？

[ihciah]

faas ？