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

难道所有项目都要滥用中间件吗?

  •  
  •   csw3983931 · 2023-07-28 16:32:51 +08:00 · 6868 次点击
    这是一个创建于 485 天前的主题,其中的信息可能已经有所发展或是发生改变。

    首先本人是一个 Java 程序员,Java 生态还是比较周全的,像注册中心,配置中心,日志收集,调用链追踪,分库分表等等。

    但是我心中突然有一个疑问,为什么一定要用上这些东西,真的有必要吗?比如说注册中心,没有一定的用户量,或者不是容器化,搞什么注册中心? nginx 转发不是根据高效?还有配置中心?又不是几百上千个应用,才几个应用上什么配置中心。

    我发现很多小的创业公司,上来就是搞什么微服务,真的有必要?难度不是徒增资源的成本和维护成本?

    我觉得任何中间件都是对应困境中而产物,如果没有遇到这些困境,为了用而用,是不是纯粹的在炫技?

    65 条回复    2023-08-04 11:29:42 +08:00
    jjjjjokerrrr
        1
    jjjjjokerrrr  
       2023-07-28 17:00:18 +08:00
    感觉还是得分情况看:
    1. 你认为这个业务之后用的人会很多

    2. 你认为这个业务之后会噶了
    jjjjjokerrrr
        2
    jjjjjokerrrr  
       2023-07-28 17:01:22 +08:00
    第一种情况,考虑后续服务扩展是有必要的,第二种情况是不是不做了比较好 xD
    csw3983931
        3
    csw3983931  
    OP
       2023-07-28 17:11:18 +08:00
    @jjjjjokerrrr 你说的情况 1 ,我觉得用的人会很多,这个跟单机服务,然后模块的拆分并不影响吧。
    我觉得大多数初创公司都是人手不住,要大量需求迭代,微服务只会让发版本和处理业务常见更加复杂和麻烦,当然现在 Java 程序员可以说基本都会一些中间件。但是个人觉得越少越好。
    lisxour
        4
    lisxour  
       2023-07-28 17:16:10 +08:00
    你说的是对的,不管什么量级,总有无脑去搞微服务的
    redial39
        5
    redial39  
       2023-07-28 17:17:13 +08:00
    只要你确定当业务越来越发展以后,你的项目越来越多以后,运维天天来找你麻烦给你小鞋穿以后不会有 "当时应该上配置中心,现在不至于这么狼狈" 的决心的话..你就可以一个 jar 走天下
    coderxy
        6
    coderxy  
       2023-07-28 17:26:25 +08:00   ❤️ 2
    你说的有一定道理,其实如果只是要求够用的话,一台单机跑个 jar 就可以对外提供服务了。
    但是很多程序员是按照自己的习惯来的,很多原来一直用微服务体系用惯了,你突然让它搞单机应用,他不一定能快速适应。
    所以,只要开发者认为自己是在以较低的成本快速展开业务就是最正确的方案。 有没有微服务都可以是最正确的方案。
    wangxiaoaer
        7
    wangxiaoaer  
       2023-07-28 17:27:07 +08:00   ❤️ 1
    是的,有一点过度设计的感觉了。 之前看过一个帖子说到自己 04 年左右开发的一个 Java Web 应用,打包成 jar 格式,这么多年过去了,jre 环境满足的话可以分分钟部署上去就欢快的跑起来了。

    现在随随便便搞个什么应用不搞几个微服务都跟瘫痪了一样,更有甚者 p 大点应用还他么上 k8s 的。
    wu67
        8
    wu67  
       2023-07-28 17:29:05 +08:00   ❤️ 8
    每次说到业务发展到什么量级我就想笑.
    大部分人写的项目, 可能巅峰时期也就千把人同时访问, 甚至很多是个位数访问, 讲什么微服务呢...
    极端一点, 可能很多公司倒闭了, 这个项目的同时访问量也上不了几百人.
    更极端一点, 可能没几年, 因为技术栈老旧难以维护, 又招了一批人来开一个新的项目推倒重来了

    题外话, v 站这摸鱼大站, 网站底下的在线人数, 此刻是 4833
    kamalei
        9
    kamalei  
       2023-07-28 17:32:37 +08:00   ❤️ 1
    不用,你下一份工作怎么吹。
    csw3983931
        10
    csw3983931  
    OP
       2023-07-28 17:58:25 +08:00
    @redial39 我觉得项目越来越多,这是一个因素,到达一定量后必然会增加人手,然后服务拆分,然后再考虑是否引进微服务的中间件。
    csw3983931
        11
    csw3983931  
    OP
       2023-07-28 18:00:24 +08:00
    @coderxy 我觉得一直没有使用过微服务的程序员去写微服务的项目会有压力,有微服务经验的程序员,写单体应该是有一种如释重负,很轻松的感觉,因为考虑的场景少了,比如分布式事务,任务调度中心,一致性等等
    csw3983931
        12
    csw3983931  
    OP
       2023-07-28 18:02:21 +08:00
    @wangxiaoaer 是的,依赖的太多中间件,导致重新部署一套,无论是成本还是资源都是要 copy 一份,而且一旦漏了一个环节,就可能无法正常运行。属实感觉微服务要慎重
    csw3983931
        13
    csw3983931  
    OP
       2023-07-28 18:04:46 +08:00
    @wu67 是的,我感觉中国大多数初创企业都是这样的现状。而且单体服务优化的好,机器和资源跟上,几十万的用户量还是轻轻松松的。
    coderxy
        14
    coderxy  
       2023-07-28 18:06:59 +08:00
    @csw3983931 很多业务开发,只是习惯与在某个框架下开发。 比如习惯了使用(甚至只使用过) spring cloud 的框架,然后各种组件都是用现成的。 你让他去写单机,他不一定能很快适应。

    微服务不是啥高阶功法,只是一种技术方案而已,过度仰视或鄙视一种技术方案,都是不合理的心态。 只有当一个技术人员,可以游刃有余的使用任何一种技术方案完成业务时,他才能真正的根据业务需求,选择最合适的技术方案。

    不然假如你不会微服务,然后跟公司其它同事说我们不需要微服务巴拉巴拉。 其它人嘴上不说,心里肯定吐槽。
    lambdaq
        15
    lambdaq  
       2023-07-28 18:11:18 +08:00
    。。。。。php python ruby 就是这样从当年 J2EE 抢的市场份额啊。。。你以为呢。。。。。
    pengtdyd
        16
    pengtdyd  
       2023-07-28 18:17:19 +08:00
    因为面试的要求,面试的时候向面试官展示自己华丽的造火箭能力能更容易的从应聘者中脱颖而出。如果不这么做,其实是会在就业市场中被淘汰。
    wu00
        17
    wu00  
       2023-07-28 18:19:32 +08:00
    都说缺点,我来说优点
    - 拿公司项目练手
    - 降低解释成本,避免给老板、同事解释为什么咱们没有用这些专业的、高大上的、牛逼的新技术
    zsdroid
        18
    zsdroid  
       2023-07-28 18:57:04 +08:00
    如果项目中不用,面试问到了一问三不知怎么办?
    tomatocici2333
        19
    tomatocici2333  
       2023-07-28 20:12:47 +08:00
    没办法 现在你的项目不是分布式,你都要改成分布式的...不然简历这关都过不了 hr
    paradoxs
        20
    paradoxs  
       2023-07-28 20:17:50 +08:00
    这些东西很水,没一个稳定的发展方向。 所以现在程序员的就业环境才显得这么的难。 因为没有东西可以量化你的能力。
    LeegoYih
        21
    LeegoYih  
       2023-07-28 20:22:10 +08:00
    让你写单机应用,你又会嫌弃没技术含量。
    kingjpa
        22
    kingjpa  
       2023-07-28 21:09:14 +08:00
    其实绝大部分应用 实时用户量都不会上万。
    agagega
        23
    agagega  
       2023-07-28 21:11:39 +08:00 via iPhone   ❤️ 1
    分享一下这篇文章,如果你是做自己的项目,真没必要上分布式那一套徒增复杂度: https://ruby-china.org/topics/39735

    > 随着越来越多的人们意识到对于微服务的追逐会走上一条死胡同,“钟摆将会再摆动回来“。“雄伟巨石”在这儿等待着微服务的“难民”。如果他们确实做到了大型应用程序的规模,那么“城堡”这种可以扩展的模式足以让你安心。
    xuanbg
        24
    xuanbg  
       2023-07-28 21:18:51 +08:00
    几行命令的事,有什么维护成本?
    hooych
        25
    hooych  
       2023-07-28 21:28:17 +08:00
    各大云厂商都有现成的产品可以接入,用户只需要关注业务服务即可。
    James0
        26
    James0  
       2023-07-28 21:54:00 +08:00
    因为你可能还不熟悉使用,或者公司基建太辣鸡
    winglight2016
        27
    winglight2016  
       2023-07-28 23:13:23 +08:00
    如果 lz 试过开发一个长期运行使用,并且需要经常修改维护的系统就明白为什么要上配置中心、容器化、微服务了,一切都是为了可维护性、稳定性。
    Ericcccccccc
        28
    Ericcccccccc  
       2023-07-29 01:10:56 +08:00
    好, 假设你不用配置中心, 那你实现相关功能要怎么做呢?

    (最后变成自己实现了一个配置中心?
    wushenlun
        29
    wushenlun  
       2023-07-29 01:22:02 +08:00
    用现成方案才是最节省成本的 ,自己手搓代码可劲折腾去吧
    IvanLi127
        30
    IvanLi127  
       2023-07-29 01:54:47 +08:00 via Android
    我说个比较极端的话,有一部分公司,尤其是小公司选 java 做技术栈本身,就是为了招人省事,开发省事,所以如果用上了很多对程序本身没多大益处,反倒是很累赘的组件,也可能是出于省事。

    反正现在硬件成本低了,堆一堆东西,性能差点加配置就是了。。。我感觉追求程序简约高效的开发者,应该不怎么会选中 java 了吧。。。
    Bingchunmoli
        31
    Bingchunmoli  
       2023-07-29 02:59:56 +08:00 via Android
    有可能是你做了可以买 20 万不做不能宣传集群微服务什么话术只能买 8000
    qinxi
        32
    qinxi  
       2023-07-29 08:41:24 +08:00 via iPad
    我们的主服务现在就是单 jar 跑,今年收入应该有几千万了
    我们的 global 团队是微服务。不过国内版本目前不打算用,没必要
    ikas
        33
    ikas  
       2023-07-29 08:58:52 +08:00
    原因=>垃圾公司垃圾老板垃圾人
    cquan
        34
    cquan  
       2023-07-29 09:42:54 +08:00
    被迫卷的
    laozhoubuluo
        35
    laozhoubuluo  
       2023-07-29 10:02:43 +08:00
    1. 有的需求提供方对自己预期比较高,例如觉得自己能冲用户量或者以后要学习微信搞大而全。需求侧定了调子之后架构必然要按照需求来实现。比如定了个用户数或者交易量一年冲千万、三年破亿的指标,不搞服务拆分可能才是架构失职。
    2. 如果您是面试官,在现在这个大环境下没有微服务、注册中心应用经验的中高年资员工您会考虑录用么?如果大多数面试官都不考虑的话,那也别奇怪大家为啥要往微服务、注册中心上靠拢了。
    learningman
        36
    learningman  
       2023-07-29 10:45:42 +08:00 via Android
    threads 还是 python 写的呢,优化啥啊
    silentsky
        37
    silentsky  
       2023-07-29 12:06:18 +08:00 via Android
    单体应用确实没必要 如果两个服务以上那肯定需要这些 又不是什么很难的东西
    silentsky
        38
    silentsky  
       2023-07-29 12:10:09 +08:00 via Android
    配置中心没你说的不堪 比如你想动态改一些配置不用重启服务生效 就很有用。有些敏感数据放在配置中心肯定更安全些
    evalcony
        39
    evalcony  
       2023-07-29 12:20:46 +08:00
    1. 提高招人门槛。
    2. 招聘的双向选择。水平好一点的人看你们还是个单体应用,可能就不乐意过来了。
    agdhole
        40
    agdhole  
       2023-07-29 12:30:44 +08:00
    某个游戏平台公司流水过亿,所有东西都是单机撑住,没有任何高级的架构,甚至连专业运维都没有。所以单机其实是很强大的。
    leegradyllljjjj
        41
    leegradyllljjjj  
       2023-07-29 13:40:09 +08:00
    我微服务容器化 k8s 都上了,怎么没人来访问啊,老板你说句话呀
    没有淘宝的命得了淘宝的病
    salmon5
        42
    salmon5  
       2023-07-29 16:17:53 +08:00
    你说的对的,不搞这些怎么搞 KPI 呢?怎么拿公司联手呢?反正代价也是公司付出。
    大多数人在一个公司也就 1-2 年,练完手,拍拍屁股就走了
    bigbrother
        43
    bigbrother  
       2023-07-29 16:31:45 +08:00
    为了写简历啊
    daimubai
        44
    daimubai  
       2023-07-29 16:37:09 +08:00
    嗯,其实单体项目完全足够了的,再加两台服务器部署个集群也完全可以的。
    nkidgm
        45
    nkidgm  
       2023-07-29 17:07:53 +08:00
    其实很多玩微服务的人连单体应用都还没玩明白。。。
    ClericPy
        46
    ClericPy  
       2023-07-29 17:26:51 +08:00
    没有三年以上运维给你支撑, 用任何第三方中间件都是在给接手的人添乱

    尤其是连服务治理都不做的情况下滥用微服务, 年份越大灾难越重
    angryfish
        47
    angryfish  
       2023-07-29 17:36:47 +08:00
    如果后端开发就 3,5 个人的话写微服务拆分得太细会很痛苦。对于小公司,从公司角度还是建议一个单体 jar 走天下。
    但对于个人发展,当练手吧。
    brookegas
        48
    brookegas  
       2023-07-29 20:53:19 +08:00
    这已经是公开的秘密了
    其实道理都懂,以用户量来看根本用不上注册中心、分库分表这些花活
    但是大家都这么玩,把简单的应用工作量放大了好几倍
    好处是经济上行时多了几倍的码农岗位,高薪摸鱼乐无边
    坏处是拉低了效率,经济下行时企业死得快,码农跟着一起堕入深渊
    ashuai
        49
    ashuai  
       2023-07-29 21:10:14 +08:00
    公司去投项目,项目一般不大,2C4G 的物理机足以支撑,但那帮不懂的麻瓜好像感觉中间件用得越多越牛 x 。搞安全的都不知道缩哪去了
    jiangzm
        50
    jiangzm  
       2023-07-29 21:22:06 +08:00
    小公司上微服务倒不一定有问题,就怕瞎拆分几个人能拆 10 几个服务,除了浪费资源也没太大实际好处。
    xuanbg
        51
    xuanbg  
       2023-07-29 21:45:01 +08:00   ❤️ 1
    微服务从来没有说要多少用户量才值得上,微服务主要解决的是系统复杂度的问题。解决量的问题,是分布式系统的事,只不过微服务天然就支持分布式而已。

    所以,只要系统比较复杂,哪怕只是为了能够方便维护和扩展功能,只要会用一些 devOps 工具,譬如会简单使用 k8s 来解决运维领域的问题的话,微服务就是最好的解决方案,没有之一。

    我上个月接了个活,才 6w 。如果我从无到有给他搞单体服务,估计 2 个月才能搞得定。而采用微服务方案,上线时间就变成 20 天了。
    tin3w5
        52
    tin3w5  
       2023-07-29 22:37:32 +08:00 via iPhone
    格局小了,你只是从你的角度来看,他是个小微企业,从老板的角度来看,万一以后要扩容呢?客户量大了,需要拆的时候再重写?
    与其未来 capacity 不足的时候手忙脚乱的拆服务,不如初期设计的时候就做好,免得以后麻烦。
    咱们都是搞技术的,没必要过多干涉上面的决策。他们搞多大项目,咱们要多少钱,只要钱到位,什么花活咱都会。
    diagnostics
        53
    diagnostics  
       2023-07-29 22:48:12 +08:00
    因为留有扩展的余地吧,拿基金头部的软件恒生来说,他们的 o32 也是单体,和你们的思路一样,单体做到极致,后果就是:

    1. 很多功能没法加,代码已经非常庞大了
    2. 扩展性非常差,只能一直堆最好的硬件

    1 、2 都导致了很多功能做在其他系统,导致恒生和其他第三方厂商做的系统没啥区别。

    恒生自己也在做 o45 ,然后就落后别人了,很多券商也在做去恒生化了。当然未来可能不一定

    所以,为什么要搞这些?当然小公司,没发展空间就可以没必要了,另外其实新技术挺方便的,尤其是 有一套 k8s 对于开发来说,测试非常方便,压测也很方便。
    olaloong
        54
    olaloong  
       2023-07-29 23:18:54 +08:00 via Android
    都是成熟的东西,使用成本没你想得那么高,顺手就用上了
    真等后期需要了再改,那成本可高多了
    akira
        55
    akira  
       2023-07-30 00:20:35 +08:00
    你要是说小的创业公司的话,那可以 php 一把梭 验证商业模型
    去到一定量级以后再用 java 整体重构
    snBDX1b0jJM4ogKd
        56
    snBDX1b0jJM4ogKd  
       2023-07-30 01:38:34 +08:00 via Android
    有没有可能,对他来说,一个 jar 就默认搞定了这些东西,部署也是驾轻就熟。
    如果因为项目太小,非要让他重新搞一个精简的出来,他的工作量可能更多。那不是另一个角度的过度设计?
    jdOY
        57
    jdOY  
       2023-07-30 03:16:35 +08:00
    老板说要什么你就搞什么
    gejun123456
        58
    gejun123456  
       2023-07-30 09:37:04 +08:00
    没必要,小公司弄单体应用就行,做大做强再优化
    murmur
        59
    murmur  
       2023-07-30 10:07:15 +08:00
    中间件就是 tomcat ,你不会连这个都不知道吧
    murmur
        60
    murmur  
       2023-07-30 10:07:27 +08:00
    更正:tomcat 就是中间件的一种
    salmon5
        61
    salmon5  
       2023-07-30 10:24:22 +08:00
    @murmur #59 现在几乎都是 springboot ,至于 tomcat 还是 undertow 都被弱化了
    murmur
        62
    murmur  
       2023-07-30 10:48:34 +08:00
    @salmon5 等到国产化的时候就想起来了,to b ,to g 跑不掉这个,还得用东方通之类的东西给 tomcat 换掉
    lanlanye
        63
    lanlanye  
       2023-07-31 02:06:52 +08:00
    优点当然也是有的:

    1. 可以练手,不然你下一份工作的简历怎么办?
    2. 容器化管理起来确实容易,哪怕我就俩服务,用 k8s 也方便些,至于你说消耗的资源……那是老板的钱,又不是我的。
    3. 战未来,万一火了呢?
    4. 微服务不仅能拆分大型软件,还能方便拆分团队,如果一个项目有很多个组参与,使用微服务会比写成单体然后让大家工作在同一个仓库下容易些……同理,如果前提是没几个用户,进程内通信和跨进程通信相比那点优势也微不足道。至于额外的复杂度,k8s 也基本能解决,没几个用户的项目又能复杂到哪儿去呢?
    javaZhenJuan
        64
    javaZhenJuan  
       2023-08-04 11:28:18 +08:00
    @qinxi 大佬您是做什么业务的
    javaZhenJuan
        65
    javaZhenJuan  
       2023-08-04 11:29:42 +08:00
    @salmon5 说到点子上了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1146 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 18:14 · PVG 02:14 · LAX 10:14 · JFK 13:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.