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

• 資深大佬 : 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 ？

• 主 資深大佬 : vevlins

  @ihciah 最近也在了解这个概念。

• 資深大佬 : slyang5

  @swulling 你说的这些人都是 高素质的人 能比么

• 資深大佬 : swulling

  @vevlins

  如果单体服务划分好模块，需求都在各个模块内部，也不会有什么冲突，反而是对公共依赖的修改可以更容易的发现对其他代码的影响。

  单体服务也好，微服务也好，其实后面都是同样的设计方法。只不过微服务更灵活，难度也更大而已

• 資深大佬 : WispZhan

  典型的反模式。
  30+个 Service，每个 Service 就 3 个 Entity，这哪里有什么业务内聚了。

  合并，@swulling 的说法很对。

  μ 的架构演进，（在没有经验的情况下）合理的情况应该是从一个单体架构开始的。 因为在单体架构是你的业务在内部非常清晰，逻辑完整，内聚程度也相对较高。

• 資深大佬 : artandlol

  告别码农