2021杂记

庚子小结

2020悄然逝去，年逾而立却历经工作中最为激情的一年。工作虽算不上资历很深，也有几年经验，唯独这一年觉得非比寻常。
2019转入当前公司总觉得有点消沉，因为工作内容没法让自己成长，一路走来的经历让自己深刻知道逆水行舟不进则退。“人要胸怀去接受那些不可改变的事–这叫仁，要有勇气去改变那些可以改变的事–这叫勇，最重要要有能力区分二者–这叫智”，最早是在某个地方看到朱清时说的这句话，这么多年总是埋在心里。好在2019年底转入了一个新的团队，迎接我的就是2020一年超出寻常艰苦奋斗。
这一年，遇到了一位偶像级的Manager[大哥]。经历了不少团队，还没遇到一个直系Manager能给我如此多的启发和施展。一直自认为工作充满激情，与大哥相比，还是自愧不如。深厚的技术功底，饱满的工作激情，前瞻的方案设计 ，坚韧不拔的工作品格，当自己疲惫时候，看看这些，觉得自己连疲惫的资格都没有。大哥赋予了我信任，一直以来自己都是这样，如果一个人对我信任，那么这份信任我会拼尽全力赴以实现。就像是士兵突击里面史班长对高连长说的话：你有在心里承诺去完成的事么，不论是对别人的，还是对自己的？
接手项目时候，大哥给予了满满期待，但是自己对与微服务观测监控，压根没有了解过，对于监控领域几乎空白，虽说早点有过主机监控建设，但是想要去独挡一面设计一个大型监控平台，还是心里犯怵，因为我没发估量自己究竟能否完成这项使命。Domain理解几乎为0，自身技术栈不匹配，已有平台欠债巨多，中途有一定Domain理解的同伴职业规划改变离职…这相当于开局4打5。
没有Domain知识，不了解微服务化、监控、指标， 时序库，那就问，就学。
不会Go那就先照猫画虎写功能，逐渐就把编码效率练上去了。
同伴离职，任务积压那就尽一切可能压缩事情，提升效率，延长时间，这中间有天晚上下班到家洗个澡直接就在卫生间吐了。不推荐这种工作方式，但是在当时那种环境下，没有出路，我心里那个承诺也不允许自己退缩。
团队缺人，17天Boss聊天900人，捞100多份简历。
带了个应届，底子有点薄，没法干活，愣是给带出来能有产出。
年底产品官宣，奔走筹备，本科离开校园就没有再登台，但是当年那个在台上汇报回回第一的气质，时隔多年，瞬间找回。
中间还有其他事情，大哥说吵架也是一种能力…
回看这一切，我仿佛又回到当年高考前那个青涩少年，站在校门口望着那个小牌子，上面留驻着爱默认的那句：一心向着自己目标前进的人，整个世界都会给他让路。
或许有人会说，不就一份工作，至于么？是的，工作就是养家糊口，但是我自己一直都希望在这个直白的倾诉上能够再添加点理想，或许对于而立出头的人来说就是最奢侈的。等切实做到了，其实也没有那么艰难。
老祖宗说，吃亏是福。曾经有人会说，那么多事情为啥都是你去办？可是当一切都经历捶打后，现如今突然发现，技能多样是如此难得。有些在我看压根不是事的技能，在很多其他同仁身上，就成了非常明显的短板。
当然自己的短板也非常明显，希望明年能够继续成长。
这一切也离不开夫人背后默默支持和理解，家庭永远是前进中最暖的港湾。

微服务观观测

如今一般互联网软件公司都不会仅一款应用产品，对应软件实现也早就从单一服务转为涉及纷繁多服务，各个服务趋向于单一职能化，产品系统前台所有功能则是有成百上千个服务支撑。转而大型系统后庞杂的微服务，会面临严峻治理问题，其中最为重要的一个环节则是服务日常稳定性，出现异常时监控排障则是其中最为重要一个Domain，本篇就个人从事相关方面皮毛了解，做一些提纲挈领的梳理。

指标

既然是观测，那首先得具有指标Metric，用来能够衡量一个系统某个维度表征。最为常见Linux下的top命令，其中的cpu利用率等就是一个观测指标，对应的数值就是观测值。
在微服务监控中监控数值通常需要数据库存储，对于指标数据不同于我们常见的关系型数据或NoSQL数据。

• 首先这部分数据多数是持续不断会录入，海量数据，通常都是TB或PB级别
• 数据录入有没有修改诉求
• 数据具有时序特性
• 通常对数据需要按不同维度进行聚合统计，这点对于没有接触过监控数据的人来说特别不好理解，因为一个时序列中的数据，会被不同的tagKV标记，可以指定tag为某个维度进行汇聚序列值，得出更精确的指标统计
  Google使用的时序数据库是Borgmon，对于开源为当下比较为人熟知的Prometheus就是受到Borgmon的启发。

日志

开发最熟悉不过的排查问题手段，常见的ELK为多数中小系统青睐，某些云厂商也提供了日志产品，能够轻松接入日志系统。

Trace

微服务监控中核心组件，直译就是追踪，面对微服务化的应用支撑，一个前台请求进入系统系，在众多服务间完成调用，这个过程出现异常如何追踪定位呢？大型微服务化的分布式系统中，想要完成调用细节观测， 必然需要依赖Trace。如果有看官想了解Trace详情，可以移步Opentracing的官网。
其核心就是在一个请求进入系统后，给该请求打一个标记，然后带这个标记一路完成往后的各个相关服务的调用，每个服务可能会需要一个耗费一个跨度(Span) ，这个Span中可能还调用了其他服务，最终是由一个 Span组成的调用树表示一个完整的调用，这个调用都归属在该Trace内。业内实践中：

• Google: Dapper. 2010年以前分布式Trace基本处于探索阶段，而后Dapper论文 主要 作者Benjamin H. Sigelman 基本奠定了分布式Trace的形态，也被奉为分布式Trace的圣经
• Twitter: Zipkin 前生叫 BigBrotherBird
• Uber: Jeager [雅戈尔] 源于德语，意为猎手

指标，日志，Trace三者的关系如下图(从Google图库中下载的)：

Metric: 核心特点是可以进行数据聚合或累加，并且具有原子性的数据或数值分布，而且指标的值理论上来说都有一个逻辑的含义和单位
Log: 核心特点是日志描述离散时间，内容是文本居多，有类似事件的属性
Trace: 核心特点是聚焦在单次请求范围内，所有数据都被绑定到业务的系统中的单个事务上
三者事件的联系如上图，存储消耗上，相对而言日志最重。
Google 的 OpenCensus 这是可以提供监控和Tracing同时使用的客户端组件，但是下一代的产品则是OpenTelemetry，集监控，Tracing，日志为一身的客户端组件。OpenTracing的官网都提示：OpenTracing and OpenCensus have merged to form OpenTelemetry!。

云原生 Cloud Native

近几年可谓火热异常，那么这个就是是什么呢？
来自官网的一段介绍：
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
参考：https://www.cncf.io/
CNCF 第一个项目是 Kubernetes，第二个是 Prometheus，第三个就是OpenTracing。

漫漫成长路，2021继续努力～