传统软件行业、工业信息化
原来的业务系统是用 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
sampeng 73 天前 via iPhone ![]() 你层级多高? cto 或者总监这件事可行,否则,只能是你跑…
|
2
cutepig 73 天前 via Android ![]() 切身经历告诉我,不要寄希望于彻底重写一次到位,尽量想如何一点一点替换
|
![]() |
3
zu1y 73 天前
Node.Js 套 C++还是第一次见 讲讲怎么玩的
|
![]() |
4
kop1989smurf 73 天前 ![]() |
![]() |
5
vivisidea 73 天前 ![]() 试试新需求用 Java 实现,然后用跨语言的 rpc 与原有系统连接,比如 grpc
原来的能不动就不动了,又不是不能跑 :D 百万行的代码的项目,从零开始 Java 重写?想想就头皮发麻 |
![]() |
6
yiqiao 73 天前
悄无声息的挂了?写过脚本监听端口掉了自动重启试试?我们就是这么干的
同意 2 楼,只能慢慢迭代 |
7
roundgis 73 天前 via Android
超過一百萬行重寫除非是換領導了
不然 |
8
imv2er 73 天前 ![]() 附议楼上的 C# 调用 cpp 更方便。但是为了微服务啥的,招人和开发效率 建议 java 但是硬件要提高。
如果真像你说的 nodejs 是 tomcat 的话 那 nodejs 可以直接丢弃。另外一百万行代码不可怕 js 代码永远都是一坨坨的,cpp 也有头文件无形中增加了太多没用代码 还有一个办法把 c++的业务方法都找出来 jndi+springboot 说白了就是套一层 java 壳。然后你就可以慢慢的把 c++的消化掉 |
![]() |
9
adoal 73 天前 via iPhone
接入层架好网关慢慢做灰度迁移吧
|
10
WispZhan 73 天前
这是个典型的遗留系统迁移。
关键字“遗留系统”,“防腐层”。 你会得到很多相关的常用套路。 个人建议平滑过度,补齐单元测试、集成测试。 挨个模块挨个模块迁移。 这个课题很大,几句话说不清楚。也不想说,点到为止。 |
11
KENNHI 73 天前 via Android
早知道,还是 Java.jpg
|
12
xsen 73 天前
我们就有类似的情况,原有的整套都是 C++写,代码量五十万网上
其实思路就是——模块化、服务化 简单点就是内部一部份一部份的拆出来,然后再服务化(这个过程是不换语言的);服务化之后,就可以看机会一个服务一个服务重写、重构,若 Java/Go/C++这些 |
13
xsen 73 天前
一开始先别考虑什么微服务(如引入网关、注册中心什么的),不划算。开始要做的就是解耦,模块化、服务化、再重构重写
|
14
buruoyanyang OP @sampeng 目前是架构师(新任命的),CTO 想搞这个事情。
|
15
buruoyanyang OP @cutepig 现在的想法就是慢慢替换,一次性重写实在是风险太高了,现场太多了
|
16
buruoyanyang OP @zu1y 具体细节我也不清楚,大概就是 NodeJs 直接调用 dll 里面的函数?
|
17
forbreak 73 天前
首先排除重写这个选项。既然微服务了,就新的用 java 写。 不出问题的不换,出问题的模块慢慢换成 java 。这是一个长期的规划,不要想着一次解决问题。 对了 java 写久了,最后一样会变成屎山的。 要我说能跑就行,实在跑不了了在原有上面改才是最稳妥的。 屎山换语言也还是屎山。
|
18
buruoyanyang OP @kop1989smurf 因为目前表现来看,是 NodeJs 这一层问题很大,又没有足够强的大佬。第二个就是业务系统,C++可用的组件太少了,开发效率也不高。第三个就是自己造的低质量轮子太多了,已经维护不过来了。
|
19
buruoyanyang OP @yiqiao 我们目前也做到了,自动重启,但是我们的行业特殊,自动重启是要被审计...
|
20
buruoyanyang OP @imv2er jndi 也考虑过,哈哈哈,主要是原来的业务系统同事有抵触,而且这种东西容易出现做好了是应该的,做不好是 shabi 这么个情况
|
21
buruoyanyang OP @WispZhan 哈,感谢
|
22
buruoyanyang OP @forbreak 直接推到重写不现实,C++那边也没实现微服务化。至于代码层面,跑起来的代码才是好代码,但是从目前的技术需求来看,以我们公司现有的储备,维护会愈发困难。
|
![]() |
23
opengps 73 天前
了解下云架构,既然 op 补充说弹性扩容能力,那么完全可以适当改造就具备(具体改多少看具体业务)
我最早就是因为直接面对负载量保障,所以从云计算的一开始就各种探索,最后找到了云的思路,重集群轻单机 |
24
buruoyanyang OP @opengps 这个也是一个思路,核心问题就是如上我说的,我们没有横向扩展的能力,虽然我们有网关(我们叫调度服务)和注册中心(别问,问就是理解不一致)
|
25
cp19890714 73 天前
既然用微服务了,那就可以异构微服务。
迁移原则是:仅在必要时或极低成本时迁移,C 代码以保留为主,迁移为辅。 * 在 nodejs 前再加一层,用于兼容微服务间调用方式,如 http 。 * 老代码以保留为主,分离为辅。 * 如果 1 个模块功能已经比较完善,那就不必要用 java 重写,直接 http 调用 * 如果 1 个模块在未来需要大量开发,那就用 java 开新服务。这样 1 个模块既有 java 代码,也有 c 代码。这个模块内部,需要功能间方法调用,如果功能简单,则可以直接以 java 重写,如果功能复杂,则 http 调用。 Dubbo 支持异构微服务,其他的技术栈你可以再找找。 |
![]() |
26
xuanbg 73 天前
首先,你要把基于 windows 的 C++程序改成基于 Linux 的。这一步其实不难,最多重写 make 文件。
然后,把 C++的巨石服务尽可能分拆为多个单领域服务,譬如:组织机构、用户、角色、订单等等。 最后,无非就是容器化,这个就好简单了。 |
27
bjhc 73 天前
模块拆分吧,先从边缘业务开始重写,慢慢替换,过程中可能还需要新旧系统同时跑。
|
![]() |
28
luvsic 73 天前
2 、现在 NodeJs 这一层目前处于不够稳定的状态,经常悄无声息的挂了,也没有特别牛的技术储备。
挂了无所谓,pm2 启动 NodeJs ,再重启呗 |
29
buruoyanyang OP @luvsic 我们是面向工厂的,而且行业特殊,重启是要被审计的...
|
30
xworkwithreader 73 天前
能不动就别动...
|
31
star7th 73 天前
用过 nodejs 多年,表示 nodejs 和 C++两者的性能都是非常高的 。nodejs 作为应用层还是非常合适的。如果只能 100 并发,肯定是你们的代码哪里阻塞的问题。但是你们的技术储备没有懂 nodejs 的,那就没办法了。
|
32
god7d 73 天前
哈哈哈,100 个用户就挂了。但是 100 万行代码看着都头大呀,我觉得动架构真的很需要勇气,而且完成之后带来海量的问题,到时候万一绝望了怎么办,我看大概率只能你跑了。
|
33
star7th 73 天前
我的建议是,不要重写,而是把原有的优化。你们的问题是在于没有招到 nodejs 的人才。假如实在找不到,再考虑换技术栈的事情。感觉你们公司有其他技术栈的软件,却招一推 java 程序员,感觉招聘这块没有针对性。如果你确定全部转到 java 块,那么,重构风险你就背吧。个人觉得历史包袱应该蛮多的
|
34
buruoyanyang OP @star7th 确实,我们内部一直认为是人的问题,完全没到语言的瓶颈,但是奈何是没有 NodeJs 的储备,原来搞这套的人已经跑路了,现在都是 C++的同事兼着 NodeJs...
|
35
buruoyanyang OP @god7d 杭州的工业信息化圈子就这么大,不行就回到老东家划水(手动狗头)
|
36
god7d 73 天前 ![]() @buruoyanyang 你们是做 mes 系统的吗,还是其他的工业系统,我是做设备研发的,算是半个同行,感觉这行很多公司用的是 C#或者 java 呀,我是一直用 C#的
|
37
buruoyanyang OP @god7d 哈,是的。我们公司的业务老大是 C++出身...
|
![]() |
38
zjsxwc 73 天前
记录日志找到 node 挂的原因,修复这个老系统稳定性。
新业务用楼主擅长的搞。 |
![]() |
39
loryyang 73 天前
一般解法都是另起炉灶,慢慢迁移过去。你们搞个新系统,慢慢加功能,满足部分用户需求,把这部分用户迁移过去。顺便梳理下,原系统的功能,没用的就干掉。
但是即使如此,也是很漫长,非常耗费人力物力 最后一个终极问题:你如何确保新的代码不会变成屎?凭什么这次就会不一样? |
40
jjx 73 天前
100 个并发就挂 而且机器不能扩容
那瓶颈在 io? db? 否则扩容一般就可以 如果瓶颈在 io? 不换语言应该也能解决 |
41
urnoob 73 天前 ![]() @buruoyanyang
想当年第一家公司做 MES 就是 java. 这类系统 C#也很合适。 过往公司也有平台和业务都是 CPP 然后套上 nodejs 结果很快淘汰了。 总结下经验选项有三 一路 c++到底,把 nodejs 也用 c++换掉 套壳 java/C#慢慢替换 重新写一套替换老系统 另外 mes 之类的不要上微服务搞什么服务发现之类的噱头, 拆分成单独应用相互调用就好了。 |
![]() |
42
8355 73 天前
核心问题还是你能不能推动这个事
其次就是 java 的全套微服务改造不仅仅是业务代码 要求有运维能力 从落后 N 久到跟上时代 新中间件用的可不少.... 开发业务代码成了相对最简单的事 |
![]() |
43
ProProPro 73 天前
确实庞大的和复杂的。
首先是技术栈的变换,这个主要视员工技术栈而定,楼主说了,有 java 人才,而且自己也是 java 人才,所以 这点没毛病。 但是,一入 java 深似海,各种框架,中间件,组件,分布式,DevOps ,容器。。。。这些都需要攻克的,基础工具(代码,api 文档,知识库等等)和流水线还是要搭建好。。。 第二,关于业务系统重构,从边缘系统开始,让兄弟们练手 |
![]() |
44
xieren58 73 天前
直接上 rust, 一劳永逸.
|
45
jjwjiang 73 天前 ![]() 我感觉你根本没有弄清楚瓶颈在哪,就想着重构。重构不是万能药,你如果对目前的困境没有认知,甚至不知道怎么解决当前的问题,重构是必然失败的。
个人建议 1. 找清楚当前时不时崩溃的原因,通过各种方式得出一个在当前局面增强稳定性的方案 2. 评估重构的代价,重中之重是从当前如何平滑过渡到重构的方案 3. 评估重构成功之后的优势,从业务角度和运维角度,评估 1 和 3 ,最终得出方向性结论 |
46
yuedun 73 天前
这其实是一场政治问题,并不是技术问题
|
![]() |
47
yaphets666 73 天前
无论如何是另起炉灶,还是怎么样,都得先解决 nodejs 的问题,解决的 nodejs 的问题,保证能交付,剩下的怎么搞都可以了。
|
48
sky857412 73 天前
感觉应该从机器不能扩容这个方向去解决,把一些共享的状态加锁,应该就可以完成扩容了吧。百万级别的代码重构和变成异构架构听着就头大
|
![]() |
49
ericgui 73 天前
nodejs 又不是很难,你就修一下呗
实在行不行,可以把 nodejs 用 typescript 改造一下,肯定比 js 稳多了 你先解决眼前的问题,再考虑重写 |
![]() |
50
crayygy 73 天前
超过一百万行基本上没有迁移的可能了,这个技术债几乎会永远存在了,即使写了新的系统,也会被老系统拖累,最后大概率是老代码新代码一起跑,出了问题两边都要看...
|
51
wangxiaoaer 73 天前
@kop1989smurf #4 我觉得是这样:如果没有 sass 话就是客户单独部署,一个客户一套代码,哪怕定制也是互相隔离的。但是 SAAS 化了以后,所有客户一套代码,定制需求上来后开发的效率、成本就跟技术栈密切相关了,典型的 C++么有 java 好招人。
|
![]() |
52
zhangky 73 天前
招 nodejs
|
53
gold2022 73 天前
先找大佬处理 nodejs 的问题,再解决迁移的问题吧
|
54
alienx717 72 天前
代码和我总有一个能跑。
牛逼😂 |
![]() |
55
ren2881971 72 天前
代码和我总有一个能跑。 哈哈哈哈
|
![]() |
56
janus77 72 天前
重写一个新项目,但是可以一点点写,然后灰度接入主项目的网关层,用以验证重写项目的稳定性和可靠性。当然你们开发的速度要快于灰度的速度,最终实现全体切换到新项目
|
![]() |
57
zhang77555 72 天前
无论哪种都挺难,一般遇到这种问题要么混到彻底维护不下去, 要么劝 boss 花钱做 2.0
以原项目为基础做替换必定会遇到要向原来的设计妥协的情况,可能会导致新写的功能依旧被污染成 shi 山 重做 2.0 会导致你们有相当长一段时间是没有产出的,并且大概率要一边维护老的一边开发新的,疲于奔命最后干不下去 |
58
zhywang 72 天前
他这根本不是重构,他想要的是重写。私以为百万行代码进行 Saas 化,招几个技术大佬重构一下比重写成本低多了
|
59
RainCats 71 天前
除非你能让老板看到技术栈替换对业务有什么利好方向,不换会有什么非常大的问题,不然准备看面试题比较好一些。
有一句话很重要:“技术没有业务重要” |
![]() |
60
Nazz 71 天前
go 可以交叉编译 exe
|
![]() |
61
dream4ever 70 天前
100 个用户就把系统打挂了,会不会是数据库有慢查询语句……
|
![]() |
62
litguy 70 天前
100 个用户并发 ?然后决定重构 ?
fire CTO/VP/架构师吧 一个都不用留了 并发出问题的瓶颈在哪里 ?有分析报告么 ?为啥重构就能解决问题 ? |