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

技术栈一把梭,真的好吗

  •  
  •   fanmouji · 2020-10-01 00:28:50 +08:00 · 7905 次点击
    这是一个创建于 1513 天前的主题,其中的信息可能已经有所发展或是发生改变。
    说一下现状:
    1.原系统 Java 开发,供内部人员使用,工单模块使用最频繁,并发最多 400,涉及大量导入导出,多表联表统计;偶有支付订单,基本无实时要求。
    2.开发 4 人,无技术大佬,开发运维一条龙服务...
    3.需求更改频繁,今天一个导出,明天修改流程等等小修改
    4.单体项目,部署麻烦。
    最近公司高层变动(原领导提桶跑路),新来的领导(非技术)想优化业务(涉及多部门)流程,新的产品经理(有过技术经验)一直提要重构成微服务,拆分用户中心、支付中心、订单中心;分布式、缓存、高并发等等。粗略算了下全公司用户最多 1000,支付单:工单=1:1 也就 1000 多单。
    请问这样真的有必要微服务吗?
    51 条回复    2020-10-05 18:07:40 +08:00
    nvkou
        1
    nvkou  
       2020-10-01 00:32:29 +08:00 via Android
    如果业务成增长态势的话判断也没错,战未来嘛。
    tsingke
        2
    tsingke  
       2020-10-01 00:35:59 +08:00 via iPhone   ❤️ 17
    公司发工资让你学技术 何乐不为呢?跟上主流技术本身对公司可能不是刚需 但是对技术人来说是刚需。所以爽快的干吧。
    cqxxxxxxx
        3
    cqxxxxxxx  
       2020-10-01 00:38:32 +08:00 via Android
    同意 2l
    des
        4
    des  
       2020-10-01 01:24:42 +08:00
    @tsingke “开发 4 人,无技术大佬,开发运维一条龙服务”
    MintZX
        5
    MintZX  
       2020-10-01 01:45:53 +08:00   ❤️ 3
    @tsingke 这就是典型的杀鸡用牛刀,就算你做出来了这么点儿流量,你也不知道你做的对不对啊。
    sheeta
        6
    sheeta  
       2020-10-01 02:16:33 +08:00   ❤️ 1
    不要为了微服务而微服务...
    Kirsk
        7
    Kirsk  
       2020-10-01 02:29:36 +08:00 via Android
    你叫他来搭分布式系统 看他还比比不 高并发?号召员工一起点吗
    fengchang
        8
    fengchang  
       2020-10-01 03:25:03 +08:00   ❤️ 3
    康威定律:"设计系统的架构受制于产生这些设计的组织的沟通结构。"

    四个人的团队不需要搞微服务。
    felixcode
        9
    felixcode  
       2020-10-01 03:49:22 +08:00 via Android
    跑两个容器,跑一下压测,就能把微服务和百万并发写到领导年终总结里去了
    xuanbg
        10
    xuanbg  
       2020-10-01 03:59:21 +08:00
    微服务有必要。对付这种需求变更频繁,业务组成复杂的情况,微服务就是最好的解决方案了。但搞微服务,你们要先搞定 devops,要对 ddd 有所理解,然后才能成。

    至于高并发,你当他是买一送一的就行了。事实上微服务本身就是个分布式系统。搞定高并发,就是多部署几个实例的事。钱能直接解决的问题也就不是问题了。。。
    xuanbg
        11
    xuanbg  
       2020-10-01 04:08:28 +08:00
    @fengchang 我一个人开发也搞微服务。只需要写业务模块的代码就搞定整个项目,完全不需要关心那些和业务无关的功能,包括但不限于:用户、组织机构、权限、账务、支付、字典、报表模板、短信、邮件、消息通知、失败重试等等……

    微服务属于那种一次投入终身受益的事。既然已经投入过了,我何苦不接受这个好处非得每个项目自己搞一套呢?用一套现成的他不香吗?
    fengchang
        12
    fengchang  
       2020-10-01 05:01:16 +08:00
    @xuanbg 看清楚 lz 的需求,他只有一套系统,你在一个系统里写两套用户模块?
    zjsxwc
        13
    zjsxwc  
       2020-10-01 05:55:24 +08:00 via Android
    先定义什么是重构。
    老是有人把重写当重构来说,产品经理等外行这么说也就罢了,程序员也这么说就不应该了,建议看 Martin 的书。
    maddot
        14
    maddot  
       2020-10-01 06:07:38 +08:00 via Android   ❤️ 3
    哈哈,面向简历做项目呗
    wd
        15
    wd  
       2020-10-01 06:08:29 +08:00 via iPhone
    微服务的意思是 每个服务至少需要三个人维护 你们总共四个 拆了之后也还是这么几个人搞 那肯定只会更累
    way2explore2
        16
    way2explore2  
       2020-10-01 06:27:31 +08:00
    @zjsxwc

    我觉着重写一个函数是一个小小的重构。

    容易被人滥用的是

    refactor - replatform - rehost
    fanmouji
        17
    fanmouji  
    OP
       2020-10-01 07:15:20 +08:00 via iPhone
    @tsingke 这个确实很好,还能丰富简历。但是人手不足,每个人都太累了,前领导就是因为薪资问题提桶跑路的
    fanmouji
        18
    fanmouji  
    OP
       2020-10-01 07:23:44 +08:00 via iPhone
    @Kirsk 搭不出来的,就像领导去听完某些讲座,回来就说“我们是不是也可以搞一个?”,大概就是别人有的,我也想有...
    fanmouji
        19
    fanmouji  
    OP
       2020-10-01 07:35:44 +08:00 via iPhone
    @xuanbg 微服务确实很好,但是人少没专人专职,太累了,催得又紧...
    shenchao
        20
    shenchao  
       2020-10-01 08:08:16 +08:00 via Android   ❤️ 1
    重构下挺好,总结经验好机会。对技术部门也好,代码清晰部署方便,高可用性也可以上来。领导也好,组建正规化技术团队,团队可以稍微大点。
    对公司也好。周边一千多人需要用系统工作。公司规模也不会太小,4 个人的开发运维团队明显服务不了这么大的公司。IT 系统还有很大优化空间。
    Leigg
        21
    Leigg  
       2020-10-01 08:13:07 +08:00 via Android
    如果用 go 的话,推荐一个仓库
    https://github.com/chaseSpace/go-kit-examples
    chenqh
        22
    chenqh  
       2020-10-01 09:38:15 +08:00
    不如先搞一个自动化部署,哈哈
    reus
        23
    reus  
       2020-10-01 09:49:00 +08:00 via Android
    当练手,熟悉了就跳槽
    zengming00
        24
    zengming00  
       2020-10-01 10:00:11 +08:00
    单体项目哪来的部署麻烦,微服务才是真的麻烦,而且不是一般的麻烦
    TypeError
        25
    TypeError  
       2020-10-01 10:01:34 +08:00 via Android
    面向工资 /简历编程
    ReinerShir
        26
    ReinerShir  
       2020-10-01 10:37:04 +08:00
    过来人告诉你,就算为了面向面试而使用微服务也没用,面试官会问你,海量大数据处理经验吗?有高并发处理经验吗?有亿级数据架构设计经验吗? 没有?那不好意思,事实上有几个企业能用上大数据高并发。
    fanmouji
        27
    fanmouji  
    OP
       2020-10-01 10:54:40 +08:00 via iPhone
    @chenqh 确实是部署麻烦,在弄自动化部署了...
    @ReinerShir 问倒了😂
    Mitt
        28
    Mitt  
       2020-10-01 11:06:14 +08:00 via iPhone   ❤️ 1
    虽然现在这个情况可能用不到,但是学了对自己有好处,积累经验,以后用到的时候就很容易上手再搞突破了
    wangritian
        29
    wangritian  
       2020-10-01 12:28:37 +08:00
    微服务人少不要折腾,但自动化运维任何规模的项目都有用
    hahasong
        30
    hahasong  
       2020-10-01 13:17:43 +08:00
    微服务已经过时了,现在流行宏服务,中台系统。你可以提议做个中台出来
    eudore
        31
    eudore  
       2020-10-01 13:40:07 +08:00   ❤️ 1
    赞同 6 楼 “不要为了微服务而微服务”

    从项目的角度来说,可以正常使用就好,不要为了炫技而使用新技术,你们变化的是领导不是项目场景,是否需要微服务看项目和公司的发展状态,一些再牛逼的东西里面主线程也是一个 for 死循环。

    从个人角度来说,那个 pm 很可能是外行(不会写代码),也许微服务了解不深,以前工作是使用的微服务,为了 kpi 之类来搞的,深点的内部竞争的我想不到了(太笨);公司要是花钱让你玩微服务就弄吧,那一样的钱玩点新东西也不错,也许微服务了还要加人呢,自己还能当个小领导( 15 楼说每个项目至少 3 人是正确的,最低 2 人维护一个服务,单人维护出现请假离职就凉凉了,你们 4 人玩不来,公司需要打钱加人)。

    另外我觉得你们缺乏发布流程,正常应该在固定时间点进行项目发布更新,如果这个功能每赶上这个发布点就下次了。
    piecehealth
        32
    piecehealth  
       2020-10-01 14:25:26 +08:00
    1. 微服务首先解决的是团队 scalability 的问题,4 人团队完全没有此问题。而且单体应用也可以业务解耦,谷歌一下 modular monolith 。
    2. 单体应用也有很多自动化部署方案。如果单体应用自动化部署都搞不定,上微服务等于自杀。
    3. 开局就微服务还好说,如果把一个已经挺复杂的系统迁移到微服务又是一个复杂度巨大的事情,要是准备干两年跑路可以试试;打算长期干下去就不要给自己挖坑了。
    fanmouji
        33
    fanmouji  
    OP
       2020-10-01 14:57:10 +08:00 via iPhone
    @eudore 他前东家是微服务,内部竞争倒是没有,只不过我们一直提的人手不够上面还卡着,真上这个还是累死自己...
    fanmouji
        34
    fanmouji  
    OP
       2020-10-01 15:01:02 +08:00 via iPhone
    @piecehealth 是很复杂的系统迁移,其实现在都是各自分模块开发的,公共部分一年都没 3 次修改,各自独立也没啥问题,主要是人不够,还经常加班,心态炸了...
    bleepbloop
        35
    bleepbloop  
       2020-10-01 15:42:25 +08:00
    技术选型也听产品经理的,这解释不通吧
    fanmouji
        36
    fanmouji  
    OP
       2020-10-01 16:02:41 +08:00 via iPhone
    @bleepbloop 还别说,之前我们一直当他透明的,这次不一样了,万一怂恿上面这样的好处 balabala,还真有可能🌚
    losephsky
        37
    losephsky  
       2020-10-01 17:41:35 +08:00
    我觉得趁此机会学一把还不赖啊,至少出去找下家简历也很光彩
    EPr2hh6LADQWqRVH
        38
    EPr2hh6LADQWqRVH  
       2020-10-01 18:40:37 +08:00 via Android
    没运维监控搞微服务不是给自己添乱吗
    liuzhiyong
        39
    liuzhiyong  
       2020-10-01 21:13:47 +08:00
    个人观点:经过实践检验的代码,尽量少改动。
    asuraa
        40
    asuraa  
       2020-10-01 21:16:53 +08:00   ❤️ 1
    我们公司开发 12 个人 运维就我一个人.
    三个项目同事搞
    我维护 gitlab 和所有项目
    于是我上了 k8s 现在闲的天天喝茶
    kangsheng9527
        41
    kangsheng9527  
       2020-10-01 22:49:28 +08:00
    趁年轻 ,练练!
    任何时候把自己公司当成宇宙第一强企业来做,都是好事。
    lewis89
        42
    lewis89  
       2020-10-02 05:58:12 +08:00
    公司发钱让你们追技术主流,这么好的事情,你都拒绝? are you kidding me ?
    cmqwan
        43
    cmqwan  
       2020-10-02 06:42:24 +08:00 via iPhone
    1000 人,并发有 400 呢
    bambo
        44
    bambo  
       2020-10-02 07:52:06 +08:00
    好吧,只是不知道你们用的是不是 maven,如果是,我那个工具,帮你们分分钟解决。
    https://www.v2ex.com/t/712080#reply7
    notejava
        45
    notejava  
       2020-10-02 10:34:17 +08:00
    杀鸡用牛刀?
    shroxd
        46
    shroxd  
       2020-10-02 14:14:28 +08:00
    公司领导需要重构项目才能升职, 程序员需要重构项目才能学习新技术。所以说这算是个双赢,何乐而不为呢?
    kajweb
        47
    kajweb  
       2020-10-02 21:39:40 +08:00
    @luodaoyi 好了,公司知道你闲了
    594duck
        48
    594duck  
       2020-10-03 08:13:22 +08:00 via iPhone
    @fengchang 不搞怎么可以,不搞就不能折腾不能展示自己的才华
    itmyhome126
        49
    itmyhome126  
       2020-10-03 08:50:30 +08:00
    你确定有并发 400 ?
    matatabi
        50
    matatabi  
       2020-10-03 15:50:13 +08:00 via iPhone
    并发 400 挺多,微服务走起
    asuraa
        51
    asuraa  
       2020-10-05 18:07:40 +08:00
    @kajweb 哈哈哈 公司都知道
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1167 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 23:06 · PVG 07:06 · LAX 15:06 · JFK 18:06
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.