行业
传统软件行业、工业信息化
现状
原来的业务系统是用 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 开始一个重写业务，代码和我总有一个能跑。

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

为什么想动架构，还有个很大的原因是，我们有个现场，100 个用户的并发，直接把我们系统打挂了。客户提出，我们给你们家机器，但是我们目前没有横向扩展的能力

为什么要选择 Java ，第一是我的主力语言是 Java ，第二是公司还有其他业务线，Java 的储备还算比较足的。

感谢各位的回复，目前已经和大领导达成的策略
1 、不能一下子重构，但是可以从公共组件、边缘业务开始。
2 、尽量选择语言无关的开源组件替换。
3 、先做 Linux 化，再做无状态改造，无法改为无状态的服务考虑在网关层或者调度服务中响应。
4 、SaaS 化的事情往后拖一下，先对付现场。

你层级多高？ cto 或者总监这件事可行，否则，只能是你跑…

切身经历告诉我，不要寄希望于彻底重写一次到位，尽量想如何一点一点替换

Node.Js 套 C++还是第一次见 讲讲怎么玩的

没特别理解，SaaS 化和技术栈的改变之间的逻辑关系是什么？

如果想相对平滑的过度，其实.net （ C＃）+ IIS 是相对更稳妥的技术选型。（ c++的老库可以复用，然后灰度更新）

试试新需求用 Java 实现，然后用跨语言的 rpc 与原有系统连接，比如 grpc
原来的能不动就不动了，又不是不能跑 :D

百万行的代码的项目，从零开始 Java 重写？想想就头皮发麻

悄无声息的挂了？写过脚本监听端口掉了自动重启试试？我们就是这么干的
同意 2 楼，只能慢慢迭代

超過一百萬行重寫除非是換領導了

不然

附议楼上的 C＃ 调用 cpp 更方便。但是为了微服务啥的，招人和开发效率 建议 java 但是硬件要提高。
如果真像你说的 nodejs 是 tomcat 的话 那 nodejs 可以直接丢弃。另外一百万行代码不可怕 js 代码永远都是一坨坨的，cpp 也有头文件无形中增加了太多没用代码
还有一个办法把 c++的业务方法都找出来 jndi+springboot 说白了就是套一层 java 壳。然后你就可以慢慢的把 c++的消化掉

接入层架好网关慢慢做灰度迁移吧

这是个典型的遗留系统迁移。

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

个人建议平滑过度，补齐单元测试、集成测试。 挨个模块挨个模块迁移。
这个课题很大，几句话说不清楚。也不想说，点到为止。

早知道，还是 Java.jpg

我们就有类似的情况，原有的整套都是 C++写，代码量五十万网上
其实思路就是——模块化、服务化

简单点就是内部一部份一部份的拆出来，然后再服务化（这个过程是不换语言的）；服务化之后，就可以看机会一个服务一个服务重写、重构，若 Java/Go/C++这些

一开始先别考虑什么微服务（如引入网关、注册中心什么的），不划算。开始要做的就是解耦，模块化、服务化、再重构重写

目前是架构师（新任命的），CTO 想搞这个事情。

现在的想法就是慢慢替换，一次性重写实在是风险太高了，现场太多了

具体细节我也不清楚，大概就是 NodeJs 直接调用 dll 里面的函数？

首先排除重写这个选项。既然微服务了，就新的用 java 写。 不出问题的不换，出问题的模块慢慢换成 java 。这是一个长期的规划，不要想着一次解决问题。 对了 java 写久了，最后一样会变成屎山的。 要我说能跑就行，实在跑不了了在原有上面改才是最稳妥的。 屎山换语言也还是屎山。

因为目前表现来看，是 NodeJs 这一层问题很大，又没有足够强的大佬。第二个就是业务系统，C++可用的组件太少了，开发效率也不高。第三个就是自己造的低质量轮子太多了，已经维护不过来了。

我们目前也做到了，自动重启，但是我们的行业特殊，自动重启是要被审计...

