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

今天被组长好心提醒了下,不要过度设计,有点疑惑,问一问大家,大家理性发言

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

    事情是这样的 目前做的一个项目,一个微服务,俩节点,配了一个微服务注册中心配置中心集群 consul 为什么这么做,一方面是为了监控服务状态,虽然是只有一个服务,但也是个微服务,俩节点,另外就是刚学习了 consul ,想实践一波 这个算过度设计了不,欢迎大家讨论

    第 1 条附言  ·  188 天前
    其实今天的事情已经有结果了,就是去掉额外的注册中心,想跟大家讨论下,同类事情的边界在哪里,现在看来应该是具体的业务场景,不能为了技术尝鲜给项目带来较大风险,遇到这样问题应该是自己思考下到底有没有必要,意见相左还得讨论下
    第 2 条附言  ·  188 天前

    大家讨论的都挺好,不过呢,真当我组长不逛V站啊,不用回这么快吧,:cry:

    102 条回复    2021-12-22 13:29:32 +08:00
    1  2  
    daiwenzh5
        1
    daiwenzh5  
       188 天前
    看情况吧,如果服务器资源充足的话,实践一下未尝不可。
    bwensun
        2
    bwensun  
    OP
       188 天前
    @daiwenzh5 站在我角度上,我肯定是想试试的
    z740713651
        3
    z740713651  
       188 天前   ❤️ 11
    大佬这叫简历驱动开发
    daiwenzh5
        4
    daiwenzh5  
       188 天前
    @z740713651 真实
    bwensun
        5
    bwensun  
    OP
       188 天前
    @z740713651 雀食,作为开发不在生产上用过,解决问题,怎么能说会了呢 狗头
    hidemyself
        6
    hidemyself  
       188 天前
    借楼问一下,微服务一般都是里面所有的服务都是自己开发吗
    zoharSoul
        7
    zoharSoul  
       188 天前
    刚学习了 consul ,想实践一波
    ospider
        8
    ospider  
       188 天前
    组长说的对,你要想试一下,自己搞个环境玩玩儿就行,生产环境哪儿能上自己刚学会的东西啊,万一出问题了谁解决?再者,你这俩节点确实用不上啊……
    daiwenzh5
        9
    daiwenzh5  
       188 天前
    @hidemyself 当然不是,你只需要关注自己业务所在的微服务,其他的可能是其他同事在开发,也可能是公司已经有的产品,或者第三方的
    FantaMole
        10
    FantaMole  
       188 天前   ❤️ 11
    其实挺多时候,让你不要过度设计的另一个想表达的意思就是,你这么搞,项目可能做不完,控制好项目工时,别给我瞎搞
    bwensun
        11
    bwensun  
    OP
       188 天前
    @ospider 嗯 能理解他说的 但是这个 consul 就算出问题也在我也能及时处理呀 正常来说哪有不出问题的嘛 不能为了追求绝对的稳定 放弃任何尝试的机会呀 俩节点雀食用不上 狗头
    bwensun
        12
    bwensun  
    OP
       188 天前
    @FantaMole 正所谓 将在外 军令有所不受
    bwensun
        13
    bwensun  
    OP
       188 天前
    Nich0la5
        14
    Nich0la5  
       188 天前   ❤️ 7
    10 楼说得对 公司是雇你干活的不是雇你整活的,也不是每个公司都愿意消耗成本让员工学习
    bwensun
        15
    bwensun  
    OP
       188 天前
    @Nich0la5 理解 一般你们怎么处理 继续做自己的还是追求稳定
    wellsc
        16
    wellsc  
       188 天前
    注册中心这么关键的东西,两个节点还少了呢
    bwensun
        17
    bwensun  
    OP
       188 天前
    @wellsc 注册中心三个节点 但是微服务俩
    k9982874
        18
    k9982874  
       188 天前
    你点个蛋炒饭,厨师给你来个鲍鱼炒饭顺道练练手,再收你 100 不过分吧
    masterclock
        19
    masterclock  
       188 天前
    生产环境用什么不是应该组长或者更上面的领导决定吗?
    bwensun
        20
    bwensun  
    OP
       188 天前
    @k9982874 没收 100 哦 都是一样价格 维护也是我来呀
    bwensun
        21
    bwensun  
    OP
       188 天前
    @masterclock 是的 这个后面也改回来了 但是引发我的思考 想问问兄弟萌都是怎么处理这样问题的呢
    Nich0la5
        22
    Nich0la5  
       188 天前
    @bwensun 我 leader 对我就一个要求 别延期, 实践起来就是开发文档之外的事情尽量不要做(不然我还有时间在 v 站吹逼吗),骚操作可以做,但是要放到下一期评审里面评估一下是否有意义。稳定性其实是其次的,如果没被毙掉就可以做,想不毙掉就得证明你这么改动的价值。像这个任务,你自己都说明不了它的必要性,评审怎么能通过呢。
    br_wang
        23
    br_wang  
       188 天前   ❤️ 8
    组长这么说可能是他觉得「杀鸡用牛刀,后面你要是不维护了我还得替你擦屁股」。所以,如果你不是只是一时兴起,可以把基于这个架构的中期计划跟他聊聊,明确下后面的路线和规划,可能会好一点。

    老板怕得不就是「不确定性」么。让他了解你的意图和你有计划就好。别着眼于当前状况的解释。
    sujin190
        24
    sujin190  
       188 天前
    java 这一套的话,反正更新重启一下十分钟过去了也不止,所以两个节点也想用注册中心也可以理解,否则真没啥必要,否则节点数比较少服务也少也搞似乎是个坑,大炮打蚊子可不但没提高生成效率反而坑死人的了
    zliea
        25
    zliea  
       188 天前
    就一个微服务?我是组长,我也不想让你搞; 10 个微服务再搞吧。
    Ackvincent
        26
    Ackvincent  
       188 天前
    能用就行了,好歹给后边人留点空间。
    charlie21
        27
    charlie21  
       188 天前 via iPhone
    别延期是可以的
    Cielsky
        28
    Cielsky  
       188 天前 via Android
    @ospider 永远不上那永远学不会啊,这不是死循环了
    bwensun
        29
    bwensun  
    OP
       188 天前
    @Nich0la5 嗯 基本想法一致 说明必要性这块可有的说(我以前在警校写报告拿满分--黎明)另外我觉得新的东西出来自然有它对于传统的东西的优势,我们不应该向前看嘛 很多时候只是习惯于某某而不是真的有足够大的理由停留在之前的样子 我不是说我现在说的项目 就是说在我们工作中
    Mogugugugu
        30
    Mogugugugu  
       188 天前
    你离职了,谁来接手?
    bwensun
        31
    bwensun  
    OP
       188 天前
    jtwor
        32
    jtwor  
       188 天前
    反手加个网关上个鉴权中心全上 grpc 弄个 elk 日志中心搭套容器编排自动部署 狗头)

    其实这些一堆中间件学习难度一般,基本搭一次就大概懂了,如果工地的业务不大没必要上微服务,基本都会否决使用的,学习和维护都是需要成本的,不是所有公司都愿意投入。还是自己项目练练,后面跳大点公司把,如果是开源的最好看看源码,学习是学习,搬砖是搬砖。
    joyhub2140
        33
    joyhub2140  
       188 天前
    跟着团队走。。。商业项目不是试错场地,除非有人负责。。。
    bwensun
        34
    bwensun  
    OP
       188 天前
    @Mogugugugu 那这不得看人嘛 说走提包就走呀
    bwensun
        35
    bwensun  
    OP
       188 天前
    @br_wang 嗯嗯
    nbndco
        36
    nbndco  
       188 天前   ❤️ 37
    非常严重的过度设计。



    有人说这种东西需要组长决定,或者公司不是来让你学习的,反而不应该是考量因素。大家天天问怎么提升薪水,你天天就乖乖听组长分配的任务堆 CRUD ,其他不闻不问不学习,真的能加薪吗?

    真正关键的是,你要解决什么问题,以及如何解决问题。

    就你描述的情况本身,一个服务两个节点,看起来也不像是会有很大的增长的样子,那么就不存在 service mesh 的应用场景。也就是说,你没有解决任何问题,只是单纯的引入了一个新的(大)问题——设置管理维护 consul ,组长只是提醒你不要过度设计,也是有问题的,要是我就直接让你全撤了。你要意识到,你的实践一定是实践如何用 consul 解决问题,不是使用 consul ,你要用 consul 你自己搭个 k8s 就好了。

    所以这样做就没有意义么,也不是。这就取决于你要解决什么问题。

    你说你现在做的是一个微服务,那就意味着公司里有很多其他的微服务。你说你在使用 consul ,那就意味着公司现在并没有任何的 service mesh 方案,考虑到 consul 和 k8s 绑定之紧,我甚至可以猜测整个公司的服务部署都是完全独立各组自行管理的。这显然是一个错误的方案,缺乏正确微服务架构的特性。那么,要不要提升,要不要改,要不要用 consul ,我觉得是很值得考虑的。

    有人肯定又要说这种事情推不动,大家都只想堆 CRUD 。那我也没啥可说的,这个时候我只能反省为何我会加入这种公司了。
    Bigglesworth
        37
    Bigglesworth  
       188 天前
    还好,也不是完全没用
    pigspy
        38
    pigspy  
       188 天前
    我们这边,微服务调用链啥,整体部署结构,都要经过评审,不允许自己随便弄
    这样也方便出问题甩锅
    RudyS
        39
    RudyS  
       188 天前
    任何事都应尽量简单,但不宜过于简单。---爱因斯坦
    otakustay
        40
    otakustay  
       188 天前   ❤️ 21
    摘录一下 Google 选择引入一个依赖时的决策条款,用于对任何技术做还是不做的评估都有用:

    - 是不是有测试,并且使用者可以自己跑起来测试
    - 测试是不是通过的
    - 谁开发的这个库
    - 承诺怎么样的兼容性
    - 作者有没有详细地说清楚这个库期望用在什么场景下
    - 这项目有多流行
    - 我们大概会有多长时间要依赖这个包
    - 在历史上这个包搞出来破坏性变更的频率是怎么样的
    - 我自己来实现这个依赖的功能的话有多复杂
    - 让这个依赖保持版本跟进是不是必要的
    - 以后谁来更新依赖的版本
    - 这个依赖的版本更新难不难
    zliea
        41
    zliea  
       188 天前
    偷偷的说一下,前边有 nginx 的话,可以开启 nginx 的 upsteam 健康检查与 check_status 。
    lbp0200
        42
    lbp0200  
       188 天前   ❤️ 1
    你的利益是 搞 consul ,刷简历
    你组长的利益是 工期延迟的风险,回头给你擦屁股的风险,他确什么都得不到

    另外,你自己也说了,只是“就是刚学习了 consul ,想实践一波”,组长说过度设计,只是很委婉的说法,用不到的技术暂时先收起来
    shyrock
        43
    shyrock  
       188 天前
    你这岂止是过度,简直就是过度。

    虽然我也鼓励部门的技术人员多学习和实践新技术,但这是在部门资源可控的范围之内。
    如果你在自己负责的资源之内,自己能承担责任,想上新技术,搞一些试验和学习,毫无问题。
    你现在的问题是,自己想学习,责任由组长担。。。说得过去吗?
    bwensun
        44
    bwensun  
    OP
       188 天前
    @shyrock 不是 不是由组长承担 最终也是我来处理的 就相当于这个项目我负责
    lingo
        45
    lingo  
       188 天前
    你只是在拿公司的生产环境做自己的学习工具。。。
    这么设计对这个项目有啥好处么。没有的话只是为了你的学习而提高复杂度,这不是过度设计是啥。
    loading
        46
    loading  
       188 天前
    无缘无故提高项目复杂度,你组长没错。
    实践项目可以自己玩,没必要带到生产环节。
    Jooooooooo
        47
    Jooooooooo  
       188 天前
    过度设计增加理解成本, 增加系统复杂度, 增加工期. 如果看不见足够好处, 确实少做.

    你这么干已经是负面印象了, 如果看重绩效 /涨薪, 最好调整一下
    bwensun
        48
    bwensun  
    OP
       188 天前
    @nbndco 说的很有道理,技术确定应该由场景来决定,我们这边类似于项目交付,并非是针对产品,emm ,只是今天发生这件事情,我想到了别人也应该遇到过,想看看大家是怎么想的
    bwensun
        49
    bwensun  
    OP
       188 天前
    @Jooooooooo
    @lingo OK 明白
    Biwood
        50
    Biwood  
       188 天前
    这种显然是需要提前跟 leader 说一声,如果是对技术细节不怎么过问的 leader , 可能就不管你,随你折腾,但懂技术的 leader 肯定不会轻易让你把生产项目当做试验场的,至少他需要有知情权,不然出了问题他是要承担责任的。

    说真的,除非是你们团队本身就有对新技术积极拥抱的文化,否则还是自己私下玩玩算了。
    Rorysky
        51
    Rorysky  
       188 天前
    过度设计的本质,你是拿着成品的组件去堆服务,而不是从整体架构上定制实现。
    bwensun
        52
    bwensun  
    OP
       188 天前
    其实今天的事情已经有结果了,就是去掉额外的注册中心,想跟大家讨论下,这件事情的边界在哪里,现在看来应该是具体的业务场景,不能为了技术尝鲜给项目带来较大风险,遇到这样问题应该是自己思考下到底有没有必要,意见相左还得讨论下
    shyrock
        53
    shyrock  
       188 天前   ❤️ 1
    @bwensun #44 如果项目你负责,就不存在组长打回来的说法。你只是执行者而已,不是决策者。
    sjzjams
        54
    sjzjams  
       188 天前
    只是会用那就用吧,遇到问题我再告诉大家
    A555
        55
    A555  
       188 天前
    一个服务,两个节点上注册中心干嘛用 😅
    fregie
        56
    fregie  
       188 天前
    不用会造成问题吗?在未来可见范围内会有问题吗?如果答案是否定的,就算是过度设计了。
    bwensun
        57
    bwensun  
    OP
       188 天前
    @A555 嘿嘿
    nicebird
        58
    nicebird  
       188 天前   ❤️ 1
    拿公司项目做实验呢,多试几次估计会被开。
    goofylp
        59
    goofylp  
       188 天前
    @bwensun 增加复杂度就是增加成本,站在团队的角度肯定是要尽量避免过度设计。另外用个 consul 很难说会给你简历有多少加分,只是个工具。至少我看简历写“熟练使用 XXX”只会减分,我会更看中实际业务上你用技术解决了哪些实际问题,再小的项目都能找到值得设计的点。其实你能综合分析一下,然后说最后没有使用 consul ,那绝对是更吸引面试官的 case 。
    A555
        60
    A555  
       188 天前
    @bwensun #57 或者你可以给领导画大饼,以后公司的服务都迁移到微服务架构,接入 consul
    总之不能为了用而用,要有规划
    darkengine
        61
    darkengine  
       188 天前
    虽然出了问题你来解决和维护,但是从组长的领导的角度来看,就是你们组长弄出了问题。
    ppllss
        62
    ppllss  
       188 天前
    从设计方面,的确过度了,但是从未来架构方面和技术可行性方面这是加分的,懂得尝试,有一点,觉得还是不要拿公司项目做实验,自己私底下去实践,然后整理成一个可行性方案,对公司内部项目的架构升级等。组长愿意就让你做,不愿意,你自己也实践了,能力也提升了
    ganbuliao
        63
    ganbuliao  
       188 天前
    一般分项目啊,有的项目就是不能整活。有的独立的小项目,时间充足的时候就各种整活了
    lap510200
        64
    lap510200  
       188 天前
    搞就完事了 大不了删库跑路
    kujio
        65
    kujio  
       188 天前
    时间+稳定优先:效率优先
    jackzhengjbs
        66
    jackzhengjbs  
       188 天前 via Android
    上次那个在注释里面留彩蛋的是不是你?🐶头
    akira
        67
    akira  
       188 天前
    项目怎么做 怎么实施 这些在上服务器前都要讨论确认的吧。。
    这个都不是过度不过度设计的问题了,比这严重多了。。
    wyhooo
        68
    wyhooo  
       188 天前
    你跟组长关系不够铁 → →
    meeop
        69
    meeop  
       188 天前
    不影响需求实现前提下,尽量搞,面向简历开发,不要怕

    除非是你的方案有明显问题影响服务可靠性
    37Y37
        70
    37Y37  
       188 天前 via Android
    运维,看到这个要骂娘了
    az467
        71
    az467  
       188 天前
    边界就是没经过讨论审查,没出现在文档里的东西一个也不要出现。
    何止是过度设计,简直是独走下克上了。
    raptor
        72
    raptor  
       188 天前
    面向简历开发的最大问题就是:好处是你自己学习到了,坏处都是公司和后来人的。

    我上次接了一个前同事丢下的烂摊子,比你这过度多了,真是想问候他亲属。
    kaedea
        73
    kaedea  
       188 天前 via Android
    很多 leader 觉得过度设计那是因为改代码的时候不用他们来改。
    hallDrawnel
        74
    hallDrawnel  
       188 天前
    两个服务的话,那直接用 k8s 的 service 就可以了。引入额外的东西复杂度一下子就变高了。如非必要,勿增实体。
    wangritian
        75
    wangritian  
       188 天前
    你可以在测试环境玩
    hxndg
        76
    hxndg  
       188 天前
    @otakustay 问下这个的原文是在哪里哈?
    levelworm
        77
    levelworm  
       188 天前
    @bwensun 其实这就是员工和公司的矛盾之一。我对这些技术不熟,但是就帖子里回复的那些内容,我觉得项目上自己不熟悉的东西的确欠妥。可以和领导提一下用这个,但是如果他反对,那就只好撤出来了,毕竟他最关心的一个是实现一个是可靠性。

    如果觉得公司不支持你学新东西,我觉得可以考虑自己学然后跳。当然很多东西,就像你说的,就是不在生产环境试过,怎么能够叫做熟练了呢?这就看你和公司之间的互动了,可以和领导商量下,试试看有没有小的项目可以让你练手。
    ETiV
        78
    ETiV  
       188 天前
    不知道你执行到哪里了才被组长发现的,

    但照理都是先设计(讨论方案),再实现(编写代码)。

    「好心提醒」这个词有些……所以是在实现阶段才发现你用了 consul ,然后被毙掉的?
    zw1one
        79
    zw1one  
       188 天前
    公司只想让你当工具人,用最快的时间搞完 CRUD ,对于公司来说搞其他都是浪费时间。毕竟大部分公司的业务根本用不到这些技术。
    SmiteChow
        80
    SmiteChow  
       188 天前
    做任何事都是奥卡姆剃刀原则
    neptuno
        81
    neptuno  
       188 天前
    @Cielsky 业务量起来了自然就会了呀,,,又不是什么难的东西。
    neptuno
        82
    neptuno  
       188 天前
    挂了的话,确实是组长先背锅吧。(我不是你组长 hhhh )
    brust
        83
    brust  
       188 天前
    另外就是刚学习了 consul ,想实践一波
    emmm
    xiaoyang7545
        84
    xiaoyang7545  
       188 天前
    1 你对 consul 并不熟悉,出了问题又得花大量时间精力解决。
    2 项目复杂度在“想实践一波”这样无聊的背景下提高,以后维护的人还要因为这个再提高学习成本。
    zjuster
        85
    zjuster  
       188 天前
    最低成本(代码)和最简(最熟)方法解决业务问题,永远不会错。

    你想加任何一点额外的东西,都是额外的维护和沟通成本。

    技术晋升不是炫技就行的,要在技术视角解决问题的基础上推进技术迭代和行业理解。前提是先做好业务问题。
    aLazarus
        86
    aLazarus  
       188 天前   ❤️ 1
    在我公司,对于生产环境用新技术的话,首先需要调研技术、编写技术评审文档开会让项目组所有人评审,以及制作一个和业务场景类似的 demo ,而且要完善技术相关的工具或者调用。
    kangkang
        87
    kangkang  
       188 天前
    若无必要,勿增实体。
    zengyuxi
        88
    zengyuxi  
       188 天前
    看到"刚学习了 consul ,想实践一波",说出这种话的,如果你是学生,我是鼓励的;但你现在的身份,是企业的一员,说出这种话,我觉得你是在耍流氓。
    otakustay
        89
    otakustay  
       188 天前   ❤️ 1
    @hxndg #76 《 Software Engineering at Google 》,450 块钱一本的好书
    wudaye
        90
    wudaye  
       188 天前
    才两个服务节点,你就整个 consul ,站在公司项目利益上肯定是没必要,甚至弊大于利,浪费资源,consul 是不是还得部署多节点保证高可用?单纯想监控两个节点有轻量得多的方案。当人站在个人发展的角度看,你这种面向简历开发的思路是无可厚非的
    ccyixia
        91
    ccyixia  
       188 天前   ❤️ 1
    mark 一下,以后谁给我整幺蛾子,就发这篇给他看。

    没有嘲讽 lz 的意思,人都会有成长的过程。lz 明显踩过的坑不够多,试想一下,万一 consul 出了严重 bug 导致服务中断,你半夜被电话喊起来或者节假日紧急 oncall ,google 半天毫无收获结果发现项目 github 里躺着一个没有 close 的 issue 恰好是你遇到的问题。。。相信我,你那时会很想穿越到现在扇自己两巴掌,后悔没有听组长的话。
    IvanLi127
        92
    IvanLi127  
       188 天前 via Android
    @nicebird 那得看多久被发现,上线几个月了才被发现,可没人敢开除的喔🤔
    struggletoday
        93
    struggletoday  
       187 天前
    @bwensun 想知道 组长到场了没 🐶
    Carver9527
        94
    Carver9527  
       187 天前
    @otakustay 请问一下,这段决策的出处有吗,想进一步的了解
    Real00
        95
    Real00  
       187 天前
    奥卡姆剃刀定理
    arthas2234
        96
    arthas2234  
       187 天前
    要使用新的东西,必须组内讨论经过组长的同意才用。
    浪费资源就不说了
    项目不是你一个人的,也得要考虑组内其他人是否熟悉这个东西,以免你不在的时候出现问题,其他人不能及时解决
    otakustay
        97
    otakustay  
       187 天前
    @Carver9527 #94 就《 Software Engineering at Google 》这本书
    qixcoder
        98
    qixcoder  
       187 天前
    考虑 ROI 吧
    qfdk
        99
    qfdk  
       187 天前
    其实解决问题方式很多种,团队合作必需要大家都熟悉才能维护一个系统的稳定,如果这个系统只有你来做,里面 bug 出现了 处理的问题,哪天你走了,这个就成了烂尾项目了,后面如何维护。主要是引入了一个 consul 不知道里面有多少的坑。想到以前引入了一个 Eureka 都折腾了一阵子。自己的分布式项目也搞了好久,才发现里面很多门道。 然后你做完了之后要不然还要写完整的文档。。。
    gerorim
        100
    gerorim  
       187 天前
    @Carver9527 #93
    O'Reilly 官网地址: https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/
    原书第 436 页,第 21 章依赖管理

    When engineers at Google try to import dependencies, we encourage them to ask this
    (incomplete) list of questions first:
    • Does the project have tests that you can run?
    • Do those tests pass?
    • Who is providing that dependency? Even among “No warranty implied” OSS projects, there is a significant range of experience and skill set—it’s a very differ‐
    ent thing to depend on compatibility from the C++ standard library or Java’s Guava library than it is to select a random project from GitHub or npm. Reputation isn’t everything, but it is worth investigating.
    • What sort of compatibility is the project aspiring to?
    • Does the project detail what sort of usage is expected to be supported?
    • How popular is the project?
    • How long will we be depending on this project?
    • How often does the project make breaking changes?
    Add to this a short selection of internally focused questions:
    • How complicated would it be to implement that functionality within Google?
    • What incentives will we have to keep this dependency up to date?
    • Who will perform an upgrade?
    • How difficult do we expect it to be to perform an upgrade?
    1  2  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3330 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 51ms · UTC 05:06 · PVG 13:06 · LAX 22:06 · JFK 01:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.