一名微博架构师的2016年终总结

  

架构

  作者:蛋疼的axb

  眼看着又一年结束,想想今年过的还真是快,上个画面还是去年年末各种处理故障的场景,一眨眼一年就过去了。既然过了一年,还是得留下些思考和展望,否则就有些太无趣了。

  还是套用那个老的不能再老的梗吧,the good,the bad and the ugly。

  The Good

  今年职位从高级码农变成了看上去很忽悠人的”技术专家“,虽然按专家的头衔来说应该做一些更深入的研究工作,不过受限于身体状态一直不好,一认真的思考问题就会头昏脑涨,只好做了很多给团队打杂的工作,所以好的部分大多数不是我个人的贡献,而是团队的功劳。

  今年最主要的成果,应该是跟团队一起在很多事情上兑现了之前一直念叨的“应该”。

  应该从现在开始做重构,而不是“到时候”

  从去年接手团队之后就一直在跟历史代码做斗争,在做了很久看似出工不出活的“代码review”、“重构”、“增加测试”、“删代码”之后终于有了回报:我们的代码质量可以让我们在其中正常工作,不再需要为了一个看似简单的功能而大动干戈的在“屎一样的一大坨代码”里纠结半天了。

  我们试过很多办法提升代码质量,包括强制code review、专门抽出时间重构、周会上的代码评审等等。每一种都或多或少的有一些效果,但最有效果的做法是引入自动化的代码风格检查工具,可以发现大部分代码细节问题,并且很容易量化,对于“质量”这种没有实感的东西,量化是能够让你持续投入很重要的一个方面。

  而最终的收益不仅是开发效率的提升,更重要的是,一个不断进化的团队中的一员在看到烂代码时,感受到的是“如何解决这些问题”的挑战,而不是”这些代码再也不会好了“的无力感。

  应该通过提升开发效率完成工作,而不是靠加班

  有代码不断优化的基础,我们也很自然的把服务过渡到了微服务架构。微服务架构让我们能够更敏捷的工作,不再需要忍受单体架构带来的“一个巨大的黑盒”带来的不便,我们可以对性能做更细致的分析,对问题做更精确的定位,对技术选型也有更多自由。在此基础上建立起了持续部署系统终于把上线变成了一件日常工作,“等我5分钟,我review代码的时候发现个bug,上个线就去吃饭”。

  我跟很多人谈起这个“5分钟上线”的时候,他们都觉着我是个不负责任的人,并且一遍又一遍的问我:“上线上出问题怎么办?”

  问我这个问题的人一定是没有考虑过“复杂度”本身就是一个巨大的问题源,当代码足够简单、依赖足够清晰时,很多问题就自然的消失了。实际上,我们现在的上线次数从每周两次提高到了每天十几次之后,上线产生的问题已经几乎不存在了。

  应该通过报警发现问题,而不是用户投诉

  我去年用几天写了一个报警系统,团队又在此基础之上建立起了一套特别靠谱的报警服务,不再依靠“检查系统内部有没有问题”,而是站在用户的视角,依靠探测程序检查“用户在使用时是不是有问题”。

  站在用户维度报警的好处是,只要有报警,那么就一定有问题。于是我们终于从每天轰炸式的报警短信中脱出身来,不再需要“按报警频率估计服务有没有问题”这种无用的工作,也不需要面对boss“怎么用户都投诉了你们还不知道”的尴尬问题。只要有报警,那么就需要处理;反过来,只要没报警,那么绝大部分用户使用也不会有问题,我可以放心的玩《守望先锋》而不用担心boss会突然来电话。

  最终,有惊无险的,我们做到了服务全年无故障(虽然还有几天才过完今年,希望这不是一个flag……)。

  应该通过技术解决性能问题,而不是堆机器

  微博的访问量极大,做个方案动辄要支持百万并发、千亿数据,但奇葩的是公司又很穷总是买不起新服务器(-_-),性能优化就变成了极其重要的工作。

  我们今年做了不少应用的性能调优,把每个服务的性能指标都提升了几倍(还有几倍是留给明年的KPI的-_-)。性能调优是一件有挑战又有成就感的事情,而且比较有意思的地方是,无论程序员的水平是好是坏,总是有调优的空间。水平弱一些的同学可以调优业务代码和基本参数;好一些的优化架构和第三方组件;牛逼的可以深入jvm和内核原理。调优经验多了,总会有种“无论怎么优化也到不了头”的感觉。