jndi 也考虑过，哈哈哈，主要是原来的业务系统同事有抵触，而且这种东西容易出现做好了是应该的，做不好是 shabi 这么个情况

哈，感谢

直接推到重写不现实，C++那边也没实现微服务化。至于代码层面，跑起来的代码才是好代码，但是从目前的技术需求来看，以我们公司现有的储备，维护会愈发困难。

了解下云架构，既然 op 补充说弹性扩容能力，那么完全可以适当改造就具备（具体改多少看具体业务）
我最早就是因为直接面对负载量保障，所以从云计算的一开始就各种探索，最后找到了云的思路，重集群轻单机

这个也是一个思路，核心问题就是如上我说的，我们没有横向扩展的能力，虽然我们有网关（我们叫调度服务）和注册中心（别问，问就是理解不一致）

既然用微服务了，那就可以异构微服务。
迁移原则是：仅在必要时或极低成本时迁移，C 代码以保留为主，迁移为辅。

• 在 nodejs 前再加一层，用于兼容微服务间调用方式，如 http 。

• 老代码以保留为主，分离为辅。

  • 如果 1 个模块功能已经比较完善，那就不必要用 java 重写，直接 http 调用
  • 如果 1 个模块在未来需要大量开发，那就用 java 开新服务。这样 1 个模块既有 java 代码，也有 c 代码。这个模块内部，需要功能间方法调用，如果功能简单，则可以直接以 java 重写，如果功能复杂，则 http 调用。

Dubbo 支持异构微服务，其他的技术栈你可以再找找。

首先，你要把基于 windows 的 C++程序改成基于 Linux 的。这一步其实不难，最多重写 make 文件。
然后，把 C++的巨石服务尽可能分拆为多个单领域服务，譬如：组织机构、用户、角色、订单等等。
最后，无非就是容器化，这个就好简单了。

模块拆分吧，先从边缘业务开始重写，慢慢替换，过程中可能还需要新旧系统同时跑。

2 、现在 NodeJs 这一层目前处于不够稳定的状态，经常悄无声息的挂了，也没有特别牛的技术储备。
挂了无所谓，pm2 启动 NodeJs ，再重启呗

我们是面向工厂的，而且行业特殊，重启是要被审计的...

能不动就别动...

用过 nodejs 多年，表示 nodejs 和 C++两者的性能都是非常高的 。nodejs 作为应用层还是非常合适的。如果只能 100 并发，肯定是你们的代码哪里阻塞的问题。但是你们的技术储备没有懂 nodejs 的，那就没办法了。

哈哈哈，100 个用户就挂了。但是 100 万行代码看着都头大呀，我觉得动架构真的很需要勇气，而且完成之后带来海量的问题，到时候万一绝望了怎么办，我看大概率只能你跑了。

我的建议是，不要重写，而是把原有的优化。你们的问题是在于没有招到 nodejs 的人才。假如实在找不到，再考虑换技术栈的事情。感觉你们公司有其他技术栈的软件，却招一推 java 程序员，感觉招聘这块没有针对性。如果你确定全部转到 java 块，那么，重构风险你就背吧。个人觉得历史包袱应该蛮多的

确实，我们内部一直认为是人的问题，完全没到语言的瓶颈，但是奈何是没有 NodeJs 的储备，原来搞这套的人已经跑路了，现在都是 C++的同事兼着 NodeJs...

杭州的工业信息化圈子就这么大，不行就回到老东家划水（手动狗头）

你们是做 mes 系统的吗，还是其他的工业系统，我是做设备研发的，算是半个同行，感觉这行很多公司用的是 C＃或者 java 呀，我是一直用 C＃的

哈，是的。我们公司的业务老大是 C++出身...

记录日志找到 node 挂的原因，修复这个老系统稳定性。
新业务用楼主擅长的搞。

一般解法都是另起炉灶，慢慢迁移过去。你们搞个新系统，慢慢加功能，满足部分用户需求，把这部分用户迁移过去。顺便梳理下，原系统的功能，没用的就干掉。
但是即使如此，也是很漫长，非常耗费人力物力
最后一个终极问题：你如何确保新的代码不会变成屎？凭什么这次就会不一样？

