小码农的碎碎念之2016个人技术总结

重金难酬大梦想，寸功不负小码农

题图来自我在四月份借元代吴澄的《勉学吟》组诗中一句，再凑一句，做的一首小(shun)拙(kou)诗(liu)。当时的我正处在一个挺纠结的状态中，聊以此来给自己打气。

转眼又过了大半年，2016年的阳历阴历都已落幕，在新年伊始再回头看看这过去一年，真是特别有感触。因为这一年过得可谓跌宕起伏精彩纷呈，所有努力的、新鲜的、憧憬的、不确定的、甚至是后悔的经历，到最后都归为充实的成长。在这篇文章里我先数一数自己这一年在技术上的些许收获。

年初

PySpark

在2016年开年之时，我在数据组做游戏数据的捞取、计算和存储等工程相关的东西，也做了一两个报表网站的API。其中一个网站的API算是2015年末写的吧，用了一些在当时部门里比较没人试过的东西，比如用OpenResty来异步化DB连接、动态加载DB Model、和SA合作尝试Docker部署之类的（万分感谢SA大大提供的Docker Swarm集群），现在看来挺有过度设计的嫌疑，一些配置也没有达到最佳实践，但是至少那个站在挺少的资源配给下，做到了还算不错的性能。

后来一个同事把这个网站前后端一口气都接走了。老板们安排让我把工作重心完全转到用PySpark来做我们电商平台的数据工程。就是在这段时间，我开始接触Spark上的RDD和Dataframe API。由于Spark的MapReduce编程范式要求，代码里函数化的程度比之前的项目都高不少，尤其用了非常非常多的闭包来传递上下文，也算是比较少有的函数式编程练习机会了。

年中

Pandas

要说用Spark有什么遗憾的话，最大的应该是当时还没来得及用上Luigi或者Airflow之类比较现代的pipeline管理工具，只是初步调研了一圈；另一个是当时一直做着工程上的东西，没有机会接触分析和建模层面，就没有怎么接触到Spark的MLlib API。不过这个也不算太可惜，因为我后来被抓到了一个新部门，重点帮公司的大游戏做营收优化。于是我在Spark集群内网里要到了一台机子，搭了个Jupyter，在上面跑Pandas和Scikit-learn。在这个部门，我需要开始短平快地用脚本从游戏数据生成报表，然后提供给运营组的同事做精确营销之类的准定——需求服务面的专一性和时效性就决定了用Spark取出来的数据量小到一定程度时，就可以尽量用一些抽象程度高的API和类库来节省时间，不需要考虑计算过程的可扩展性。

其实做报表吧，也不全是我工作所有内容，平时还是有一些数据准备工作是比较工程化的。在一些项目里，我们需要直接用Hadoop的接口操作HDFS，于是就用上了Scala——这也算是今年比较独特的技术经验了。关于对Scala的爱恨情仇，在另一篇博客里有比较详细的描述，这里就不展开了。

年末

不忘初心

年末是全年最开心的阶段，开心到我都不知道要配什么图好了……

我被最初招我进公司的老板调回一开始的部门，专心做游戏活动宣传网站及API。在此之前我虽然有很长时间在这个部门里，但主要做的网站比较报表向，以内部使用为主，项目比较注重数据计算流程；现在在这个组里做面向外部玩家和用户的网站，就更加注重网站外观注重服务性能。

我们组里气氛特别自由开放，项目更新周期也短一些，很多想推进的改动都可以去尝试，效果好的话，在新项目里推广开也是很快的事情。我们已经顺利地把很多活动宣传网站放到Docker上了，运维就可以交给SA，不再需要自己去服务器里重启，有性能需求的时候也可以随时横向扩容；本地开发环境的架设用docker-compose以后方便了很多，不再需要用一个专门的开发虚拟机来为项目各种安装依赖包各种改自己本地测试DB连接参数。新的项目到手时候还有一套挺顺手的Cookiecutter模板来生成比较简洁的基本项目结构。这些流程上的改变，希望都能让组里筒子们在开发体验上有所提高吧。

这里插一段题(zhao)外(pin)话(tie)：我能知道Cookiecutter这个工具还要感谢我们厂赞助了坡县PyCon 2016，让我能直接围观Python社区里的新鲜玩意。会上有两个Keynote Speakers（Greenfeld夫妇）就是Cookiecutter的作者。如果没有这次PyCon SG的参会经验，我们可能还得自己造轮子来准备模板项目。喜欢在开发社区交流学习的朋友想来我们厂的话，欢迎简信上找我哟。

再回到技术总结，在性能上我们的改进也不少。我们之前在一些WSGI的异步部署配置上没有做到很好的实践。在跟其他部门的前辈们学习之后，我把他们的一些经验借鉴到我们组的项目中，性能提升挺明显的。在此也要感谢一下我们厂能从国内一线大厂挖来这么多大牛，让我这在坡县成长的小码农也能偷师一发。

还有一个我们性能相关的调整在于对Nginx的调研。我们在推广了前后端分离的网站架构之后，对API的性能就可以有更好的细粒度控制——有一些报文很长而更新时效不敏感的API，就可以提到Nginx的缓存里。这样的调整对单API的吞吐量提升非常明显，明显到这些API对服务器的压力简直都可以忽略不计。

其实我们的调研不止于Nginx的核心功能，还用上了OpenResty——在我用OpenResty写完一个性能要求比较高的API做尝试之后，陆续又有两个同事用上了OpenResty。目前服务跑得挺稳定的，用了OpenResty的同事反馈也不错。之后我们可能还会继续用OpenResty给我们的内部API做统一网关什么的，都已经写进2017的愿望列表里啦。

最后提一下我在2016农历年末的一个尝试，两年以来一直很想通过Vue来学习前端姿势的我，终于下决心用Vue来写一个比较复杂的游戏活动站。一开始还只用了vue-cli默认的Webpack项目模板，到现在已经用上Vue + vuex + vue-router的全家桶了。不过由于手生，开发过程中有一些小的磕磕碰碰，但是现在还不至于影响业务设计——希望自己的前端能力可以赶快成长起来 :)

---

不知不觉已经嘚吧嘚吧写了这么一大串乱七八糟的流水账，who cares 反正也没什么人会看。

2017，继续加油吧！