2022年的大礼包

·

1 min read

其实上周五就已经离开公司了,只是因为还有年假未休的缘故,离职日期上写的是昨天,所以理论上今天才是我2022年离职生活的第一天。第一次被裁,拿到了大礼包,得失之间,内心是非常复杂的。

尤记得上一份在微医工作,由于种种原因,"试用期"竟然没有通过,对我的打击不可谓不大,以致于一度产生了严重的自我怀疑,直到我来到了涂鸦,至今,我依然心存感激,所以,临走那天,我私信感谢了我的面试官,感谢了我的领导,以及我所在团队的一众队友,不得不说,有些许煽情,但全都发自于内心,很真诚,我都被自己反复斟酌的文字给感动到了。

回顾这一年半的涂鸦生涯,感觉时间过的似乎很慢,又似乎很快,的确有很多收获,但也有不少遗憾。还记得初到涂鸦时,团队的后端技术栈可谓是一穷二白。一切都很原始,很粗糙:

  • 发布流程:自己打包镜像,登录虚拟机容器化部署

  • 代码与配置:配置打入镜像中,以不同文件名区分

  • 后端框架:使用B站的kratos框架,当时还是v0.5.0,据说还魔改了

  • 重复代码:由于团队绝大部分人都是客户端开发出身,后端代码是各写各的,自己copy自己的代码

  • 代码风格:没有基本的代码格式化,一人一套风格

  • ……

问题当然是非常多的,当然,如果没有问题,也就没有招我进来的必要了。作为一个新人,我并没有要求谁谁谁应该怎么样,只是默默地写下了golang开发规范RFC,制定了以下规范

  • golangci-lint

  • pre-commit

  • 后端开发框架推荐Gin

  • ……

将发布流程接入了公司的内部的发布平台,配置与代码分离,对接了公司的apollo配置中心,编写了一个叫做goc的极简的后端脚手架工具,创建了golib仓库,放置一些常用公共代码……那段时间,几乎是报复性工作,我非常高产。

API网关

当时由于团队的整个平台非常地零散,每个后端服务都要申请一个办公网域名,单独对外提供服务,而且还是裸奔的,当时就觉着非常不可思议。于是乎,从没有玩过API网关的我,萌生了要为团队打造独立网关的想法,这个点子得到了TL的支持。从头开始造轮子是不可能的,我只有不到1周的时间调研。在极短的时间里,以上手快为基本原则,我选用了lura这个golang开发的API网关,很快适配了公司的技术平台,并且上线发布。期间,因为团队对权限控制有需求,而公司内部的ACL平台当时又无法满足需求,于是在TL的推荐下,引入了casbin作为团队的自有权限控制体系。于是,lura网关+casbin权限就这么成为了我们的 mPaaS 平台的基础设施。地基打好了,后面做许多事情就方便了。

开倒车?

作为一个支撑客户端应用的DevOps团队,我们有许多时间需要跟jenkins打交道,由于一些历史原因,我对jenkins实在是没什么好感。jenkins的流水线也不那么好写,彼时,团队的做法是自己定义一些默认的模板,打包在后端项目中,暴露一些常用的选项给业务方用,灵活性很差,而且难以维护。中间经过了很多次讨论和一些尝试,TL决定将github action的那一套语法照搬到jenkins里面来,使用jenkins的sharelib做语法解析。当时还是比较惊讶的,因为当时调研的时候,有看到jenkins往github action迁移的,但是反向操作的,印象中是没有看到过的,这算不算是开倒车? 当然,现在从结果看还不错,虽然教育用户差不多也用了半年时间。保持耐心,持续投入,终会有收获的,不是吗?

监控体系

mPaaS平台的数据监控用的是influxdb方案,jenkins安装influxdb插件,团队自己申请的虚拟机安装influxdb和grafana,维护当然也是自己搞定,久而久之,维护也成了一项繁重的工作,重要的是这不是我们的核心工作,但却要投入不少精力。虽然公司有自己的一套监控体系,但是数据采集格式是自己定义,也自己的sdk,既不兼容influxdb也不兼容prometheus,这就很尴尬了。所谓念念不忘,必有回想,还真被我想到了。既然公司有这么多限制,何不加一个中间层:

  1. influxdb_exporter: 负责承接jenkins的influxdb数据并转为prometheus的一个exporter

  2. prometheus: 打听到基础团队有一个自己维护的prometheus,团队联系接入

  3. 数据转换:promethues配置remote write到我写一个服务(将prometheus数据转成公司的格式) 当然,公司今天支持prometheus exporter,我可以无缝接入这就是后话。

