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

微服务的节点多了真的很不好么?宏服务是什么东西?

  •  1
     
  •   tctc4869 · 2020-09-28 10:36:19 +08:00 · 5197 次点击
    这是一个创建于 1499 天前的主题,其中的信息可能已经有所发展或是发生改变。

    今天看到这个

    https://my.oschina.net/DeveloperFront/blog/4651920

    新的专有名词被发明出来“宏服务”,这是什么东西?取代微服务的东西?微服务节点多了真的很不好么?

    各位的主管 web 项目,大了之后有没有考虑微服务,还是考虑过走“偏门”的方法?还是到时候看情况着来?

    33 条回复    2020-09-29 23:07:59 +08:00
    fx
        1
    fx  
       2020-09-28 10:40:51 +08:00
    维护痛苦
    leopod1995
        2
    leopod1995  
       2020-09-28 10:51:02 +08:00
    微服务的生长条件是,单机业务过于复杂 -> 拆成 n 套( n<10 -> 每套业务耦合太严重,开发效率降低-> 微服务(n>10 -> 维护成本太高-> 合并同类项 -> 服务减少(n<10 -> 起名宏服务(macro

    本质上还是业务和架构、开发效率、运维成本的综合考虑
    janxin
        3
    janxin  
       2020-09-28 10:55:23 +08:00
    上百个微服务你试试...然后每个微服务再 N 个节点,直接爆炸
    tctc4869
        4
    tctc4869  
    OP
       2020-09-28 10:57:48 +08:00
    @janxin 这样的话,那 几十个微服务节点怎么样?如果项目大了不走微服务,那还能走什么偏门的方向么?
    xx6412223
        5
    xx6412223  
       2020-09-28 10:59:37 +08:00
    传统企业就不合适用微服务,
    liuzhaowei55
        6
    liuzhaowei55  
       2020-09-28 11:20:48 +08:00 via iPhone
    单点故障,链式爆炸。
    wizzer
        7
    wizzer  
       2020-09-28 11:26:54 +08:00
    90%以上客户的项目,单应用足够了
    maichael
        8
    maichael  
       2020-09-28 11:38:46 +08:00   ❤️ 2
    架构和设计本身就没有银弹,不存在能适配所有场景的设计,总是想着一招鲜吃遍天是不可取的。根据你业务实际的需求来设计你的架构,用不用微服务都要贴合你的实际需求来决定。
    janxin
        9
    janxin  
       2020-09-28 11:46:28 +08:00
    @tctc4869 几十个范围比较广,如果 20 个微服务一般人手团队问题不会很大的。

    这个不是说微服务方向上有问题,而是其实整合部分微服务为宏服务在维护性上会好很多。
    sampeng
        10
    sampeng  
       2020-09-28 12:42:50 +08:00 via iPhone   ❤️ 1
    我早上才跟同事聊微服务弊端。设计架构的人要求太高。真按业务拆分。很容易写出 100 层调用代码。一次就算 1ms 。也要 100ms 。
    CODEWEA
        11
    CODEWEA  
       2020-09-28 12:46:46 +08:00
    会玩概念啊
    594duck
        12
    594duck  
       2020-09-28 12:58:37 +08:00 via iPhone
    当初我说为微服务不是银弹没必要,docker 更不是万能药。

    多少人喷我啊,多少人笑话我啊。v2 桑多少人和我吵啊。

    现在呢
    shineqaq
        13
    shineqaq  
       2020-09-28 13:01:25 +08:00
    就是不拆分,或者少量拆分
    594duck
        14
    594duck  
       2020-09-28 13:07:26 +08:00 via iPhone
    对 99%的企业来说做好 SOA 就够了。

    上微服务要么面向简历要么面向升职
    594duck
        15
    594duck  
       2020-09-28 13:13:29 +08:00 via iPhone
    @leopod1995 中间少了 SOA,很多公司其实上了 SOA 就解决了所有问题。

    只不过大部份技术人员为了恰饭,天天吹
    wangyzj
        16
    wangyzj  
       2020-09-28 13:22:11 +08:00
    @594duck #14 除了这个面向简历,面向升职,还有数字化转型
    tctc4869
        17
    tctc4869  
    OP
       2020-09-28 13:26:38 +08:00
    @janxin 服务拆分的话,不一定要完全按照为微服务的概念拆分把。不是还有 SOA 服务么?
    firefox12
        18
    firefox12  
       2020-09-28 13:37:14 +08:00
    @janxin 1000 多个微服务飘过,也就那样。没有规则的前提下是没办法管理的。
    ppphp
        19
    ppphp  
       2020-09-28 14:19:13 +08:00
    维护老项目总是很痛苦的,分拆也是要合理分拆人和业务
    Lighfer
        20
    Lighfer  
       2020-09-28 15:01:01 +08:00
    合理拆分就行
    我们的项目,数十个业务,每个业务都是一大功能,项目团队前中期 60 人左右(现 30 多人),单体应用的开发吃不消。
    踩的坑不少,但是团队成长起来后,开发效率和维护成本明显都比前一个大版本(单体应用)要好。
    前期是真的痛苦,踩的坑不计其数,效率低得吓人,调用链路的问题、监控、CI/CD 、事务、bug 排查、拆分方案等,很多,每一个环节都有坑要踩,当然不排除是我们团队太菜了,踩的坑比别人要多。
    尤其是想着第一次就作出完美的拆分方案,会越做越不合理。
    总之微服务的架构对开发人员的水平要求确实要高很多,但是只要能解决这些问题,并做好相关文档,微服务还是有其可取之处的。
    ArJun
        21
    ArJun  
       2020-09-28 15:03:18 +08:00
    微服务的利器是 K8s
    janxin
        22
    janxin  
       2020-09-28 16:01:09 +08:00
    @tctc4869 我的理解是微服务是 SOA 的一种落地实现方式
    Kirsk
        23
    Kirsk  
       2020-09-28 19:01:03 +08:00 via Android
    微服务不能提供效率用来装逼增加工作量? 项目适合什么就是什么 ddd soa 微服务 三缺一
    maigebaoer
        24
    maigebaoer  
       2020-09-28 19:15:15 +08:00 via Android
    类似于一个 App 拆分成 n 个模块,每个模块可以交给不同的人搞,并行开发。然而……以大多数厂子的沟通调试成本……
    shyangs
        25
    shyangs  
       2020-09-28 19:15:59 +08:00
    單點故障,鏈式爆炸.
    Mohanson
        26
    Mohanson  
       2020-09-28 19:17:36 +08:00
    等一个名词: 量子服务 /智能服务...
    index90
        27
    index90  
       2020-09-28 19:33:19 +08:00
    对微服务一知半解,道听途说就出来踩微服务架构。存在即合理,围绕着微服务架构的生态逐渐丰富和完善,真如你所说那么不堪,还能存在那么多年吗?

    所会拆出 100 层调用的那些人,根本没去了解微服务要解决的问题,为了微服务而微服务。

    ABC 三个模块,在巨石里面他们是三个互不相干的业务组件,其中一个升级会导致另外两个业务也会产生变更,其中一个代码有 bug,会影响另外两个业务程序正常运行。为了解决这个问题,才把他们拆开三个微服务。而不是因为 A 通过函数调用 B,B 通过函数调用 C,就把他们拆成微服务。
    xuanbg
        28
    xuanbg  
       2020-09-28 22:57:41 +08:00
    @594duck 现在也一样啊。微服务要做好是需要一些基石的,譬如 DevOps 、DDD 、Spring cloud,还有用户中心、账务中心、消息中心等业务无关的支撑服务。这些都是搞定了,就只剩下写写业务代码了。这样的微服务是很爽的,每个服务都很简单,开发快、上线快,并且易于扩展和维护。

    微服务的核心优势就是把系统复杂度从开发转移给了运维,而运维靠 docker 、CI/CD 、k8s 这些技术解决了开发甩过来的复杂度,所以大家都很快乐。但如果你没有能力搞定运维,就会被干趴下,于是微服务对你就不是什么好事了。在服务拆分上面也一样,拆得不好,维护起来比单体更麻烦。

    所以,是不是要上微服务,不是看规模大小,也不是看行业,而是看团队有没有这个能力。有能力就上,没能力就不要赶时髦硬上了。
    felixcode
        29
    felixcode  
       2020-09-28 23:19:53 +08:00
    宏服务的诞生是因为微服务助力互联网+后产生的生态化反。
    Tink
        30
    Tink  
       2020-09-28 23:25:42 +08:00 via Android
    大企业系统多的,还是 ESB 后期维护成本低一些
    tctc4869
        31
    tctc4869  
    OP
       2020-09-29 12:09:16 +08:00
    @Kirsk ddd 是什么?
    Kirsk
        32
    Kirsk  
       2020-09-29 13:53:41 +08:00 via Android
    @tctc4869 领域驱动设计
    firefox12
        33
    firefox12  
       2020-09-29 23:07:59 +08:00
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3375 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 38ms · UTC 11:35 · PVG 19:35 · LAX 03:35 · JFK 06:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.