V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
vevlins
V2EX  ›  程序员

crud + 微服务,如何解放重复劳动?

  •  
  •   vevlins · 2020-04-17 17:19:33 +08:00 · 4033 次点击
    这是一个创建于 1666 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    现在在考虑:

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

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

    25 条回复    2020-04-19 15:18:28 +08:00
    dbskcnc
        1
    dbskcnc  
       2020-04-17 17:30:45 +08:00
    protobuf 定义表,grpc 直接模块生成
    xcstream
        2
    xcstream  
       2020-04-17 17:32:30 +08:00
    自定义 dsl 代码生成代码
    vevlins
        3
    vevlins  
    OP
       2020-04-17 17:45:37 +08:00
    我再提供一个思路,可以利用元编程组装 sql,不过有弊端。
    1490213
        4
    1490213  
       2020-04-17 17:56:42 +08:00 via Android
    有较多人力,可以考虑低代码方式,使用 DSL,甚至是可视化网页加部分自定义代码的方式。
    有少量人力,进一步封装一些框架代码。
    xizismile
        5
    xizismile  
       2020-04-17 21:31:04 +08:00 via Android
    每个服务三个实体,不用拆这么细吧。。
    hooopo
        6
    hooopo  
       2020-04-17 21:35:44 +08:00 via Android   ❤️ 1
    在做一个根据 db 结构自动生成 graphql 接口的服务
    Yuicon
        7
    Yuicon  
       2020-04-17 22:00:36 +08:00
    你这是什么鬼微服务
    fx
        8
    fx  
       2020-04-17 22:00:44 +08:00
    @hooopo 老期待了, 可以付费
    hooopo
        9
    hooopo  
       2020-04-17 22:02:12 +08:00 via Android
    @fx 卧槽?商机来了
    oneisall8955
        10
    oneisall8955  
       2020-04-17 22:09:08 +08:00 via Android
    一个服务 3 张表左右,我去,感觉太神奇了。按业务模块划分一个业务三张表左右,这也太细了
    passerbytiny
        11
    passerbytiny  
       2020-04-17 22:15:00 +08:00
    我注意到你说了“相对独立”,这样只有 crud 的话,大概现在还好,不出两个月就会出现大量数据不同步问题。
    而如果完全独立,又都是重复工作的话,一百多个实体完全可以放到一个微服务中。
    dingyaguang117
        12
    dingyaguang117  
       2020-04-18 00:50:31 +08:00
    学习 django 制作脚手架框架
    swulling
        13
    swulling  
       2020-04-18 01:04:45 +08:00 via iPhone   ❤️ 2
    相信我,把三十多个微服务改成一个或数个大服务,才是正道。

    过度微服务就是天坑
    xuanbg
        14
    xuanbg  
       2020-04-18 04:04:39 +08:00   ❤️ 1
    服务拆细本身没有问题,只要服务能够独立,不过度依赖其他服务就行。数据库我的建议是按领域拆分,不一定要一个服务一个库,可以多个相同领域的服务使用同一个库。

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

    搞微服务不能教条主义,要按业务的实际需求来。
    xuanbg
        15
    xuanbg  
       2020-04-18 04:07:54 +08:00
    楼主这种情况我们开发过程中也遇到很多,这其实是一个代码规范的问题,如果像我们这种代码都是套同一个模板的话。复制粘贴改一改就是一个新服务了呀……
    yangxin0
        16
    yangxin0  
       2020-04-18 06:56:20 +08:00 via iPhone
    服务越多状态越多出错的概率越大。而且你搞为服务可以但是别拆成几十个 repo 啊。放在一个 repo 里面不就好了。
    slyang5
        17
    slyang5  
       2020-04-18 07:13:01 +08:00
    @swulling 如果人多 开发一个大项目 简直是 灾难
    swulling
        18
    swulling  
       2020-04-18 08:16:11 +08:00 via iPad
    @slyang5 几千人开发 linux kernel 也没见有啥灾难。

    项目管理做不好,你拆分微服务是缘木求鱼,这不楼主就碰到问题了吗
    vevlins
        19
    vevlins  
    OP
       2020-04-18 12:53:01 +08:00
    我对微服务的理解确实不深。解释下现状由来:

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

    大家在实践中对于微服务如何理解呢?一般有几个实体?如果不存在关联的实体(比如上面提到的预览服务和媒体操作服务)也会因为业务靠近放在一个服务内吗?
    ihciah
        20
    ihciah  
       2020-04-18 12:53:32 +08:00 via iPad   ❤️ 1
    faas ?
    vevlins
        21
    vevlins  
    OP
       2020-04-18 13:00:57 +08:00
    @ihciah 最近也在了解这个概念。
    slyang5
        22
    slyang5  
       2020-04-18 21:23:14 +08:00
    @swulling 你说的这些人都是 高素质的人 能比么
    swulling
        23
    swulling  
       2020-04-18 21:57:23 +08:00 via iPhone
    @vevlins

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

    单体服务也好,微服务也好,其实后面都是同样的设计方法。只不过微服务更灵活,难度也更大而已
    WispZhan
        24
    WispZhan  
       2020-04-19 09:21:48 +08:00
    典型的反模式。
    30+个 Service,每个 Service 就 3 个 Entity,这哪里有什么业务内聚了。

    合并,@swulling 的说法很对。

    μ 的架构演进,(在没有经验的情况下)合理的情况应该是从一个单体架构开始的。 因为在单体架构是你的业务在内部非常清晰,逻辑完整,内聚程度也相对较高。
    artandlol
        25
    artandlol  
       2020-04-19 15:18:28 +08:00 via Android
    告别码农
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   943 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 20:58 · PVG 04:58 · LAX 12:58 · JFK 15:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.