100 个并发就挂 而且机器不能扩容

那瓶颈在 io? db?

否则扩容一般就可以

如果瓶颈在 io? 不换语言应该也能解决

想当年第一家公司做 MES 就是 java. 这类系统 C＃也很合适。
过往公司也有平台和业务都是 CPP 然后套上 nodejs 结果很快淘汰了。
总结下经验选项有三
一路 c++到底，把 nodejs 也用 c++换掉
套壳 java/C＃慢慢替换
重新写一套替换老系统

另外 mes 之类的不要上微服务搞什么服务发现之类的噱头， 拆分成单独应用相互调用就好了。

核心问题还是你能不能推动这个事
其次就是 java 的全套微服务改造不仅仅是业务代码 要求有运维能力
从落后 N 久到跟上时代 新中间件用的可不少....
开发业务代码成了相对最简单的事

确实庞大的和复杂的。

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

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

第二，关于业务系统重构，从边缘系统开始，让兄弟们练手

直接上 rust, 一劳永逸.

我感觉你根本没有弄清楚瓶颈在哪，就想着重构。重构不是万能药，你如果对目前的困境没有认知，甚至不知道怎么解决当前的问题，重构是必然失败的。
个人建议

1. 找清楚当前时不时崩溃的原因，通过各种方式得出一个在当前局面增强稳定性的方案
2. 评估重构的代价，重中之重是从当前如何平滑过渡到重构的方案
3. 评估重构成功之后的优势，从业务角度和运维角度，评估 1 和 3 ，最终得出方向性结论

这其实是一场政治问题，并不是技术问题

无论如何是另起炉灶，还是怎么样，都得先解决 nodejs 的问题，解决的 nodejs 的问题，保证能交付，剩下的怎么搞都可以了。

感觉应该从机器不能扩容这个方向去解决，把一些共享的状态加锁，应该就可以完成扩容了吧。百万级别的代码重构和变成异构架构听着就头大

nodejs 又不是很难，你就修一下呗
实在行不行，可以把 nodejs 用 typescript 改造一下，肯定比 js 稳多了

你先解决眼前的问题，再考虑重写

超过一百万行基本上没有迁移的可能了，这个技术债几乎会永远存在了，即使写了新的系统，也会被老系统拖累，最后大概率是老代码新代码一起跑，出了问题两边都要看...

＃4 我觉得是这样：如果没有 sass 话就是客户单独部署，一个客户一套代码，哪怕定制也是互相隔离的。但是 SAAS 化了以后，所有客户一套代码，定制需求上来后开发的效率、成本就跟技术栈密切相关了，典型的 C++么有 java 好招人。

招 nodejs

先找大佬处理 nodejs 的问题,再解决迁移的问题吧

代码和我总有一个能跑。
牛逼😂

代码和我总有一个能跑。 哈哈哈哈

重写一个新项目，但是可以一点点写，然后灰度接入主项目的网关层，用以验证重写项目的稳定性和可靠性。当然你们开发的速度要快于灰度的速度，最终实现全体切换到新项目

无论哪种都挺难,一般遇到这种问题要么混到彻底维护不下去, 要么劝 boss 花钱做 2.0

以原项目为基础做替换必定会遇到要向原来的设计妥协的情况,可能会导致新写的功能依旧被污染成 shi 山
重做 2.0 会导致你们有相当长一段时间是没有产出的,并且大概率要一边维护老的一边开发新的,疲于奔命最后干不下去

他这根本不是重构，他想要的是重写。私以为百万行代码进行 Saas 化，招几个技术大佬重构一下比重写成本低多了

除非你能让老板看到技术栈替换对业务有什么利好方向，不换会有什么非常大的问题，不然准备看面试题比较好一些。
有一句话很重要：“技术没有业务重要”

go 可以交叉编译 exe

100 个用户就把系统打挂了，会不会是数据库有慢查询语句……