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

各位对业务系统技术栈迁移有啥看法

  •  
  •   buruoyanyang · 2023-01-11 20:32:25 +08:00 · 6000 次点击
    这是一个创建于 526 天前的主题,其中的信息可能已经有所发展或是发生改变。

    行业

    传统软件行业、工业信息化

    现状

    原来的业务系统是用 C++写的,NodeJs 作为应用容器,对外开放了 WebService 。也就是 NodeJs 是 tomcat ,C++写的业务是 war 包,这么一个策略。
    然后就是目前我们需要进行微服务改造,最终要 SaaS 化

    问题

    1 、NodeJs 和 C++代码已经超过一百万行了,全部推翻重写风险略微有点大。
    2 、现在 NodeJs 这一层目前处于不够稳定的状态,经常悄无声息的挂了,也没有特别牛的技术储备。
    3 、古老的工业软件设计,仅能支持冷备,整体无状态化改造困难,C++的大佬真的很难招,是的,我们只支持 Windows
    4 、原来的架构师,非常极其十分喜欢造轮子,比方说网关、注册中心等等,但是受制于手下同学的战力,真的是不太好使。
    5 、C++没啥好使的 ORM ,也没有合适的分布式事务组件,作为业务系统,真的不可避免的要和数据库打交道啊。
    6 、目前是按照项目交付的,现场太多,基础组件不稳定,各位同事苦不堪言。

    策略

    1 、使用 Java 慢慢替换现有的 NodeJs 这一层(杭州,公司的 Java 储备还可以),使用公共组件慢慢替换现有的各种不好使的自己造的轮子。
    2 、不装了,我特么直接用 Java 开始一个重写业务,代码和我总有一个能跑。

    请教各位是如何看待这样的大业务系统迁移的问题的?

    第 1 条附言  ·  2023-01-12 09:34:59 +08:00
    为什么想动架构,还有个很大的原因是,我们有个现场,100 个用户的并发,直接把我们系统打挂了。客户提出,我们给你们家机器,但是我们目前没有横向扩展的能力
    第 2 条附言  ·  2023-01-12 10:47:02 +08:00
    为什么要选择 Java ,第一是我的主力语言是 Java ,第二是公司还有其他业务线,Java 的储备还算比较足的。
    第 3 条附言  ·  2023-01-13 11:12:21 +08:00
    感谢各位的回复,目前已经和大领导达成的策略
    1 、不能一下子重构,但是可以从公共组件、边缘业务开始。
    2 、尽量选择语言无关的开源组件替换。
    3 、先做 Linux 化,再做无状态改造,无法改为无状态的服务考虑在网关层或者调度服务中响应。
    4 、SaaS 化的事情往后拖一下,先对付现场。
    66 条回复    2023-04-26 11:27:26 +08:00
    sampeng
        1
    sampeng  
       2023-01-11 21:43:43 +08:00 via iPhone   ❤️ 1
    你层级多高? cto 或者总监这件事可行,否则,只能是你跑…
    cutepig
        2
    cutepig  
       2023-01-11 21:46:42 +08:00 via Android   ❤️ 2
    切身经历告诉我,不要寄希望于彻底重写一次到位,尽量想如何一点一点替换
    zu1y
        3
    zu1y  
       2023-01-11 22:08:41 +08:00
    Node.Js 套 C++还是第一次见 讲讲怎么玩的
    kop1989smurf
        4
    kop1989smurf  
       2023-01-11 22:16:42 +08:00   ❤️ 2
    没特别理解,SaaS 化和技术栈的改变之间的逻辑关系是什么?

    如果想相对平滑的过度,其实.net ( C#)+ IIS 是相对更稳妥的技术选型。( c++的老库可以复用,然后灰度更新)
    vivisidea
        5
    vivisidea  
       2023-01-11 22:20:30 +08:00   ❤️ 1
    试试新需求用 Java 实现,然后用跨语言的 rpc 与原有系统连接,比如 grpc
    原来的能不动就不动了,又不是不能跑 :D

    百万行的代码的项目,从零开始 Java 重写?想想就头皮发麻
    yiqiao
        6
    yiqiao  
       2023-01-11 22:24:11 +08:00
    悄无声息的挂了?写过脚本监听端口掉了自动重启试试?我们就是这么干的
    同意 2 楼,只能慢慢迭代
    roundgis
        7
    roundgis  
       2023-01-11 22:28:10 +08:00 via Android
    超過一百萬行重寫除非是換領導了

    不然
    imv2er
        8
    imv2er  
       2023-01-11 22:28:48 +08:00   ❤️ 1
    附议楼上的 C# 调用 cpp 更方便。但是为了微服务啥的,招人和开发效率 建议 java 但是硬件要提高。
    如果真像你说的 nodejs 是 tomcat 的话 那 nodejs 可以直接丢弃。另外一百万行代码不可怕 js 代码永远都是一坨坨的,cpp 也有头文件无形中增加了太多没用代码
    还有一个办法把 c++的业务方法都找出来 jndi+springboot 说白了就是套一层 java 壳。然后你就可以慢慢的把 c++的消化掉
    adoal
        9
    adoal  
       2023-01-11 22:31:33 +08:00 via iPhone
    接入层架好网关慢慢做灰度迁移吧
    WispZhan
        10
    WispZhan  
       2023-01-11 22:31:36 +08:00
    这是个典型的遗留系统迁移。

    关键字“遗留系统”,“防腐层”。 你会得到很多相关的常用套路。

    个人建议平滑过度,补齐单元测试、集成测试。 挨个模块挨个模块迁移。
    这个课题很大,几句话说不清楚。也不想说,点到为止。
    KENNHI
        11
    KENNHI  
       2023-01-11 22:34:43 +08:00 via Android
    早知道,还是 Java.jpg
    xsen
        12
    xsen  
       2023-01-12 08:31:11 +08:00
    我们就有类似的情况,原有的整套都是 C++写,代码量五十万网上
    其实思路就是——模块化、服务化

    简单点就是内部一部份一部份的拆出来,然后再服务化(这个过程是不换语言的);服务化之后,就可以看机会一个服务一个服务重写、重构,若 Java/Go/C++这些
    xsen
        13
    xsen  
       2023-01-12 08:32:54 +08:00
    一开始先别考虑什么微服务(如引入网关、注册中心什么的),不划算。开始要做的就是解耦,模块化、服务化、再重构重写
    buruoyanyang
        14
    buruoyanyang  
    OP
       2023-01-12 09:22:57 +08:00
    @sampeng 目前是架构师(新任命的),CTO 想搞这个事情。
    buruoyanyang
        15
    buruoyanyang  
    OP
       2023-01-12 09:23:47 +08:00
    @cutepig 现在的想法就是慢慢替换,一次性重写实在是风险太高了,现场太多了
    buruoyanyang
        16
    buruoyanyang  
    OP
       2023-01-12 09:24:16 +08:00
    @zu1y 具体细节我也不清楚,大概就是 NodeJs 直接调用 dll 里面的函数?
    forbreak
        17
    forbreak  
       2023-01-12 09:24:47 +08:00
    首先排除重写这个选项。既然微服务了,就新的用 java 写。 不出问题的不换,出问题的模块慢慢换成 java 。这是一个长期的规划,不要想着一次解决问题。 对了 java 写久了,最后一样会变成屎山的。 要我说能跑就行,实在跑不了了在原有上面改才是最稳妥的。 屎山换语言也还是屎山。
    buruoyanyang
        18
    buruoyanyang  
    OP
       2023-01-12 09:26:05 +08:00
    @kop1989smurf 因为目前表现来看,是 NodeJs 这一层问题很大,又没有足够强的大佬。第二个就是业务系统,C++可用的组件太少了,开发效率也不高。第三个就是自己造的低质量轮子太多了,已经维护不过来了。
    buruoyanyang
        19
    buruoyanyang  
    OP
       2023-01-12 09:26:53 +08:00
    @yiqiao 我们目前也做到了,自动重启,但是我们的行业特殊,自动重启是要被审计...
    buruoyanyang
        20
    buruoyanyang  
    OP
       2023-01-12 09:27:50 +08:00
    @imv2er jndi 也考虑过,哈哈哈,主要是原来的业务系统同事有抵触,而且这种东西容易出现做好了是应该的,做不好是 shabi 这么个情况
    buruoyanyang
        21
    buruoyanyang  
    OP
       2023-01-12 09:28:08 +08:00
    @WispZhan 哈,感谢
    buruoyanyang
        22
    buruoyanyang  
    OP
       2023-01-12 09:33:31 +08:00
    @forbreak 直接推到重写不现实,C++那边也没实现微服务化。至于代码层面,跑起来的代码才是好代码,但是从目前的技术需求来看,以我们公司现有的储备,维护会愈发困难。
    opengps
        23
    opengps  
       2023-01-12 09:41:43 +08:00
    了解下云架构,既然 op 补充说弹性扩容能力,那么完全可以适当改造就具备(具体改多少看具体业务)
    我最早就是因为直接面对负载量保障,所以从云计算的一开始就各种探索,最后找到了云的思路,重集群轻单机
    buruoyanyang
        24
    buruoyanyang  
    OP
       2023-01-12 09:44:47 +08:00
    @opengps 这个也是一个思路,核心问题就是如上我说的,我们没有横向扩展的能力,虽然我们有网关(我们叫调度服务)和注册中心(别问,问就是理解不一致)
    cp19890714
        25
    cp19890714  
       2023-01-12 10:02:35 +08:00
    既然用微服务了,那就可以异构微服务。
    迁移原则是:仅在必要时或极低成本时迁移,C 代码以保留为主,迁移为辅。

    * 在 nodejs 前再加一层,用于兼容微服务间调用方式,如 http 。
    * 老代码以保留为主,分离为辅。
    * 如果 1 个模块功能已经比较完善,那就不必要用 java 重写,直接 http 调用
    * 如果 1 个模块在未来需要大量开发,那就用 java 开新服务。这样 1 个模块既有 java 代码,也有 c 代码。这个模块内部,需要功能间方法调用,如果功能简单,则可以直接以 java 重写,如果功能复杂,则 http 调用。


    Dubbo 支持异构微服务,其他的技术栈你可以再找找。
    xuanbg
        26
    xuanbg  
       2023-01-12 10:05:36 +08:00
    首先,你要把基于 windows 的 C++程序改成基于 Linux 的。这一步其实不难,最多重写 make 文件。
    然后,把 C++的巨石服务尽可能分拆为多个单领域服务,譬如:组织机构、用户、角色、订单等等。
    最后,无非就是容器化,这个就好简单了。
    bjhc
        27
    bjhc  
       2023-01-12 10:05:36 +08:00
    模块拆分吧,先从边缘业务开始重写,慢慢替换,过程中可能还需要新旧系统同时跑。
    luvsic
        28
    luvsic  
       2023-01-12 10:12:04 +08:00
    2 、现在 NodeJs 这一层目前处于不够稳定的状态,经常悄无声息的挂了,也没有特别牛的技术储备。
    挂了无所谓,pm2 启动 NodeJs ,再重启呗
    buruoyanyang
        29
    buruoyanyang  
    OP
       2023-01-12 10:17:43 +08:00
    @luvsic 我们是面向工厂的,而且行业特殊,重启是要被审计的...
    xworkwithreader
        30
    xworkwithreader  
       2023-01-12 10:19:39 +08:00
    能不动就别动...
    star7th
        31
    star7th  
       2023-01-12 10:20:31 +08:00
    用过 nodejs 多年,表示 nodejs 和 C++两者的性能都是非常高的 。nodejs 作为应用层还是非常合适的。如果只能 100 并发,肯定是你们的代码哪里阻塞的问题。但是你们的技术储备没有懂 nodejs 的,那就没办法了。
    god7d
        32
    god7d  
       2023-01-12 10:23:25 +08:00
    哈哈哈,100 个用户就挂了。但是 100 万行代码看着都头大呀,我觉得动架构真的很需要勇气,而且完成之后带来海量的问题,到时候万一绝望了怎么办,我看大概率只能你跑了。
    star7th
        33
    star7th  
       2023-01-12 10:25:35 +08:00
    我的建议是,不要重写,而是把原有的优化。你们的问题是在于没有招到 nodejs 的人才。假如实在找不到,再考虑换技术栈的事情。感觉你们公司有其他技术栈的软件,却招一推 java 程序员,感觉招聘这块没有针对性。如果你确定全部转到 java 块,那么,重构风险你就背吧。个人觉得历史包袱应该蛮多的
    buruoyanyang
        34
    buruoyanyang  
    OP
       2023-01-12 10:26:34 +08:00
    @star7th 确实,我们内部一直认为是人的问题,完全没到语言的瓶颈,但是奈何是没有 NodeJs 的储备,原来搞这套的人已经跑路了,现在都是 C++的同事兼着 NodeJs...
    buruoyanyang
        35
    buruoyanyang  
    OP
       2023-01-12 10:29:09 +08:00
    @god7d 杭州的工业信息化圈子就这么大,不行就回到老东家划水(手动狗头)
    god7d
        36
    god7d  
       2023-01-12 10:35:42 +08:00   ❤️ 1
    @buruoyanyang 你们是做 mes 系统的吗,还是其他的工业系统,我是做设备研发的,算是半个同行,感觉这行很多公司用的是 C#或者 java 呀,我是一直用 C#的
    buruoyanyang
        37
    buruoyanyang  
    OP
       2023-01-12 10:38:16 +08:00
    @god7d 哈,是的。我们公司的业务老大是 C++出身...
    zjsxwc
        38
    zjsxwc  
       2023-01-12 10:38:49 +08:00
    记录日志找到 node 挂的原因,修复这个老系统稳定性。
    新业务用楼主擅长的搞。
    loryyang
        39
    loryyang  
       2023-01-12 10:51:13 +08:00
    一般解法都是另起炉灶,慢慢迁移过去。你们搞个新系统,慢慢加功能,满足部分用户需求,把这部分用户迁移过去。顺便梳理下,原系统的功能,没用的就干掉。
    但是即使如此,也是很漫长,非常耗费人力物力
    最后一个终极问题:你如何确保新的代码不会变成屎?凭什么这次就会不一样?
    jjx
        40
    jjx  
       2023-01-12 11:06:52 +08:00
    100 个并发就挂 而且机器不能扩容

    那瓶颈在 io? db?

    否则扩容一般就可以

    如果瓶颈在 io? 不换语言应该也能解决
    urnoob
        41
    urnoob  
       2023-01-12 11:23:54 +08:00   ❤️ 1
    @buruoyanyang
    想当年第一家公司做 MES 就是 java. 这类系统 C#也很合适。
    过往公司也有平台和业务都是 CPP 然后套上 nodejs 结果很快淘汰了。
    总结下经验选项有三
    一路 c++到底,把 nodejs 也用 c++换掉
    套壳 java/C#慢慢替换
    重新写一套替换老系统

    另外 mes 之类的不要上微服务搞什么服务发现之类的噱头, 拆分成单独应用相互调用就好了。
    8355
        42
    8355  
       2023-01-12 11:27:46 +08:00
    核心问题还是你能不能推动这个事
    其次就是 java 的全套微服务改造不仅仅是业务代码 要求有运维能力
    从落后 N 久到跟上时代 新中间件用的可不少....
    开发业务代码成了相对最简单的事
    ProProPro
        43
    ProProPro  
       2023-01-12 11:31:26 +08:00
    确实庞大的和复杂的。

    首先是技术栈的变换,这个主要视员工技术栈而定,楼主说了,有 java 人才,而且自己也是 java 人才,所以 这点没毛病。

    但是,一入 java 深似海,各种框架,中间件,组件,分布式,DevOps ,容器。。。。这些都需要攻克的,基础工具(代码,api 文档,知识库等等)和流水线还是要搭建好。。。


    第二,关于业务系统重构,从边缘系统开始,让兄弟们练手
    xieren58
        44
    xieren58  
       2023-01-12 14:09:26 +08:00
    直接上 rust, 一劳永逸.
    jjwjiang
        45
    jjwjiang  
       2023-01-12 15:06:36 +08:00   ❤️ 2
    我感觉你根本没有弄清楚瓶颈在哪,就想着重构。重构不是万能药,你如果对目前的困境没有认知,甚至不知道怎么解决当前的问题,重构是必然失败的。
    个人建议
    1. 找清楚当前时不时崩溃的原因,通过各种方式得出一个在当前局面增强稳定性的方案
    2. 评估重构的代价,重中之重是从当前如何平滑过渡到重构的方案
    3. 评估重构成功之后的优势,从业务角度和运维角度,评估 1 和 3 ,最终得出方向性结论
    yuedun
        46
    yuedun  
       2023-01-12 15:09:05 +08:00
    这其实是一场政治问题,并不是技术问题
    yaphets666
        47
    yaphets666  
       2023-01-12 15:13:30 +08:00
    无论如何是另起炉灶,还是怎么样,都得先解决 nodejs 的问题,解决的 nodejs 的问题,保证能交付,剩下的怎么搞都可以了。
    sky857412
        48
    sky857412  
       2023-01-12 15:42:24 +08:00
    感觉应该从机器不能扩容这个方向去解决,把一些共享的状态加锁,应该就可以完成扩容了吧。百万级别的代码重构和变成异构架构听着就头大
    ericgui
        49
    ericgui  
       2023-01-12 15:45:12 +08:00
    nodejs 又不是很难,你就修一下呗
    实在行不行,可以把 nodejs 用 typescript 改造一下,肯定比 js 稳多了

    你先解决眼前的问题,再考虑重写
    crayygy
        50
    crayygy  
       2023-01-12 16:03:10 +08:00
    超过一百万行基本上没有迁移的可能了,这个技术债几乎会永远存在了,即使写了新的系统,也会被老系统拖累,最后大概率是老代码新代码一起跑,出了问题两边都要看...
    wangxiaoaer
        51
    wangxiaoaer  
       2023-01-12 16:16:07 +08:00
    @kop1989smurf #4 我觉得是这样:如果没有 sass 话就是客户单独部署,一个客户一套代码,哪怕定制也是互相隔离的。但是 SAAS 化了以后,所有客户一套代码,定制需求上来后开发的效率、成本就跟技术栈密切相关了,典型的 C++么有 java 好招人。
    zhangky
        52
    zhangky  
       2023-01-12 16:23:46 +08:00
    招 nodejs
    gold2022
        53
    gold2022  
       2023-01-12 16:45:32 +08:00
    先找大佬处理 nodejs 的问题,再解决迁移的问题吧
    alienx717
        54
    alienx717  
       2023-01-12 21:00:29 +08:00
    代码和我总有一个能跑。
    牛逼😂
    ren2881971
        55
    ren2881971  
       2023-01-13 09:40:50 +08:00
    代码和我总有一个能跑。 哈哈哈哈
    janus77
        56
    janus77  
       2023-01-13 10:27:10 +08:00
    重写一个新项目,但是可以一点点写,然后灰度接入主项目的网关层,用以验证重写项目的稳定性和可靠性。当然你们开发的速度要快于灰度的速度,最终实现全体切换到新项目
    zhang77555
        57
    zhang77555  
       2023-01-13 11:08:45 +08:00
    无论哪种都挺难,一般遇到这种问题要么混到彻底维护不下去, 要么劝 boss 花钱做 2.0

    以原项目为基础做替换必定会遇到要向原来的设计妥协的情况,可能会导致新写的功能依旧被污染成 shi 山
    重做 2.0 会导致你们有相当长一段时间是没有产出的,并且大概率要一边维护老的一边开发新的,疲于奔命最后干不下去
    zhywang
        58
    zhywang  
       2023-01-13 14:45:22 +08:00
    他这根本不是重构,他想要的是重写。私以为百万行代码进行 Saas 化,招几个技术大佬重构一下比重写成本低多了
    RainCats
        59
    RainCats  
       2023-01-13 21:41:43 +08:00
    除非你能让老板看到技术栈替换对业务有什么利好方向,不换会有什么非常大的问题,不然准备看面试题比较好一些。
    有一句话很重要:“技术没有业务重要”
    Nazz
        60
    Nazz  
       2023-01-14 11:44:03 +08:00
    go 可以交叉编译 exe
    dream4ever
        61
    dream4ever  
       2023-01-14 17:06:01 +08:00
    100 个用户就把系统打挂了,会不会是数据库有慢查询语句……
    litguy
        62
    litguy  
       2023-01-15 08:35:19 +08:00
    100 个用户并发 ?然后决定重构 ?
    fire CTO/VP/架构师吧
    一个都不用留了
    并发出问题的瓶颈在哪里 ?有分析报告么 ?为啥重构就能解决问题 ?
    xm0625
        63
    xm0625  
       2023-04-26 11:08:21 +08:00
    “如果一个 bug 可以跑 那就不要动它” 一百万行代码的系统同理。
    1.理清业务,开发新业务时哪些资源是必须依赖老系统的
    2.新业务用 Java ,依赖的中间件做替换,替换不了的做 Proxy 代理节点兼容协议。顺带推荐一波 Golang ,好使前提是你能掌控住。
    3.依赖的数据可以通过 rpc 方式调用老业务

    慢慢的把老业务剥离,用新业务系统代替
    xm0625
        64
    xm0625  
       2023-04-26 11:14:23 +08:00
    对了 如果你只是“架构组”,旁路架构师,建议你只做多个备选方案的提案,拉大家一起来决策 /拍板 /执行。打工做事讲究的是做你层级内可以掌控的事情,你的层级不够高,如果这个事情只有 CTO 才能推的动,你就不要挑大梁,否则推动一堆阻力,做不成锅都是你的,如果是这样不如提早提桶跑路。要么就给你升职,名正才能言顺,协作关系也清晰很多。
    xm0625
        65
    xm0625  
       2023-04-26 11:20:08 +08:00
    任何的重构都需要考虑 ROI ,投这么大精力重构技术改造,交付速度能提升多少个百分点?公司收入能翻几番?否则都是不必要的。可以参考下阿里的“中台”。没有业务方买单的技术投入最终结局只有“降本增效”。
    招一个可以重构的 C+大牛 10w/月,但是优化前开发速度慢我招 10 个 1w/月的应届毕业生怼人行不行?
    felmoon
        66
    felmoon  
       2023-04-26 11:27:26 +08:00
    能不能通过业务分片或者简单改造网关实现横向扩展了 这样风险小也比较快
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3278 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 34ms · UTC 00:46 · PVG 08:46 · LAX 17:46 · JFK 20:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.