这是一个创建于 587 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2023-04-26 13:17:27 +08:00
我做了什么
核心矛盾
我做了什么
原系统迁移到Linux上，并支持容器化。
推动服务拆分，实现了部分核心模块的微服务，并支持横向扩容
使用Java重构了部分公共服务
核心矛盾
我希望尽量保持原业务不变的基础上，采用慢慢替代的方式，实现平稳过渡。也就是原有的业务完成迁移，新业务使用Java开发。
原来的架构师（也就是现在的产品经理）希望继续沿用原来的架构，后续的新业务也是这么做。并且希望我接过NodeJs那一层。
借用一句C++开发同事的话，虽然所有的系统都会变成屎山，但是这个项目的屎山进度也太快了。
当然，中间还有一些比较恶心、反复的事情。
总之就是，既然都是打工，我为什么不去一个让我爽的地方
 |
1
defunct9 2023-04-26 10:12:55 +08:00
提桶跑路上上策
|
 |
2
Bazingal 2023-04-26 10:38:13 +08:00
所以处理方案是什么呢
|
 |
3
encro 2023-04-26 10:44:32 +08:00
看懂 100 个人访问就奔溃了，然后看到解决方案是用 java ，就知道不靠谱了。。。
因为没有人关心为什么奔溃。。。 |
 |
4
NoKey 2023-04-26 11:00:02 +08:00
百万行重构，cto 来都不敢随便决定的吧~
|
 |
5
whileFalse 2023-04-26 11:01:43 +08:00 via iPhone
@encro 是不是可以这么说，与其吃屎的时候把所有硌牙的东西从屎里挑出来，不如炒个菜吃？
|
 |
6
kop1989smurf 2023-04-26 11:08:19 +08:00
|
 |
7
buruoyanyang OP @encro 不是没人关心为什么崩溃，是查不出为什么崩溃，并且原来的人直接摆烂了。至于 100 个人访问的并发瓶颈，大家都知道哪一层的问题，但是是业务核心的设计，他不放。所以我才有想法用我熟悉的语言 /手段解决问题。总的来说就是业务核心是原来的架构师，他坚称自己的架构没问题，CTO 其实有点被裹挟了。还有就是对于我们这个行业来说，能顶住 20 个并发就差不多了，100 个并发问题被发现的原因是上了一个大型规模的厂。（当然，测试早发现这个问题了，狗头）
|
 |
8
zbinlin 2023-04-26 12:34:39 +08:00
为什么不尝试去学 nodejs 来解决 nodejs 的问题呢？
|
 |
9
airqj 2023-04-26 12:55:06 +08:00
@buruoyanyang 跟 CTO 合伙让架构师滚蛋吧[狗头]
|
 |
10
HaroldFinchNYC 2023-04-26 12:59:39 +08:00
@buruoyanyang 多打点 log ，什么火焰图，什么 profiling ，十八般兵器都用上，肯定能查出来点什么头绪
|
 |
11
night98 2023-04-26 13:07:19 +08:00
这种都不用看，没有顶层的强力支持，你还不如摆烂，先把前架构干掉再说，否则后续的事情你都执行不下去。
|
 |
12
urnoob 2023-04-26 13:56:47 +08:00
我还留言过的。
提单子是离职？ |
 |
13
Seanfuck 2023-04-26 14:00:12 +08:00
屎山进度快是因为 nodejs 吧，这个改起来也挺麻烦的
|
|
14
buruoyanyang OP @Seanfuck 最早搞 NodeJs 那一层的人，只有一个，然后他生病离职了。其次是原来的架构下，查一条数据，需要 C++调用 NodeJs 的 Data 服务，NodeJs 查完数据库后返回给 C++，实在是太墨迹了~~~
|
 |
15
hooych 2023-04-26 14:42:16 +08:00
你这是在动 C++团队的蛋糕，都按你的方案做，他们岂不是没事情做了，所以会抵制；
如果公司有高层支持，就原 C++团队继续维护，你拉一支团队搞 Java 化，做 2.0 版本。 |
 |
16
egqpwU3F2beQ8V77 2023-04-26 15:42:16 +08:00
又不是不能用.jpg
|
|
17
buruoyanyang OP @hooych 是的，所以不只是技术的问题
|
 |
