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

2023-01-11 20:32:25 +08:00
 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 开始一个重写业务，代码和我总有一个能跑。

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

6867 次点击
所在节点    程序员
66 条回复
buruoyanyang
2023-01-12 09:28:08 +08:00
@WispZhan 哈，感谢
buruoyanyang
2023-01-12 09:33:31 +08:00
@forbreak 直接推到重写不现实，C++那边也没实现微服务化。至于代码层面，跑起来的代码才是好代码，但是从目前的技术需求来看，以我们公司现有的储备，维护会愈发困难。
opengps
2023-01-12 09:41:43 +08:00
了解下云架构，既然 op 补充说弹性扩容能力，那么完全可以适当改造就具备（具体改多少看具体业务）
我最早就是因为直接面对负载量保障，所以从云计算的一开始就各种探索，最后找到了云的思路，重集群轻单机
buruoyanyang
2023-01-12 09:44:47 +08:00
@opengps 这个也是一个思路，核心问题就是如上我说的，我们没有横向扩展的能力，虽然我们有网关（我们叫调度服务）和注册中心（别问，问就是理解不一致）
cp19890714
2023-01-12 10:02:35 +08:00
既然用微服务了，那就可以异构微服务。
迁移原则是：仅在必要时或极低成本时迁移，C 代码以保留为主，迁移为辅。

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


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

那瓶颈在 io? db?

否则扩容一般就可以

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

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/908250

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX