What？接手TOP1风险项目？……真香

作者|王若冰

2016年4月，我接到了华为的招聘电话：“我们急缺懂数据库和JAVA的人，你愿意来吗？”

说起华为我并不陌生，十几年前我毕业那会儿，听说华为“待遇好，工作强度大”，所以我选择了“福利好，时薪高”的外企。

而如今，外企却是王小二过年一年不如一年，竞争力江河日下，我也即将面临中年危机。

反复权衡之后，我决定放手一搏，加入华为。

从怀疑人生到小试身手

我做了十几年的软件项目，从电力到金融，从电商到汽车，基本上都围绕着数据库和JAVA展开。但加入新部门后，我发现实际的工作内容与预期大相径庭——华为的数据库使用的是华为自研产品。语言虽然是JAVA，但框架却从没听过。业务场景基本是围绕通信的，与传统互联网业务差距很大。这意味着我一半的技能点白点了。

我参与的项目是DCN控制器，目标就是用一套软件系统控制物理数据中心内的所有网络产品，不但包含交换机、防火墙等硬件产品，而且也包含软件产品。部署我们的软件之后，网络管理员只需要坐在办公室，登陆我们的软件系统，点点鼠标，就可以遥控数据中心的网络配置，不再需要跑机房，拉网线或者在网络设备上敲一堆晦涩难懂的命令。

由于这是产品的第一个版本，从平台到业务都是全新的代码，联调进展比较缓慢。与此同时，没有版本也意味着一线无货可卖，一线对版本的交付时间咬得很死，项目进展异常挑战。

好在整个团队没有谁撂挑子，逐个问题死磕，感觉无时无刻不是在写代码、改bug，经常调通了一个接口，一看时间已经是第二天了。

就这样，我一边参与项目，一边恶补通信知识。我逐步了解到，产品的框架虽源于开源项目，但仅限于通信行业，和我熟悉的IT框架不同，技术圈相对封闭。我琢磨着，按这个节奏学下去，自己得花上个两三年才能基本掌握产品技术。这么一折腾，岂不是和刚毕业的大学生站在同一起跑线上了吗?

就在我怀疑人生时，产品遇到一个棘手的问题——并发性能不达预期且存在概率性失败。这就意味着多台虚拟机同时加入网络时，系统响应会变慢，甚至影响到正常业务。项目组立即抽调精兵组织攻关。

专家们检视了平台机制和业务代码，但没找到问题所在。出于对数据库技术的敏感，我推测是编排过程中产生的大量“锁”造成的。就好比只有一个门的房间，遇到紧急情况，大家都想夺门而出，结果都被卡在门里了。要降低冲突概率，就必须让大家有序出门，防止卡住，也就是梳理锁顺序，避免死锁。

我把想法与思路和盘托出，获得了大家的认可。在业务专家的配合下，我系统梳理场景并尝试加入了新的锁机制，不到几天时间，便彻底解决了并发问题。我也在部门里多了一个“性能专家”的Title。此刻，我的心情豁然开朗，没想到这么快就有机会一显身手了。

武功再高也怕菜刀

几个月后，部门筹建公共组，旨在解决控制器产品中的疑难杂症和共性问题，并对接平台团队，我也光荣的成为其中一员。

不久，我就接到了第一个挑战任务——容器网络高并发解决方案，目标是达到每分钟要处理1万个虚拟机的上线请求，这样我们的系统不但可以对接公有云，也可以应付物联网、车联网这种终端上下线非常频繁的网络场景。

对于控制器来说，性能要优化250倍，分明是“大跃进”。再说了，我们产品的优势是强一致性，现在要和友商比拼性能，就好比让坦克和小轿车去飙速度，臣妾做不到啊！

但我转念一想，目标越是挑战不就越能体现自我价值吗？退一步说，如果换个任务，那些闻所未闻的通信场景，我就有把握搞得定吗？要干就干吧！

性能优化，我自认还是很有经验的，对内存、CPU、线程一通分析，很容易追踪到问题代码。经过一个月的优化，性能提升到了每分钟处理500个虚拟机上线请求，相比优化前提升12倍。

再往后就比较难了，明显的问题点已经找完了，优化进展逐渐停滞。那时候我在吃饭过程中、上下班的路上，甚至在梦里都在琢磨着如何优化方案，可实际的优化效果却不尽人意。