dubbogo

公司以java技术栈为主,大部分基础设施对java开发者是最友好的,不少内部服务也只提供dubbo接口,而mPaaS的技术栈是以golang为主的,这就导致团队想借力公司的基础设施会比较困难,要么,就用java写一个服务去接dubbo接口,然后转成http接口供mPaaS内部使用;要么就用dubbogo去接公司的dubbo接口。经过一番权衡,还是尝试用dubbogo去对接公司的dubbo服务,过程有一些坎坷,但总算是摸清了门路,扫清了技术障碍。可以说,经过这一步,团队建立起了更大的信心,可以借力公司的基础能力,把更多精力专注到核心内容上来了。

节点资源池

因为一些历史原因,mPaaS团队维护着多个jenkins实例,且这些jenkins的agent节点彼此之间是独立的,时常会出现不够用的情况,公司层面也不愿意拨款加机器,但问题还是要解决的。关于这点,我想过很多,如使用k8s、kubevirt、OSX的虚拟化等等,但是由于iOS打包特殊性的缘故,这些想法都被我一一否定了,直到这事被正式提上日程,交给另外一个同事做,然后参与了一次评审,当然那位同事的方案被否定了,我才忽然记起来还有nomad,多个jenkins分别对接同一个nomad集群,由nomad进行资源分配,不增加机器,又能实现构建资源共享,这不是一个完美的方案吗?于是,跟那位同事,通力合作,将这一方案落地了。现在想来,很奇妙,工作和生活能分开吗?很难,我有许多灵感都是在非工作阶段迸发出来的,这些想法在我的大脑中静静地散落着,等待着被发现的那一天。

推翻自己

切网关

改变别人很难,改变自己相对容易。lura网关固然不错,但却不支持websocket,而团队就有这样的需求,从lura社区来看,只有商业版支持websocket,我有两个选择:

  1. fork lura并增加其对websocket的支持;

  2. 换网关;

从我个人角度讲,方案1可以自己造轮子,有钱有闲有时间当然是可以的,我本身也非常有兴趣,但恰恰这些都没有;于是需要考虑方案2了,于是调研了caddy与traefik,结果是traefik的yaml配置打败了caddyfile。不过,traefik确实不错,挺好用,社区也比较活跃。

微服务合并

高峰时期,我负责的微服务多达十几个,绝大部分负载都很低,这一度让我怀疑微服务的必要性,在了解到monorepo、bazel的理念之后,我在离职前将一些微服务做了合并。现在看来,真的是天意,也算是做了一件好事,降本增效嘛。有道是:天下大势,合并必分,分久必合。

专注

我时常在想,五年前我有最佳的身体状态,当时还经常跑步,偶尔跑个半马,但是头脑就不怎么好;现在有了更丰富的头脑,身体却不如从前。果然鱼与熊掌不可兼得。回到主题专注,因为孩子的缘故,我每天都早起,早点到公司,早早地梳理一天的工作,不参与不必要的闲聊,用Hanz的音乐屏蔽掉外部的纷扰,这些简单的策略,可以让我能够保持4-5个小时的有效投入工作时间,额外的负担是每天食量变大,很容易肚子就饿了,可能因为有效的脑力活动消耗能量也比较多吧。学会更加专注,做事效率也更好,正向反馈也更多,于是就正向循环了,我能拿3.75,专注力的提高功不可没。

技术分享

技术分享是KPI的一部分,但是当时大家都不知道怎么做,整体的分享氛围还是不够的,但我认为这件事情很意义,所以自靠奋勇打起了头阵

  • 访问控制 & API网关:主要讲了网关选型和casbin

  • 中间魔法层:我是如何以最小代价将jenkins接入公司监控体系的

  • mPaaS后端技术规范RFC:一些开发的规范以及工具

  • mPaaS那些事:与竞品对比,当时团队的一些数据统计,如访问量、人员分配等

  • XX优化之路:接收一个离别同事项目的优化的一些思路

  • mPaaS技术狂想:因为当时团队没有专职前端,所以就探讨技术栈all in node的可能性

年纪大了,有好多有趣的事情都记不住了,但是mPaaS团队的共同的经历,真的让我收获很多,遗憾的事情是没有将mPaaS做大做强,时也,势也,毕竟整个大环境也不好。大礼包还是香的,只是这香味中,也带着丝丝苦涩的味道,希望离开的战友们都能找到合适的工作,能发挥所长,创造美好。