2022年的大礼包
其实上周五就已经离开公司了，只是因为还有年假未休的缘故，离职日期上写的是昨天，所以理论上今天才是我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，这就很尴尬了。所谓念念不忘，必有回想，还真被我想到了。既然公司有这么多限制，何不加一个中间层：
influxdb_exporter： 负责承接jenkins的influxdb数据并转为prometheus的一个exporter
prometheus: 打听到基础团队有一个自己维护的prometheus，团队联系接入
数据转换：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，我有两个选择：
fork lura并增加其对websocket的支持；
换网关；
从我个人角度讲，方案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做大做强，时也，势也，毕竟整个大环境也不好。大礼包还是香的，只是这香味中，也带着丝丝苦涩的味道，希望离开的战友们都能找到合适的工作，能发挥所长，创造美好。