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

微服务的意义是什么?例如获取商品信息或者处理支付的服务挂了整个商城不照样用不了

  •  1
     
  •   edis0n0 · 2023-03-12 14:55:41 +08:00 · 4729 次点击
    这是一个创建于 399 天前的主题,其中的信息可能已经有所发展或是发生改变。
    37 条回复    2023-03-14 08:39:04 +08:00
    seakingii
        1
    seakingii  
       2023-03-12 15:06:30 +08:00
    微服务,又不是只运行一个实例,会运行 N 多个实例,挂了一个,其它的先撑住,挂掉的自动修复
    微服务需要一整套的工具来辅助服务治理的,包括部署,监控等等
    最大的好处,在我看来是职责单一,以及由职责单一带来的附加好处,比如小团队,易扩展,多语言等等
    hyuka
        2
    hyuka  
       2023-03-12 15:08:34 +08:00 via iPhone
    1.如果是支付挂了,这种应该只是支付不了其它不影响
    2.微服务单个服务出问题只需要解决这一个服务的问题,重启回退修 bug,整个服务分成若干服务后肯定比回退重启整个服务要好
    3.不同人负责不同微服务,不用关注整个项目的细节,只需关注自己负责的部分的细节以及相关交互

    大概想到这些。
    工作中,尤其线上的服务都是=(不让随便动的,服务不划分全扔一块,出问题了重启或者部署整个大服务,想想就头大。改动越小越好。
    edis0n0
        3
    edis0n0  
    OP
       2023-03-12 15:10:54 +08:00
    @hyuka #2 划分的很细的话部署起来也头大
    hyuka
        4
    hyuka  
       2023-03-12 15:11:03 +08:00 via iPhone
    服务挂了,也是
    多个实例,单个挂了其他可以先撑住,要是因为请求多还可以通过添加实例的方式暂时处理
    lhx2008
        5
    lhx2008  
       2023-03-12 15:13:59 +08:00
    从开发角度来说,一两个人开发只需要单体,十个人开发就要微服务了,要不然怎么调怎么发版
    hyuka
        6
    hyuka  
       2023-03-12 15:14:00 +08:00 via iPhone
    @edis0n0 这就是度的问题了,划分的合理,部署问题就还好。我工作过的几个公司,服务都是越来越大,微服务就很有必要。

    但是嘛,你说的也是存在的问题,合理划分也不容易。
    chloerei
        7
    chloerei  
       2023-03-12 15:15:04 +08:00
    可以增加工作岗位。
    qiyuey
        8
    qiyuey  
       2023-03-12 15:18:19 +08:00
    领域隔离,控制整体的熵,避免软件危机
    hhjswf
        9
    hhjswf  
       2023-03-12 15:20:49 +08:00 via Android
    重点是微。相比单体,业务模块粒度更小,拓展更方便。比如秒杀这样负载比较大的,可以多部署几个,负载小的少部署几个
    nullpoint007
        10
    nullpoint007  
       2023-03-12 15:21:50 +08:00
    微服务化应对海量并发的, 你说的单点故障也可以通过微服务的多副本解决, 微服务部署的话也不用担心, 现在的 CICD 技术已经很多开源成熟系统
    xuanbg
        11
    xuanbg  
       2023-03-12 15:21:57 +08:00
    @edis0n0 自动化运维了解下,几百上千的服务也和一个服务一样部署。
    hhjswf
        12
    hhjswf  
       2023-03-12 15:22:12 +08:00 via Android
    @seakingii 单体也可以这么做,这不是微服务的特权
    leonard916
        13
    leonard916  
       2023-03-12 15:23:59 +08:00
    微服务是为了高可用提出的,也是因为有些项目过大,维护和启动都很麻烦,而且过于吃资源,不方便扩展等。
    sujin190
        14
    sujin190  
       2023-03-12 15:26:45 +08:00 via Android
    真正的大型电商系统,获取商品信息和处理支付就已经 n 个微服务了,然后并不会一起挂,也并不会是同一个部门维护,你说有用没用
    seakingii
        15
    seakingii  
       2023-03-12 15:27:39 +08:00
    @hhjswf 我上面说了好几项,请明确说明什么不是微服务的特权
    wangxiaoaer
        16
    wangxiaoaer  
       2023-03-12 15:46:15 +08:00
    微服务容易走火入魔,瞎捷豹分,不要为了微而微,然后原本事务性质的内容再通过微服务通信绕一圈,给部署带来了很大复杂度,尤其是业务量本身 不大的情况。比如网上很多例子商品、订单、库存等等,这几类量上去了才有分的必要。
    而支付、用户体系等本身就是业务相对独立,采用微服务是比较合理的。
    kaedea
        17
    kaedea  
       2023-03-12 16:14:13 +08:00 via Android
    一座大💩山 vs 一堆小💩山堆叠的大💩山
    dqzcwxb
        18
    dqzcwxb  
       2023-03-12 16:22:23 +08:00
    分而治之
    AyaseEri
        19
    AyaseEri  
       2023-03-12 17:47:03 +08:00
    分治之后维护与扩张起来方便啊,而且团队扩张也方便,还能成立更多的开发组,任命更多的组长。
    byte10
        20
    byte10  
       2023-03-12 18:02:13 +08:00   ❤️ 1
    基本概念不扎实:
    1 、楼上还有说集群、多实例。
    2 、还有说为了 高可用提出的。
    分布式服务跟集群多实例 没有必然的关系。高可用方案一般是多实例的方式解决,多实例也可以提升系统的吞吐量。

    关于微服务其中一个挂了,并不是整个商城都无法使用的。比如支付服务挂了,那么整个系统就会出现 服务降级,但是你还是可以继续加入购物车,可以继续浏览商品,继续给商品评价等。其实字面意思都是很简单的,语文的阅读理解是一个非常重要的能力,不然很难理解 服务降级是什么意思。

    比如:你去饭店,你可以体验饭店 美甲的服务。但是口罩的问题,你只能打包走人,那么整个饭店服务就降级了,没啥特别难搞。

    当然微服务的好处还是很多的,楼上很多回答都描述到了。
    dobelee
        21
    dobelee  
       2023-03-12 18:19:50 +08:00
    有没有一种可能,支付服务挂了,还可以搜索和查看商品。
    而一座屎山挂了...
    v2lf
        22
    v2lf  
       2023-03-12 18:24:17 +08:00
    业务隔离,弹性伸缩
    nvideo
        23
    nvideo  
       2023-03-12 20:31:59 +08:00
    高并发
    laravel
        24
    laravel  
       2023-03-12 20:44:12 +08:00
    挂的概率比起单体程序来如何?
    ch2
        25
    ch2  
       2023-03-12 21:05:49 +08:00
    鸡蛋不放在一个篮子里的道理
    salmon5
        26
    salmon5  
       2023-03-12 21:09:38 +08:00
    @xuanbg #11 "自动化运维了解下,几百上千的服务也和一个服务一样部署。"
    乱说,实际中完全不一样
    tohuer00
        27
    tohuer00  
       2023-03-12 22:06:17 +08:00   ❤️ 1
    纠正一个错误观念,微服务不是用来解决高业务量的,是用来解决高业务复杂度的。
    copper20
        28
    copper20  
       2023-03-12 22:12:31 +08:00
    从开发的角度来说,如果你见过光 bean 就有十几万个,连编译脚本都需要专人维护的大屎山,那微服务存在的必要性应该也不用解释了。

    至少你一次吃的是一个小山包,而不是一次得吃一座山脉
    panxiuqing
        29
    panxiuqing  
       2023-03-12 22:34:08 +08:00 via Android
    是为了解决软件工程的问题。
    我觉得服务降级也不是微服务相对单体有明显区别的地方,除非有问题会导致所有实例同时异常且无法重启,但是这种故障对于无状态服务不应发生。
    xiaop1ng
        30
    xiaop1ng  
       2023-03-12 23:45:30 +08:00
    说一个我实际工作中的应用场景,将并发要求更高的接口剥离出来为一个单独的微服务,在部署的时候该服务可以部署更多的副本
    yagamil
        31
    yagamil  
       2023-03-13 03:01:12 +08:00
    我的理解是 把系统拆分成一个个的 HTTP API 接口?
    之前所呆的企业业务并不是太复杂,而且项目也是一次性的,不会被别人或者其他项目调用。 而参与的开发也就几个人。

    没有必要为了微服务而微服务。
    acctv2
        32
    acctv2  
       2023-03-13 07:56:53 +08:00 via Android
    @yagamil 单体不也是拆分 HTTP API 吗
    WashFreshFresh
        33
    WashFreshFresh  
       2023-03-13 10:21:42 +08:00
    支付挂了,还能查看商品信息,商品信息也挂了,还能查看订单状态喝物流信息。

    大致就是这么个意思。
    nothingistrue
        34
    nothingistrue  
       2023-03-13 11:17:58 +08:00
    微服务下,商品信息挂了就是商品信息挂了,支付挂了就是支付挂了。非微服务下,哪里挂了都是商城挂了。当你的目标是解决问题——首先找出那里出了问题(进而解决问题),而不是没有问题——首先保证不出问题(为此将锅甩给全员,甚至掩盖问题),的时候,微服务就是有意义的。反之自然无意义。

    技术不是脱离于生活的,微服务、敏捷开发、Scrum 、看板、Issue 方式的任务 /缺陷跟踪方式,等等老外传过来的东西,你得结合老外的办事风格,才更容易理解。一个比较经典的就是 ISO9001 质量体系当中的 BUG 数量,你如果不知道老外更看重发现和解决 BUG 的能力,而不是零 BUG 的能力,就很难理解老外为啥会把 BUG 数量当作质量体系的正向指标。
    yc8332
        35
    yc8332  
       2023-03-13 14:24:03 +08:00
    微服务可能对大厂有用。小厂纯纯浪费钱,也没那么多人
    yagamil
        36
    yagamil  
       2023-03-14 08:33:36 +08:00
    @acctv2 对,所以微服务是不是只是改个高大上的名字??
    acctv2
        37
    acctv2  
       2023-03-14 08:39:04 +08:00 via Android
    @yagamil 我的意思是 HTTP API 和微服务概念没啥太大联系,正常代码都是拆分成一个个 API 接口。

    微服务和普通单体应该就是是否独立部署的区别
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2710 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 15:13 · PVG 23:13 · LAX 08:13 · JFK 11:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.