我的2019

以前想做一个很酷的极客,等真正放弃了以后才终于实现

其实写下这篇博客总结的时候已经是2020年1月8号了,为什么没有在 2019年结束前去做这么一个复盘并没有什么特殊的原因,纯粹是几个月没写博客了养成了惯性。其实就是懒(mo)了。

2019年对我来说依旧是变化最大的一年,我觉得简直比2018年给我带来的变化还要大。这一年我换了新的工作,也换了一个新的行业,失恋了,也又有了新的恋情。真的是应了一句老话,唯一不变的就是变化。

工作

上半年的时候,一直在前东家 Coohom 工作。那时候的工作内容里,作为一个后端程序员,除了完成每个敏捷流程里所承接的业务需求以外,我还独立承担了整个业务的基础架构在 Kubernetes / Istio 服务网格的应用与改造。 我自从2018年年中开始接触 Kubernetes 与 Istio 以后,从2018年10月份开始尝试使用服务网格以及实现使用服务网格服务来服务真正生产环境业务的落地实践。运气不错的是,终于经过当时两个月的努力终于在 2019年年初的时候正式将 服务网格投入到当时所在业务线的所有服务中,并在灰度发布与监控这两个场景下发挥了非常巨大的作用。 针对当时灰度发布,我写了一个非常初级也非常简单的方案发表到了国内的 ServiceMesher 社区。也是借着这个机会认识到了很多使用服务网格的同好和工程师。 这其中还有我以前的大学同学 He Cao , 有时候回想起当初一起在大学的计算机实验课一起边聊天边做实验,毕业以后又一起在云原生领域相遇真的是很有缘分。

云端设计平台Coohom在生产环境中使用istio的经验与实践

在后续的 Istio 使用中,我将原有的灰度发布服务迭代了好几个版本,将这个功能完善的越来越人性化以后,使得我们整个业务团队的迭代能力与发布次数上升了好几个档次,并且使用体验也非常棒,我就着手去接触监控与一些额外的服务网格使用场景了。后续在服务网格也做了一些额外的产出与场景,但是当时觉得这些工作并没有之前所做的工作一样比较具有宣传、分享的价值,所以有些就是做了就是做了,另一部分就对外写了一篇分享以后也不再继续深挖了。 值得一题的是,在这工作过程当中接触到了服务治理中的监控领域,当时硬着头皮学 Prometheus,觉得 PromQL 怎么这么眼花缭乱、花里胡哨的,但是经过当初那段工作实践后,总算是达到了稍微入门的水准。

Istio Mixer 的一篇水文实践

上半年在 Coohom 接触的最棘手的一个问题,在我个人看来莫过于数据同步了。 由于 Coohom 是一个服务全球的业务,为了保证各个大洲的用户都有良好的使用体验,我们在每个有着目标用户的大洲里部署了一整套服务。最初我们所有的服务都使用一个主要的数据中心,其他大洲的服务在访问数据库时都会变成跨大洲的调用。这反而在使用体验上不如让用户直接跨大洲访问来的更好。为了解决这个问题,数据同步就是我们迫切需要解决的问题。后来经过我的调研后, otter 这款产品是最直接契合我们需求的,但是由于我们的所有部署环境都是基于 Kubernetes 的,所以当时花了不少时间将整套 otter 架构生搬硬套到 Kubernetes 之上,然后写了一个简单的管理脚本来帮助管理。其实当时一直希望做一个 Otter Operator 来彻底将他在 K8S 平台上产品化,但是读了 otter 源码以后发现 otter 本身没有暴露一个良好的控制层API,改造起来工作量太大,遂放弃。

在 Coohom 最后的一个月时光里,除了写交接文档以及帮助对接一些工作外,我主导尝试设计并实施了当初组内 Serverless 的最初版架构, 纵观当时的整个云原生 Serverless 产品里,唯一能打的也就只有 Knative 了。虽然当时已经是最后的一个月了,但是为了能将初版的 Serverless 架构跑通去服务真正的业务,我也是为此一点没闲着,加了不少的班。当然最后也终于在离职前将整个初版架构的工作彻底做完了,同时也写了一篇对外分享的文章,算是对老东家尽了最后一份力。

使用Knative作为API聚合层的实践

6月末的时候参加了 Kubecon Shanghai, 也在现场见到了 He Cao 和曾经的同事 aylei , 同时也在现场和当时的 ServiceMesher 的社区成员一起合了一个影。参与 Kubecon 不仅和很多朋友与同事见面,也让我有机会见到了整个云原生业界里面大家的一些最前沿的工作内容。也正是这次参会,让我有了从一个云原生产品的使用者转向成为云原生产品的开发者的想法,我觉得这可能也是我后面打算换工作的一个契机。

Kubecon Shanghai 2019回顾

9月初以后正式入职了 Pingcap,作为 Cloud team 的一员,开始参与到 Tidb-Operator 的开发。入职Pingcap 的刚开始一个月还是比较耗费心力的,虽然那时候早就看过很多分布式数据库 Tidb 的介绍和分享了,但是真正加入了以后还是需要面对很多学习资料。那段时间

