前端梦想到后台开发的365天

恣意生长的365天

口述：程康

 撰文：南研终端分部&南研二十年采编组

2018年的夏季，带着“前端工程师”的梦想，我进入了华为。

万万没有想到，365天后，我却在“后台开发”领域闯出了一片天地。

0天：

一激动从“前”到了“后”

我毕业于南京大学，专业是软件工程，在校期间做的项目大多是前端开发相关的，我也理所当然地认为自己将来应该是个“前端工程师”吧。

2018年6月的一天，我接到一个电话，从此一个叫王志红的男人就这样闯入我的生活。大红哥是我即将入职的华为部门的主管，他在电话里给我详细介绍了云服务的情况，其中涉及到端侧和云侧的协同打通，听到这个自己未知领域的介绍，我内心有点激动，当即就对云侧的开发产生了兴趣。

云侧开发属于后台开发，我以前了解不多，只能恶补知识。于是南大图书馆成了我毕业前最爱光临的地方，大红哥还发了一个学习清单给我，里面详细梳理了我上岗后所涉及的技术栈及其学习资料、推荐书籍。我按图索骥，苦学了一个月，还真的在毕业前好好地践行了南大校训“诚朴雄伟，励学敦行”。

2018年7月2日，我正式进入部门。工欲善其事，必先利其器。第一个月，我开始像海绵一样，疯狂学习吸收各种知识，特别感谢南研终端部门组织的创新营，帮助我把所有云服务相关的知识串联并实践了一次。这个时候我觉得自己已经“充满电”了，迫不及待等待着机会，想要大展身手。

31天

开发产品得多角度

进华为第31天，机会终于来了，导师让我独立承接短地址服务，并会全程提供帮助。

短地址服务，是消费者云服务中的一个微服务，顾名思义就是将原来冗长的地址缩短成较短的地址，使用户在分享链接的时候，除了地址信息外还能够看到更多的有效内容信息，就比如在分享电商平台的商品链接的时候，还可以看到商品的名称、特征、竞争力等。

这些听上去很有意思，已经让我很兴奋了，但是更让我激动的是从需求设计到代码实现，到单元测试，再到最后联调上线，都得由我一个人完成。那个瞬间，我感觉自己被点燃了，这可是我进公司第一个独立负责的项目呀！

我斗志满满地开始了，查资料是第一步，翻看了与此相关的信息，分析周边友商的情况，罗列友商中的优秀特性，再研究导师前期提供的资料，一番功夫下来，心里已有七七八八了。

短地址服务的背后不仅是缩短网址这么简单，还需要融入市面上的一些优秀特性并且做到更好，另外在后端其实还会统计和挖掘一些有价值的内容，相当于建立一个内容承载的渠道。例如，我们可以根据某一地区分享出去的链接去分析哪类视频或者音乐是这个地区的用户更感兴趣的，从而去进行同类视频或者音乐的推荐。逻辑并不复杂，于是我开始设计、编码、自测，学习平台的各个中间件，分析哪些中间件可以采用以提升服务性能……

一切都按计划进行着，经过完整的服务发布流程后，我心中充满了自信，没想到上线前运维同事给我提了问题单。运维同事提出设计存在不合理的地方，我心里一开始还在想运维同事是不是在挑刺呀？但还是把问题单仔细看了又看，发现果然还是我设计上存在了问题。因为我在设计的时候，短地址没有配置唯一ID，如果服务器启动后，可能会存在较低概率和别的地址冲突的情况。虽然在后续运维过程中可以增加配置项来设置，但这提高了运维成本和冲突风险。

虽然是个低概率问题，但只要有发生的可能，我还是得解决掉，我开始查找相关的算法和规范，发现snowflake分布式算法根据机器码生成唯一ID能很好的解决这个问题，在不引入新的外部组件下，实现服务启动时机器码自注册，并且保证不会冲突和异常。

我事后也进行了总结，虽然做过好几轮自测了，但是没有从产品上线运维的角度考虑方案是否合理，这给我之后的开发上了最好的一课。这里要感谢运维部的专家陈百平，他温和谦逊而且很有耐心，一开始我跟陈工接触，我以为他也是位新人，所以各种问题都拉着他讨论。后来偶然得知陈工是运维领域专家，我大吃一惊，原来专家和新人之间并没有那么多鸿沟，这给初来乍到的我留下了深刻的印象，这也一直激励着我有朝一日如果能成为专家，也要像他一样。另外，这件事也让我以此为戒，一个产品的开发，必须要端到端地考虑方案，从用户、运维等角度多思考，保证最终产品可用且稳定。

