[狗头] 我就是那个改动百万行代码业务系统的练习两年半的架构师

[buruoyanyang]

前情提要： https://v2ex.com/t/908250#reply62

后续

1 、提单子了。
2 、过了年以后一直是文档工程师。
3 、很多时候不是技术的问题。

我做了什么

原系统迁移到Linux上，并支持容器化。
推动服务拆分，实现了部分核心模块的微服务，并支持横向扩容
使用Java重构了部分公共服务

核心矛盾

我希望尽量保持原业务不变的基础上，采用慢慢替代的方式，实现平稳过渡。也就是原有的业务完成迁移，新业务使用Java开发。
原来的架构师（也就是现在的产品经理）希望继续沿用原来的架构，后续的新业务也是这么做。并且希望我接过NodeJs那一层。
借用一句C++开发同事的话，虽然所有的系统都会变成屎山，但是这个项目的屎山进度也太快了。
当然，中间还有一些比较恶心、反复的事情。
总之就是，既然都是打工，我为什么不去一个让我爽的地方

[defunct9]

提桶跑路上上策

[Bazingal]

所以处理方案是什么呢

[encro]

看懂 100 个人访问就奔溃了，然后看到解决方案是用 java ，就知道不靠谱了。。。

因为没有人关心为什么奔溃。。。

[NoKey]

百万行重构，cto 来都不敢随便决定的吧~

[whileFalse]

@encro 是不是可以这么说，与其吃屎的时候把所有硌牙的东西从屎里挑出来，不如炒个菜吃？

[kop1989smurf]

@encro
@whileFalse
还是我原帖的说法，就是 SaaS 化，并不意味着要推倒重来。
楼主非要把需求和技术栈关联在一起，注定就是会出问题。

[buruoyanyang]

@encro 不是没人关心为什么崩溃，是查不出为什么崩溃，并且原来的人直接摆烂了。至于 100 个人访问的并发瓶颈，大家都知道哪一层的问题，但是是业务核心的设计，他不放。所以我才有想法用我熟悉的语言 /手段解决问题。总的来说就是业务核心是原来的架构师，他坚称自己的架构没问题，CTO 其实有点被裹挟了。还有就是对于我们这个行业来说，能顶住 20 个并发就差不多了，100 个并发问题被发现的原因是上了一个大型规模的厂。（当然，测试早发现这个问题了，狗头）

[zbinlin]

为什么不尝试去学 nodejs 来解决 nodejs 的问题呢？

[airqj]

@buruoyanyang 跟 CTO 合伙让架构师滚蛋吧[狗头]

[HaroldFinchNYC]

@buruoyanyang 多打点 log ，什么火焰图，什么 profiling ，十八般兵器都用上，肯定能查出来点什么头绪

[night98]

这种都不用看，没有顶层的强力支持，你还不如摆烂，先把前架构干掉再说，否则后续的事情你都执行不下去。

[urnoob]

我还留言过的。
提单子是离职？

[Seanfuck]

屎山进度快是因为 nodejs 吧，这个改起来也挺麻烦的

[buruoyanyang]

@Seanfuck 最早搞 NodeJs 那一层的人，只有一个，然后他生病离职了。其次是原来的架构下，查一条数据，需要 C++调用 NodeJs 的 Data 服务，NodeJs 查完数据库后返回给 C++，实在是太墨迹了~~~

[hooych]

你这是在动 C++团队的蛋糕，都按你的方案做，他们岂不是没事情做了，所以会抵制；

如果公司有高层支持，就原 C++团队继续维护，你拉一支团队搞 Java 化，做 2.0 版本。

[Matthew66]

又不是不能用.jpg

[buruoyanyang]

@hooych 是的，所以不只是技术的问题

[dudubaba]

这属于技术绉。体量也不大，搞不好没重构完公司都倒了。

[likunyan]

人或程序能跑就行

[winglight2016]

用什么语言对领导不重要，但是对开发来说很重要，你上来就要换语言谁能支持你？

我这里有类似的问题，我的解决办法也是慢慢迁移，但是是通过建立新的微服务来取代旧服务，这样新的微服务用什么语言跟旧系统没有关系，就不会影响别的开发。

[buruoyanyang]

@winglight2016 CTO 让我换的。。。不然我怎么敢起头。现在是老架构不让我迁移。。。

[nkidgm]

慢慢迁移也不行哈，一触碰到 C++核心那块，你就得让步，最后各种妥协还不是搞成和 nodejs 一样的境地。

公司内部谁的势力大，就让这个势力主导吧。。。别动人家的蛋糕了。。。人家核心是主力 C++，那就全员 C++呗。。。。人员战斗力强的话，C++开发的东西也可以粗服务化的，拉 nodejs 进来估计是为了解决开发效率的问题，问题是 C++架构组那边 hold 不住这个技术吧？

直接梭哈 C++吧，让他们随公司天荒地老。

[nkidgm]

@hooych 哈哈，这就要看领导的决心。。。在完全覆盖老团队的业务面之前，这个 2.0 就得一直在烧钱。。。还不一定能顺利平滑过渡，具体要看 CTO 有多嫌弃之前得老架构了哈

[marly]

为什么是两年半？(doge

[encro]

@buruoyanyang

业务核心的设计 不是原因。。。

技术上核心的原因通常是达到了某个物理瓶颈，

比如某个程序 cpu 运算速度，磁盘 io ，网络带宽等。。。

如果不能定位到物理原因，所有的解决办法都是盲人摸象！！！耍流氓！！！就好像脚痛去医院看医生直接什么都不检查就截肢！！！



@HaroldFinchNYC 提到的 log ，什么火焰图，什么 profiling 都是定位性能的办法，

只有先定位到瓶颈，然后再决定用什么办法。

曾经 N 个公司，我去了的时候一堆问题，大家都觉得要立马要重构，其实采用二八原则，花一两周解决关键问题，至少又能跑个一年半载。

当然，可能最后发现某业务就是这么复杂，已经达到物理瓶颈或者复杂度瓶颈，那么就拎出去，为这个服务单独部署。。。

[brust]

没看懂为什么 100 个并发会奔溃？

[AnroZ]

你们公司不会碰巧就在杭州滨江吧，感觉像是认识的

[a1274598858]

我家哥哥下蛋你别吃

[liuidetmks]

不谈技术，你这么搞是不是得新招 java 替代旧开发？你这不仅是技术升级，更是公司人员换血呢

为什么不用 rust 呢，又潮又有快，cpp 程序员上手 rust 很快吧

如果你不是老板小舅子，推不动的。


程序员还是幼稚，什么事情都想的单纯

[unlighted]

ls 说的招 rust.我觉得暂时还不太可行,社会上相关人员储备真的够么.
关于这个项目:
1.所有业务改 java,意思 cpp 的全都得转岗或者被裁,我估计还是比较难的.
2.可以把 cpp 套个微服务架子,继续跑.
3.看原帖,什么 100 并发,都能炸掉.这是什么架构方案才能出现的问题.
4.如果只是招手底下干活的 cpp,还是好找的.写写业务罢了.做好 code style,规范化流程,也不太容易出问题