18
dudubaba 2023-04-26 15:49:27 +08:00
这属于技术绉。体量也不大，搞不好没重构完公司都倒了。
|
 |
19
likunyan 2023-04-26 15:53:28 +08:00
人或程序能跑就行
|
 |
20
winglight2016 2023-04-26 15:53:50 +08:00
用什么语言对领导不重要，但是对开发来说很重要，你上来就要换语言谁能支持你？
我这里有类似的问题，我的解决办法也是慢慢迁移，但是是通过建立新的微服务来取代旧服务，这样新的微服务用什么语言跟旧系统没有关系，就不会影响别的开发。 |
|
21
buruoyanyang OP @winglight2016 CTO 让我换的。。。不然我怎么敢起头。现在是老架构不让我迁移。。。
|
 |
22
nkidgm 2023-04-26 16:19:35 +08:00
慢慢迁移也不行哈，一触碰到 C++核心那块，你就得让步，最后各种妥协还不是搞成和 nodejs 一样的境地。
公司内部谁的势力大，就让这个势力主导吧。。。别动人家的蛋糕了。。。人家核心是主力 C++，那就全员 C++呗。。。。人员战斗力强的话，C++开发的东西也可以粗服务化的，拉 nodejs 进来估计是为了解决开发效率的问题，问题是 C++架构组那边 hold 不住这个技术吧？ 直接梭哈 C++吧，让他们随公司天荒地老。 |
|
23
nkidgm 2023-04-26 16:27:15 +08:00
@hooych 哈哈，这就要看领导的决心。。。在完全覆盖老团队的业务面之前，这个 2.0 就得一直在烧钱。。。还不一定能顺利平滑过渡，具体要看 CTO 有多嫌弃之前得老架构了哈
|
 |
24
marly 2023-04-26 16:30:06 +08:00
为什么是两年半？(doge
|
|
25
encro 2023-04-26 16:33:40 +08:00  1
@buruoyanyang
业务核心的设计 不是原因。。。 技术上核心的原因通常是达到了某个物理瓶颈， 比如某个程序 cpu 运算速度，磁盘 io ，网络带宽等。。。 如果不能定位到物理原因，所有的解决办法都是盲人摸象！！！耍流氓！！！就好像脚痛去医院看医生直接什么都不检查就截肢！！！ @HaroldFinchNYC 提到的 log ，什么火焰图，什么 profiling 都是定位性能的办法， 只有先定位到瓶颈，然后再决定用什么办法。 曾经 N 个公司，我去了的时候一堆问题，大家都觉得要立马要重构，其实采用二八原则，花一两周解决关键问题，至少又能跑个一年半载。 当然，可能最后发现某业务就是这么复杂，已经达到物理瓶颈或者复杂度瓶颈，那么就拎出去，为这个服务单独部署。。。 |
 |
26
brust 2023-04-26 19:34:34 +08:00
没看懂为什么 100 个并发会奔溃？
|
 |
27
AnroZ 2023-04-26 19:44:03 +08:00
你们公司不会碰巧就在杭州滨江吧，感觉像是认识的
|
 |
28
a1274598858 2023-04-26 20:33:56 +08:00
我家哥哥下蛋你别吃
|
 |
29
liuidetmks 2023-04-27 07:38:10 +08:00 via iPhone
不谈技术，你这么搞是不是得新招 java 替代旧开发？你这不仅是技术升级，更是公司人员换血呢
为什么不用 rust 呢，又潮又有快，cpp 程序员上手 rust 很快吧 如果你不是老板小舅子，推不动的。 程序员还是幼稚，什么事情都想的单纯 |
 |
30
unlighted 2023-04-27 12:44:09 +08:00
ls 说的招 rust.我觉得暂时还不太可行,社会上相关人员储备真的够么.
关于这个项目: 1.所有业务改 java,意思 cpp 的全都得转岗或者被裁,我估计还是比较难的. 2.可以把 cpp 套个微服务架子,继续跑. 3.看原帖,什么 100 并发,都能炸掉.这是什么架构方案才能出现的问题. 4.如果只是招手底下干活的 cpp,还是好找的.写写业务罢了.做好 code style,规范化流程,也不太容易出问题 |
Select Language