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