这时候领导来给我减压，问我最多能优化到多少？我给自己留了点余地，说“每分钟1000个吧，最多2000个。”

领导说：“行，那我们就先定个小目标：每分钟1000个请求。”

虽然依旧没有好方案，但目标降低了，压力瞬间小了，我决定静下心把代码系统地捋一捋。

功夫不负有心人，我很快就有了新发现：虽然很多产品代码曾经优化过，但是这些代码都是自研开发的。

实际上，相关的开源产品在IT大厂中已经广泛使用，可以节约大量的开发成本。

并且，常用的开源产品，性能和质量往往都是业界领先的。当然，缺点是难以响应定制需求。

权衡再三，基于项目实际情况，我决定把开源方案引入到产品中，尝试替代自研模块，观察效果。

没想到经过一番捣鼓后，性能居然翻了几倍。看来武功再高也怕菜刀！经过这轮优化，并发性能达到了每分钟2000个请求。

春节闭关，挑战业界最高性能

我美滋滋地想，这回可以交差了吧？

没想到，领导又来鼓励我了：“若冰，干得漂亮！不过，每分钟处理1万个请求代表着业界最高性能，你的钻研能力我们有目共睹，我相信你一定能搞得定！”

其实到了这份上，如果就此打住我也有点不甘心，为啥不突破业界最高峰呢？可是问题代码已经整改了，开源中间件也用上了。如果再优化，那只有改动流程和机制了，但是这样做，改动量和风险都会非常大。

肥肉吃完了只能啃硬骨头了。我第一个想到的方案是拿“长事务”动刀。

事务是指需要保障业务完整性的一串关联操作。比如去银行转账就是一个事务。正常情况下会从我的账户划款到对方账户，即使失败了，我们俩的账户都没有变化。绝不允许出现我的账户上钱没了，对方账户上也没到账的事。

传统的IT事务只需要保证数据库的账面数据一致，而我们的长事务，还要保证账面上的钱是可提取的真金白银，即所有网络设备上的配置，不能出现部分成功的中间状态。

就好比散兵作战时，大家只需要朝各自的目标前进就行。但团队作战时，就需要给每个团队配备一名指挥官负责协调数据库和设备，让两者共进共退，要么全部到达指定目标，要么全退回来。

但这样一来，灵活作战能力就会变差，对整个队伍的消耗也很大。毕竟我们的实际情况是，有时需要散兵作战，有时也需要团队作战，如果能根据作战时的实际情况，自动判断、采用作战方式，那么队伍的战斗力会变得更强。也就是说，我们可以根据业务的具体场景来判断，是采用IT事务，还是长事务，最大化地提升效率。

于是，我与数据库平台兄弟交流我的思路，得到了一个好消息和一个坏消息：好消息是IT事务的机制平台是现成的，无需额外开发。坏消息是调用流程完全不同，代码等于要重写。

恰逢春节，我一个本地宅，既不喜欢喝酒聚餐，也不喜欢春晚。好不容易闲下来，就躺在沙发上发呆，边躺着边琢磨起改造的事。躺了三天，也想了三天，改造思路日渐清晰。一方面为了验证思路，另一方面也怕过完年给忘了，干脆跑到公司写代码了。

春节期间公司里没什么人，既不担心写到一半被人打断，也不用担心和别人的代码冲突。文思泉涌般的敲了两天代码，再加上一天的调测，顺利调通了！

紧接着一测，1万个请求只用了53秒。居然比原定的1分钟目标快了7秒！我兴奋得向身旁的同事炫耀，我一巴掌拍在他肩膀上，由于用力过猛，加上同事正专心工作没反应过来，就看着200斤的小胖子，蹭地一下从座位上弹起来。揉着肩膀，一脸无辜地看着我。

TOP1风险项目也可能很香

当我还沉浸在达成挑战目标的喜悦中，领导又找到我说，有一个TOP1风险项目，已经向一线承诺尽快交付，截至目前6套设计方案全都被否了。一半时间浪费了，希望我能接手。

我一听就崩溃了，这根本就是个“炸弹”好吗？我试着先谈条件：“能否延期3个月交付？”

领导说：“不行。”

我没直接拒绝，委婉地表示：“项目情况还不清楚，先给我几天研究一下。”