短地址服务用了三个月成功上线，是我在华为的第一个小胜仗。现在回想起来，内心仍然充满着兴奋和感动，也充满了成就感。

150天

从食堂吃出来的灵感

第150天，我也开始新的征途——CDN （content delivery network，即内容分发网络）调度服务。简单来说，这个服务就是根据用户所在地，调度用户链接到某家最优CDN厂商去下载或播放资源，从而提升下载速度，降低时延等。一般业务都会引入多家CDN，各家CDN加速节点在不同省份、城市都有分布，CDN智能调度采集用户上报的质量数据，做质量模型评估，针对业务和用户关注的核心指标进行合理调度，就能很直观地改善用户体验。另一方面，为了保证可靠性，智能调度支持CDN故障后在十分钟内自动切换，减少业务受损时长以及运维处理时间。

就拿智能调度这个来说吧。原本的静态调度是指分配用户使用各CDN节点的比例是固定的，这种做法并不能给用户最好的体验。而CDN技术的第一版智能调度方案中的质量评估模型也不太实用，比较简单。我心里就在琢磨，一定要有个真实提升客户体验的智能调度方案出来。

有一天吃午饭的时候，我走到食堂的一个比较火爆档口，发现这家排队的人特别多，于是我选择了旁边一家人稍微少一点的店。我突然醒悟，其实每次遇到这家人多的情况，我都会固定去另外一家，这让我当即灵光一闪，就想到CDN智能调度，为何不通过历史数据的分析来优化后续的调度呢？

于是我们就根据用户历史使用情况和端测上报数据，在设定调度原则和商务限定下，通过一段时间的调整生成这个地区的最优CDN配比。目前我正在构建一个整体上更智能的调度算法，能够将调度区间更细分地评估和优化。

同样的方法还用在了CDN故障切换上。比如用户在链接多个CDN节点的时候，突然有个CDN节点出故障了。按照之前的做法就是运维人员登陆环境去排查问题，然后通知CDN运维去处理问题等其自动恢复。如果在限定时间内CDN无法自动恢复，那就需要人工去切换CDN厂商，这样一个过程下来很耗时耗力。现在我们可以根据历史数据去评估这个CDN节点的成功率稳定曲线，然后再拿今天的成功率曲线去做对比，再经过CDN故障诊断和横向对比，确认是CDN的故障就立即进行切换并且通知业务运维去查看和确认。这样一来，就可以很快切换到可靠稳定的节点上去，也给运维人员提供了良好的排查和定位空间。

经过几个版本的完善，当前CDN调度服务接口成功率提升至99.99%，平均时延降低至0.3ms。智能调度的故障自动调度和质量调优调度都已经上线，经过现网灰度和测试，效果明显。后续还需要对质量评估模型进行优化。

365天

没有捷径，未来无限可能

回顾自己接手的两个项目，我认为写出有质量的代码是每个程序员的责任，你的代码代表了你的可信。因此每次转测之前，我都会结合各个场景进行充分的自测，用尽量完备的测试用例把自己说服，再转给专业的测试人员测试。所以这两个项目多个版本的问题单加在一起也只有个位数。每当版本结束的时候，做得不好和需要优化的地方，导师也会帮我梳理，将自己较好的工作方式和思路传授给我。我也会总结自己犯过的错误和问题单以免再犯。

在平时的闲暇时光，每天除了打篮球锻炼身体，我最常做的还是在下班后看书。碎片化学习有必要，但是有体系地看书更重要，这样才能在脑袋里构建系统，理清晰背后的逻辑。

2019年7月2日，是我加入华为的第365天，回看这365天，我从一个空有激情不知从何施展的冒进少年，成长为一个扛得起项目写得了胶片的微胖青年，有过焦虑和彷徨，但更多的是成长的喜悦。

还记得生日时导师送过一句话“不管你走了多远，一定不要忘记为什么出发”，这句话一直伴随着我，敦促我不断自省不断进步。在云服务这片肥厚的沃土上，我恣意地生长，相信未来一定有无限可能！

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