我一边给 Tidb-Operator 做一些边边角角的开发,一边学习整个 Tidb 架构和工具。在这过程中非常感谢 付老师磊哥 的帮助。来 Pingcap 之前一直是一个 Golang 的小白,在 Pingcap 工(bei)作(nue) 了几个月以后,写出来的代码终于像样一点点了。

从9月到现在,在 Pingcap 的这三个多月,做的最大的一个工作就是独立承担了 Tidb-Operator 在 成员管理的重构工作 。在我加入 Cloud team 时, Tidb-Operator 其实已经发布了 1.0.0 的 GA 版本,但是整个成员管理的功能已经比较复杂了,并且也很难成为一个通用能力,扩展到更多的场景。于是组里的大佬们经过讨论就决定使用 Kubernetes Admission Webhook 的功能,通过边缘触发的方式,将成员管理下沉下去。其实这个改造一开始只是作为一个 提案issue ,记录在 Tidb-Operator 仓库内的。然而在我出差去北京总部的高铁上看到这个 Issue 时,由于对这个 Issue 的认识出现了明显的低估。从而导致本来我预估只需要一个月不到就能完成的功能,最终花费了将近 3个月的实践才完成交付,目前已经发布到了 Tidb-Operator 1.1.0-beta 的 pre-release 中。虽然由于对于自我认识的不足让我不小心接了个大活,但是在这过程中我也是逐步的开始熟悉 Operator 的开发模式以及 Tidb/Tikv/pd 的各种特性。

另外一个比较深的感受是,作为一个基础设施级别的产品,测试是十分重要的。在 Pingcap Cloud team 中第一次接触了比较大型的自动化 e2e 测试。 由于 Operator 作为基于 kubenetes 平台,除了本身功能性的 e2e 验证外,对于所在 Kubernetes 平台的版本兼容也是我们所需要考虑的。这就意味着一个优秀的,科学的,体验良好的 e2e 架构设计对于整个 Tidb-Operator 项目来说同样是极其重要的。由于我实在是太弱了,所以整个 e2e 测试的架构是有付老师主导设计开发的,而我则是作为吃瓜群众负责喊666。但最终整个 Tidb-Operator 的 e2e 架构真的是牛逼,真香。有机会这块未来或单独介绍一下,作为帮助社区参与到 Tidb-Operator的开发资料。

课外活动

这一年来看的书比之前几年少了很多。《Kubernetes In Action》在引入国内以后,快速的通读了一遍。给我带来最大的感受是,每当我觉得我理解了 Kubernetes 的设计模式了,隔段时间再去看 Kubernetes 整体设计又会再次刷新认知。也读了 崔老师 的《深入浅出Istio》,感触颇多,有感而发写了一篇读后感。有幸被 原作者以及ServiceMesher转载。年中的时候读了《深入浅出Prometheus》,这本书写的挺好,如果不是这本书我觉得我都快 Prometheus 从入门到放弃了。下半年的时候受到了人民邮电出版社编辑的邀请,参与了一本国外 Kubernetes 书籍引入的翻译审校工作。由于那个时候我刚刚入职 Pingcap,后续还去了北京出差了几个礼拜,所以整个审校工作断断续续的,但也终于在 DDL 前交付了。

《深入浅出Istio》读后感

这一年来也一直保持了对外输出,对外分享的习惯与兴趣。9月份的时候,有幸收到华为云的邀请参与了 ServiceMesh的实践分享。2019年冬至的时候则去了喜马拉雅FM总部做了 Tidb-Operator 的产品分享。除开这些略带工作相关的,我真正最在意的还是回母校的开源社区社团去做分享。这一年来也保持着一学期一次回到母校社团去做各种各样的分享。在这里着重表扬与感谢一下现任的上海大学开源社区的每一个负责人,今年的开源社区活动办得特别棒,作为已经毕业的社区一员看到此情此景深受感动。

由于我自己在学生阶段也是收到过开源社区学长们的照顾,所以在我毕业以后,我也希望能将一些在业界新的见闻和新的眼界带到现在的社团学弟学妹们,也算是对社团的一种回报。

CNCF项目大赏

谈云服务行业的技术变迁与爱恨情仇

全球化业务背后的技术之路

未来Flag

虽然这一年看了很少的书,但是买了不少的书。杜军大佬的《云原生分布式存储基石-etcd 深入解析》与《Kubernetes网络权威》,但是一直放着太忙吃灰没怎么看。今年一定要把这两本书的优先级提到最高。另外一方面希望自己能将 client-go 的源码多深入看下,由于 Tidb-Operator 中大量使用到了 client-go,深入学习一下这个库对于提升整个 Operator 质量还是非常有帮助的。

其实 2019 年内,我也成功给 root 提交了代码贡献。但是由于后续一直在忙其他事情,所以就没时间后续继续跟进。作为云原生存储的一个编排产品,我个人还是比较看好 rook 的,希望今年能对 rook 有更加深入的了解。同时,我也希望自己能在这一年通过 Pingcap University 加深对 Tidb 数据库的了解。毕竟自己是在一家数据库公司工作,我感觉我现在对于数据库的了解还是非常弱鸡的,必须得在同事发现之前好好补上。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章