经过详细摸底，我了解到，这个项目主要是提供网络控制器的模拟器，就像训练飞行员的模拟舱一样，用户可以在里面模拟飞行，不用担心坠机的危险。难点在于模拟范围覆盖产品60%的功能，如果针对每个功能做开发，代码量高达上百K，显然难以在几个月的时间内完成。

如果是传统IT项目，我第一个想到的就是运用框架的切面技术，在下发设备前对流程进行阻击。就好比在所有的入口嵌入一个对讲门铃，连接到同一个服务员，由他提供统一服务，而不必为每一个门口配备一个服务员。但是当前产品框架并不具备这种能力。

有没有其他又快又省的办法呢？我想到了基于JAVA字节码技术，这种技术比较古老，是在指定入口嵌入“对讲门铃”，并把“门铃”连接到另一块代码程序。但有个缺点，字节码晦涩难懂，像“屠龙之术”一样一直没机会实战。

我向项目组介绍了思路，大家不置可否。不过，既然没有其他方案,就死马当活马医吧！

因为手上还有其他事情要结尾，我先和项目组的“90后”小伙伴详细介绍了字节码技术，就任由他去捣鼓了。结果三天过去了，小伙伴啥也没汇报。

我觉得有些不妙，主动问了一下，结果发现这位同学在最基础的JAVA问题上卡壳了。这才知道他原先是做前端的，接触JAVA才几个月。

我一方面叮嘱他有问题赶紧找我，一方面也有点失落：“哎，看来得我自己上了”。

万万没想到，小伙伴天赋异禀，在解决了几个简单问题后，突然有一天和我说：“调通了！”

我将信将疑地进行确认，原来他在网上找了一款三方件，对字节码技术做了封装，只需要告诉三方件我需要把“对讲门铃”按到门上，由三方件负责完成“打孔-安放门铃-固定螺丝”的步骤。

太赞了！我情不自禁的给他竖起了大拇指。

有了demo，剩下的就好办了，我简单补充了设计方案，申请评审。

方案设计虽然有些简陋，但看到demo演示后，领导们赞不绝口。方案评审一次通过。

2个月后，项目顺利进入转测。TOP1风险项目的名头也被摘掉了。

正当我得意之时，测试发来了一堆问题单。起初我没太在意，不就是bug嘛，改就是了。结果发现有些问题是由于前期考虑的不充分，漏了需要平台适配的功能。如果产品单方面修改，不但工作量巨大，软件架构也会变得很脆弱。

且不说增加工作量，牺牲软件架构会导致后期的维护和扩展难度增大，这点我是无法接受的。可如果按流程来，需要先向平台提需求，再安排开发计划，等我们拿到适配后的版本，估计得两三个月之后，到时候项目也黄了。

我决定“越俎代庖”，把平台的代码找来，一边请教平台的哥们，一边自己修改联调。调通后再申请回合代码。平台Committer在充分评估了代码后，很爽快地同意了回合要求。

就这样遇山开山，遇水搭桥，原本两三个月的流程，一个月就搞定了。

我依然是一个“新人” 

2020年伊始，我得知平台打算逐步去掉当前框架，转型IT框架，需要产品配合整改。转IT框架可是我梦寐以求的，于是我申请加入该项目。

由于以前的框架更为包容，很多的问题、冗余和冲突在这次整改中完全暴露出来，好比建房子每个人都在添砖加瓦，但是整体设计风格迥异，每面墙的厚度不同。切换轻量级框架就要精确计算每块砖的位置，统一设计风格。

我挑了一个最简单的微服务作为首批改造对象。在平台兄弟的支持下，花费一周时间研究梳理组件代码，对现有问题进行风格统一后，问题竟然迎刃而解。产品的第一个微服务很快改造完成。

后期我在改造复杂的微服务时，就没有这么顺利了，有很多还依赖平台组件的适配，导致一些微服务至今还没有改造成功。

不过，好在这种改造可以改一个上一个，不要求产品内的所有微服务一下全部改造完，所以可以一点点优化和调整。

迈出转型IT框架这一步，似乎又回到了我熟悉的赛道。

回想加入华为的三四年，我觉得自己很幸运，赶上了华为ICT转型，我也从当初的懵懂，到现在的游刃有余，还将继续以空杯心态迎接下一个未知挑战。

在华为这条大船上，我依然是一个“新人”。唯有扎根技术，才可乘风破浪，迎风远航。

本文为《华为人》版权所有，未经允许不得转载。如需转载请联系编辑部hwrb@huawei.com