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

[buruoyanyang]

行业

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

现状

原来的业务系统是用 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 开始一个重写业务，代码和我总有一个能跑。

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

[sampeng]

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

[cutepig]

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

[zu1y]

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

[kop1989smurf]

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

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

[vivisidea]

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

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

[yiqiao]

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

[roundgis]

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

不然

[imv2er]

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

[adoal]

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

[WispZhan]

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

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

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

[KENNHI]

早知道，还是 Java.jpg

[xsen]

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

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

[xsen]

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

[buruoyanyang]

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

[buruoyanyang]

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

[buruoyanyang]

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

[forbreak]

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

[buruoyanyang]

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

[buruoyanyang]

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

[buruoyanyang]

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