V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Recommended Services
Amazon Web Services
LeanCloud
New Relic
ClearDB
tianshunovel2
V2EX  ›  云计算

非得用微服务吗?

  •  
  •   tianshunovel2 · 358 天前 via Android · 7188 次点击
    这是一个创建于 358 天前的主题,其中的信息可能已经有所发展或是发生改变。
    一开始我用 go 写了个单体架构的小说网站。
    后来感觉业务流程没有梳理好,模型也有些乱,打算重构。
    研究了微服务,ddd 什么的,我的目的是能够在用户增加的情况下能够很方便的提升负载能力。
    但是我发现要划分好多微服务出来,但是就我一个人来开发,有必要弄得那么复杂吗?
    而且边界也不好划分啊,就怕到最后互相调用,性能下降不说,改动一个功能,可能就得改动好几个服务,部署好几次。

    能同时部署几个单体应用来负载均衡吗?
    或者在单体应用里,对某些路由实现微服务?
    如何监控到底是哪些接口占用资源高呢?
    29 条回复    2024-09-29 09:03:19 +08:00
    ruxuan1306
        1
    ruxuan1306  
       358 天前   ❤️ 8
    没必要,微服务的架构本质来自组织架构。
    Hurriance
        2
    Hurriance  
       358 天前
    认同一楼的,技术的演化并不完全来自技术本身
    frankies
        3
    frankies  
       358 天前 via Android
    没必要
    lovedebug
        4
    lovedebug  
       358 天前
    没必要,微服务和单体都有自己的场景,千万不要为了微服务而微服务
    gaobh
        5
    gaobh  
       358 天前 via iPhone
    等你有十万用户量再改微服务也不早
    BeijingBaby
        6
    BeijingBaby  
       358 天前 via iPhone   ❤️ 2
    单体够你用到项目消失😆
    hefish
        7
    hefish  
       358 天前
    楼上的大佬们说的对,根据自己需要来搞。合适够用是原则。
    est
        8
    est  
       358 天前
    微服务是用来 ppt 的东西啊。这玩意从概念到推广到实施都是一家软件外包公司发明的啊。。
    你没必要跟自己过意不去。
    CHUB
        9
    CHUB  
       358 天前 via Android
    这么说吧,以前我们组人多,每个人负责自己的模块,自己交自己的,开发速度嘎嘎快

    现在人也少了,项目也少了,偶尔会几个人都集中在同一个项目里干活,互相卡进度的时候想死,merge 的时候也想死,以及,维护老项目那一坨,改一个小的有很多个地方都要一起改,也很想死,有利有弊吧。

    省流:微服务适合很多个开发者一起干活的场景,人少单例完全够用。
    kuituosi
        11
    kuituosi  
       358 天前
    先搞明白什么是微服务
    不是用了微服务框架就叫微服务
    fregie
        12
    fregie  
       358 天前   ❤️ 4
    你需要的不是微服务,是容器化+无状态服务,要扩容直接加副本
    FrankAdler
        13
    FrankAdler  
       358 天前 via Android
    你这种,模块划分清楚就行了。规模大了,团队大了,涉及到不同研发(团队)负责不同功能开发,单独迭代单独发版啥的才是考虑拆分的时候
    blackeeper
        14
    blackeeper  
       358 天前
    一个人开发,没必要弄得这么复杂

    问题 1:可以,前面部署个 NG ,部署 N 个单体应用,然后负责均衡就可以了
    问题 2:你可以在 NG 上转发到你拆分的微服务应用
    问题 3:监控应用接口是多个层面的,要统计分析:有哪些接口,以及接口的 [调用频次,应用处理时间、SQL 处理时间、调用其它的时间、消耗 CPU 、内存,磁盘 IO]
    cheng6563
        15
    cheng6563  
       358 天前
    把表弄好一点就够了
    Kumo31
        16
    Kumo31  
       358 天前
    微服务不解决你说的负载能力问题
    pigspy
        17
    pigspy  
       358 天前
    单体架构足够你用到网站倒闭了
    codewld
        18
    codewld  
       357 天前 via iPhone   ❤️ 1
    微服务各模块独立自治,不会一坏皆坏,提高的是可用性,和负载能力没有直接关系。
    如果只是希望提升负载能力,应该考虑将服务改成无状态,然后按需扩容服务层。
    fgsqqq
        19
    fgsqqq  
       357 天前
    微服务 是使 单个服务 的业务内聚性更高
    不同的业务 放到不同的地方
    对系统解耦 维护扩展更高效

    当然 还得看项目规模 和复杂度
    小项目 或几个人玩的 可以不用
    大厂的 服务 基本上 微服务 因为 业务复杂,承接功能多
    抽取独立成一个 ,更易于 维护
    GeekGao
        20
    GeekGao  
       357 天前
    任何架构模式都是顾及了康威定律而设计的。一个人的项目不需要遵守这些复杂模式。
    Godjack
        21
    Godjack  
       357 天前
    当然不是非得用微服务,前些年掀起了一阵微服务热,我最近时不时会在 hacker news 首页上看到一些反思微服务的文章

    https://blogs.newardassociates.com/blog/2023/you-want-modules-not-microservices.html

    https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html

    > 后来感觉业务流程没有梳理好,模型也有些乱,打算重构。

    不管是否用微服务,都要把模块划分好

    > 研究了微服务,ddd 什么的,我的目的是能够在用户增加的情况下能够很方便的提升负载能力。

    单体架构也能「 方便」(对于你的小说应用来说应该够用了)提升负载能力。

    有时间的话可以看看这个 https://icyfenix.cn/architecture/architect-history/
    hangszhang
        22
    hangszhang  
       357 天前
    组织架构决定系统架构,你这就一个人,单体就好
    afeiche
        23
    afeiche  
       357 天前
    以前我们领导天天让我把系统改微服务,都让我顶回去,微服务部署、运维、监控都得有,要是公司不提供这些,自己搞折腾死了
    shellcodecow
        24
    shellcodecow  
       356 天前
    根据实际的情况出发,流量很一般 不需要自动横向扩容,什么微服务,容器化都没必要..

    不过既然你是用 go 我觉得可以学习下一些现成的框架..没必要自己研究这些,这些都是面向领导开发的
    me1onsoda
        25
    me1onsoda  
       356 天前
    回过头来看,很多微服务都是开发给自己简历贴金用的
    petergui
        26
    petergui  
       356 天前
    个人觉得是基于几层:
    1. 开发人员和项目的数量
    2. 流量特点, 热点服务(有多热?),热点路径
    把这些分析清楚了,自然就清楚微服务不微服务。 楼上说的对 你需要的是高可用。
    微服务架构本身提供的应该是多节点多服务隔离,管理,发现,扩展 等功能便捷性。
    xycost233
        27
    xycost233  
       355 天前
    估算一下你未来的用户规模,然后纵向切割,横向扩展,只要纵向切割得好,横向业务耦合度高一点问题也不大
    zx900930
        28
    zx900930  
       355 天前
    技术选型是服务实际需求的,如果你们预估的业务规模不会大规模横向扩张,没有多个项目组分开开发发版的需求,根本就没必要上微服务。
    danielxxx
        29
    danielxxx  
       86 天前
    14 年,后端开发 10 几个人。cto 和架构师都是新来的,上来就给原来.net 一顿重构成 java 微服务,当时微服务的 rpc 也不稳定,别说 springcloud 和 dobbo 了,那会儿 dubbo 没人用基本。
    于是领导自己搞了一套 rpc ,后端基于 ddd 开发,有 facade 层,开发只关心业务代码,controller 不用管,吭哧写了 2 年后来进了阿里内网,换成了 hsf 。
    所以有时候不是技术框架不合适,而是领导战略要求。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3777 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 19ms · UTC 05:09 · PVG 13:09 · LAX 21:09 · JFK 00:09
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.