前言
2021已经过去了，在这里回忆一下，我的2021的年终总结。
困难与挑战
工作中，在过去的一年里，迎接了不少的挑战，在公司中落地大数据相关的服务了从erlang到golang的转换。我们整套新的体系称为：mfeilog
在公司中，积累了许多go语言的组件，并且不断的完善修复相关的bug，例如，mfeilog的核心数据源：
msource，mfeilog的基础组件：daemon组件/no-named-pipe组件，logbdev组件，sink_mysql/sink_kafka等组件。说到这个
msource服务，这是一个基于rocksdb实现的支持sql语法的轻量级小型定制数据库服务，可以说是经过了不断优化，升级，修复内部各种内置功能，才得以现在的稳定和高效。给应用层提供了一个高可靠，稳定，的数据源功能。其中有一个bug，印象特别深刻，也是我始料未及的一个bug，因为发号器是附属在Table当中的，我需要自定义序列化后存储在底层的rocksdb中，所以在我反序列化出来的时候，启动了多个发号器，导致每个field-colunm都实例化了一个新的对象，而非同一个对象，引发了发号器错乱，从而导致数据丢失的问题(内存被覆盖，错误ack掉了数据)。这个问题排查也是十分不易！！！所以可以说是血的教训。并且也为公司推广 “服务器日志查询方案” 中，确定了以
GPL（grafna+protomal+loki）的日志查询架构，统一了日志查询的入口，大大提高了日志查询的效率。在
go服务流量录制和回放方案和实现中，为了实现流量闭环，特意去调研查看了 滴滴的《写轮眼》项目，并且知道了通过类似注入的方式，可以在用户层编解码上替换到原来的函数指针，从而实现在用户层替换go底层源码的方式，但是由于性价比问题，在公司中最后并未推广，也没有进行研发。该需求后面被搁置了。在
配置服务方案中，这个需求在以往其实已经试过才用consule来做配置服务中心，原因是早期我们想要对服务做一个服务注册和发现，在php这种fastcgi的方式来说，consule的主动发现服务，就比很多类似etcd被动发现注册服务好用。但是由于最终因为我们的服务目前来说比较零散，并且需求的任务不是着急，这件事后面也被搁置了，后面今天再次提了一个这样子的类似的需求，实现了通过 go语言写的的工具，类似于k8s的kubectl的工具，进行配置的同步和管理，分别分为了2个模式，一个是C端的工具，一个是S端的同步服务，中间的枢纽，最终选择了以etcd为配置分布式存储服务。我们服务的部署特点，利用jenkins的多阶段自定义编译的jenkins-shared-library实现了灵活编译，根据现有的服务灵活部署，从而达到非嵌入式的配置同步方式。因为公司成立得比较早，代码仓库一直从未进行变更，所以其中一个需求就是
gitbucket到gitlab的代码仓库迁移，写了一个小工具，从而实现了从 gitbucket到 gitlab一键自动化无缝迁移代码，包括项目组，项目的历史commit，tag，branch等等都自动化完成，大大减轻了项目迁移的负担。对
jenkins的shard-library模块进行优化升级，编写了一个python的支持多凭据认证的脚本，并且支持自定义编译代码。集成了一套，
本地的大数据docker环境，我们都知道大数据环境十分的繁杂，并且还需要多台机器才能处理，这对我们本地开发来说十分的不友好，但是网上又没有那些很好的开箱即用的docker-compose环境，因此整理了一套本地的大数据docker环境(非CDH版本)优化升级部分
mproxy的代码，从而让测试人员更友好的在该项目中完成自动化测试的脚本功能。推动
flink的落地，由于我们早期的流计算，是单机的，并且存在严重的外部依赖属性，所以，我们推动了flink的落地，探究了几种开发方式，分别是用纯java写的datastream-api方式，这个方式有一个好处就是，所有的上层的api都是基于datastream的，一些上层的api无法满足我们的需求，我们通过datastream可以很轻松的实现各类需求。在这个过程中，我踩了不少的坑，主要是来自于watermark和window的概念，咋一看其实都是一些比较好理解的概念，但是其实在配合大数据专用的kafka消息队列中间件，一切就变得复杂起来，由于kafka的partition只能有一个client去消费的原因，加上flink自身的概念并行度，这一切结合在一起，就会出现一些让你疑惑的点。经过了大量反复的摸索和钻研，最终才掌握了在多partition下flink的watermark和window-trigger机制方式，但是由于该方式不够直观，也不管灵活，所以我们最终推广了sql-api。好家伙，你以为这就完了吗，并没有，由于flink自身带有sql-client的原因，我一开始尝试了用sql-client来编写流计算的模型，但是发现这个工具有太多问题了，不同的版本有不用的调用方式，不同版本下，对于SET支持的粒度也是不一致的，这让我很头疼。所以最终选择了，基于flink编写了一个自研的flink-sql-client，通过flink run flink-sql-client.jar的方式，我们就可以轻松的提交sql任务或者做其他的需求（例如查看hive的cataglog等等）。然而到了这里还没有结束，由于sql的部分，我们没办法控制，是由flink-core自身标准化了流程，所以有一些bug我们没办法解决，例如在flink-1.12.0种，就会因为watermark在idle的情况下，无法推进watermark，从而导致窗口在少量数据情况下，根本不能及时的统计和计算（这和号称实时分析的流计算违背），所以我们只能想了一些版本做了一些迂回的操作。从而最终解决类似这种由于底层bug所带来的问题。
自己的学习上
对
golang的protobuf服务有一些的了解，并且学会了protobuf的插件开发。了解了protobuf的协议。对
rust上的生态更为清晰了，利用了其中的一些actor模型，async-io等分别实现了一些基础的工具。对
flutter也有了一定的了解，利用dart编写了一个可以用于自定义通信的库。s对
linux种的一些磁盘io，网络io，已经shell命令的灵活运用更加深刻。
未完待续！！
(悄咪咪的告诉大家，我买房了。嘿嘿)