V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
IamUNICODE
V2EX  ›  程序员

2024 年了,之前搞微服务的公司你们还好么

  •  
  •   IamUNICODE · 167 天前 · 19392 次点击
    这是一个创建于 167 天前的主题,其中的信息可能已经有所发展或是发生改变。

    新加入一个团队,应该是两年前开始搞微服务架构,组件大概有近 50 个,两个月我只看和改了其中五六个,数据流向交互完全不明白,大概是 grpc+emqx 通信,数据库有云端主库和每个用户自己的文件数据库,部署是妙云一把抓,我以为我只是项目不熟,结果上周有个小伙子,是全程跟了项目,应该对项目一草一木都熟悉吧,结果定位一个问题用了两天一夜,老实说之前参加过的最乱最复杂的项目都没有这么久才能定位问题,这是微服务通病还是只是这里没设计好?

    这种搞法有点看不懂啊,现在看起来唯一的好处是整个项目对研发的依赖相当高,什么都要研发参与才进行的下去,所以之前搞微服务的你们还好吗?

    129 条回复    2024-07-18 08:27:15 +08:00
    1  2  
    hidemyself
        101
    hidemyself  
       165 天前
    说一个暴论,如果项目用微服务能搞得定,那说明还不够复杂
    louisxxx
        102
    louisxxx  
       165 天前
    有在些公司是过度设计。一天在线用户没 100 个,微服务倒是有 100 个了
    yahon
        103
    yahon  
       165 天前
    并非是微服务不好,而是我们业务变化快,开发也得快。到后面还不如一把梭。至少开发快。
    bk201
        104
    bk201  
       165 天前
    啥架构都有利弊,所以要做取舍。收集面临的问题,具体问题具体分析。不要直接否定,但是手头又没替代方案,那叫内耗。还有如果没有问题,需要研发干嘛。
    knva
        105
    knva  
       164 天前
    有些业务就一个人
    NoobPhper
        106
    NoobPhper  
       164 天前
    做过服务治理的 尤其是 在架构新老交替的时候, 就知道有多难受了, 期间应该会被莫名背上很多锅吧
    silencil
        107
    silencil  
       164 天前
    有没有人能细致的聊聊微服务,你们接触的微服务都业务大到有几十个吗,还没接触过那么复杂的。
    IamUNICODE
        108
    IamUNICODE  
    OP
       164 天前
    @silencil 上面说上千的都有,相比之下我们这居然还算少的了
    silencil
        109
    silencil  
       164 天前
    @IamUNICODE 这是因为系统体量大,所以一个功能都拆分出了一个微服务,例如评论单独出个微服务这样吗?
    IamUNICODE
        110
    IamUNICODE  
    OP
       164 天前
    @silencil 以我的理解是不影响主业的情况下按大型功能挂出去,比如上面说的 B 站主业是视频,在不影响视频播放的情况下,把订单,支付,评论,弹幕挂出去,而且数据流向应该尽量单向可溯,除非大型功能有几十上千个,按理说不会有太多容器交互,但是现实是一个需求出一个,拆分法就很迷,加上神奇的数据交互方式,就更迷了。。
    leecher
        111
    leecher  
       164 天前
    @IamUNICODE 没有银弹,不过听你说的情况,应该是服务拆分问题。
    leegradyllljjjj
        112
    leegradyllljjjj  
       164 天前 via iPhone
    就像学生时代文科考试,不知道写什么,先把卷面写满,结果得分只有几分
    wtzwutianzhi
        113
    wtzwutianzhi  
       164 天前
    来一个微前端吧
    fengpan567
        114
    fengpan567  
       164 天前
    一个问题定位两天和微服务有啥关系,哪个服务出现问题不是一目了然?
    lysShub
        115
    lysShub  
       164 天前
    但是,定位一个问题一两天算快的了
    jackerbauer
        116
    jackerbauer  
       164 天前
    为了微服务而微服务,就是埋坑
    laoan
        117
    laoan  
       164 天前
    用法问题。
    你这个情况说不准是微服务最差实践。
    问 sa 要系统框架图和数据流图。
    有这两个就差不多能开整了。
    lsyAndroid
        118
    lsyAndroid  
       164 天前
    全链路监控有了吗?日志有了吗?系统监测有吗?排查问题的时候看不到调用栈,就难喽!梳理不出来整个调用链路,更难!
    kxg3030
        119
    kxg3030  
       164 天前
    @Features 做过 hyperf 的微服务 现在运行几年了 感觉你上面说的什么库不能用是伪命题
    8355
        120
    8355  
       164 天前
    微服务没有错,是你们过度的问题。。。
    archxm
        121
    archxm  
       164 天前
    @IamUNICODE 天降大任
    dyllen
        122
    dyllen  
       164 天前
    微服务小团队还是算了,增加好多工作量,直接模块化,多部署几台服务器比什么都好。
    archxm
        123
    archxm  
       164 天前
    @gazi 看完,我头都大了
    FYFX
        124
    FYFX  
       164 天前   ❤️ 1
    https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html
    想起来这篇文章,我看不少回复的意思是: 你们没有做好 Observability!
    Xiamu2663
        125
    Xiamu2663  
       164 天前
    业务到了一定复杂度和性能要求,微服务必须上啊。尤其是大型应用,玩集群和性能的。
    IamUNICODE
        126
    IamUNICODE  
    OP
       163 天前
    @FYFX 读完了,受益匪浅,谢谢
    Chinsung
        127
    Chinsung  
       163 天前
    微服务又和分布式是 2 个概念,许多人理解的微服务就是什么勾八小的领域都拆个服务出来,真不知道带来的分布式系统复杂度他们打算怎么处理的。
    你这个问题主要在于分布式配套的组件不够,排查人员的经验不足,排查手段受到团队基建影响。本质上这些是要 sre 团队考虑的。
    hekkowoerld
        128
    hekkowoerld  
       163 天前
    @ilvsxk 我推荐下 aws serveless 吧,真的好用,微服务注定是要被时代淘汰的东西
    dif
        129
    dif  
       163 天前
    装个 Pinpoint 之类的服务,微服务不都搭配 K8S 么,运维也方便,监控起来,那个服务出锅监控一目了然
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2196 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 00:57 · PVG 08:57 · LAX 16:57 · JFK 19:57
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.