曾经的我

/images/now/book-shelf-1.webp

记录下我的学习轨迹。(结果写着写着有点像是技术笔记跟日记的混合了 hhhh)

Twitter 上 @manjusaka.eth 等大佬喜欢写周报,不过我不太喜欢周报的形式。因为周报的标题本身没啥意义,而要看其中的内容却得一个个点进去看,这对我自己回顾过往的学习、工作、生活,体验非常不方便。 我比较喜欢类似「一镜到底」的阅读体验,所以我采用这种单页的方式来记录我的日常。(基于同样的理由,我将博客单页展示的文章数量上限调整成了 1000) 同时如果某一天的日报内容跟前一天并无区别,我会直接省略掉当天的记录。

  • 英语
    • The Unlikely Pilgrimage of Harold Fry - 23/100
    • 一点英语 270 天英语学习 - 24/270
  • Linux/Unix 系统编程手册(上册) - 进度 190/572
    • 完成第 12 章 /prod 文件系统与 uname 系统调用,明天做下习题。
  • 国庆回家度假
  • 英语
    • The Unlikely Pilgrimage of Harold Fry - 22/100
    • 一点英语 270 天英语学习
      • 回到家后,忘记了打卡。虽然早就知道连续打卡 270 天很难,不过还是很错愕,居然在第 23 天就断掉了。
  • 英语
    • The Unlikely Pilgrimage of Harold Fry - 19/100
    • 一点英语 270 天英语学习 - 20/270
  • Linux/Unix 系统编程手册(上册) - 进度 174/572
    • 略读了「进程凭证」、「时间」「系统限制与选项」三章,因为对其内容不太感兴趣,跳过了习题。
    • 第 12 章讲 /proc 我比较感兴趣,明天读
  • 英语
    • The Unlikely Pilgrimage of Harold Fry - 18/100
    • 一点英语 270 天英语学习 - 19/270
      • 试了下每天靠通视频语料背 80 个单词(包含复习每日复习),花了 100 分钟,难度略高。暂时改成 50 个明天试试看。
    • American Pronunciation Workshop 美语发音教程 - 一周目 2/16

另外在 twitter 上看到了 待业五年后的找工作经历 这篇文章,读完之后,敬佩之余也想到一个问题:「如此专注在某一个很小的领域,在世俗意义上到底能取得多大的成功?」

这位文章作者毕业五年一直没找工作,开源项目也仅仅专注于 Flask 开发跟写各种布道的文章、书籍。 从绝大部分公司普通公司的角度来讲,他的技术栈显然是不合格的,Java/Go 性能都秒杀 Python,Flask 你懂的再多也没用。 也因为这个原因,作者面了这么多公司,最终没几个拿到 offer.

但是作者确实取得了名望。 他的书写得不错,在技术圈里广受好评。 还组织过两场国内 PyCon 技术大会,技术圈内小有名气。 还运营了 hello-flask 社区,并且长期参与 flask 的开发维护,Github 跟 Twitter 上都有上万 followers.

而且现在,他也确实凭借自己的能力进了外企(即使有 90% 的职位都拒绝了他)。

感觉这位作者的经历,是我此前从未发现的一条出路,虽然这条出路很窄,他的成功也很难复制。

我目前从中学到两点:

  • 得把英语学好(我正在做这件事)
  • 专注一个子领域深耕,才是提升技术能力跟影响力的捷径!啥都想学的结果只会是不断上赶着追逐别人创造的知识,啥都不精。
  • 英语
    • The Unlikely Pilgrimage of Harold Fry - 16/100
    • 一点英语 270 天英语学习 - 17/270
    • American Pronunciation Workshop 美语发音教程 - 一周目 1/16
    • 多抓鱼上下单了《English Grammer In Use》跟《赖世雄经典英语语法》,语法几乎全忘光了,这次打算补一补语法
    • z-library 上下载了《Key words for fluency》前两本书,因为发现自己口语经常不太会表达自己的想法,打算靠这个补补看
  • 英语
    • The Unlikely Pilgrimage of Harold Fry - 14/100
    • 一点英语 270 天英语学习 - 15/270
  • APISIX 504 问题
    • 周会同步,同事提示我 node-exporter 的 network traffic 部分就有列出 nf_conntrack 表的监控。但是因为环境问题,我跑 APISIX 这批机器刚好没整这个监控…再次确认了完善的监控功能的重要性
    • 调整 nf_conntrack 相关参数后,问题暂时解决了。但是接下来遇到 TCP 连接数无法超过 65535 的问题,导致 504 报错…
      • 按理说我 nginx 有两个 worker,worker_connections 也设置到了 65535,至少应该也能撑住 65535 * 2 的连接数量?
      • 发现 alloc : orphaned : timewait 三类 TCP 连接数的比值大概为 66% : 13% : 21%,dmesg 命令能看到很多这样的错误:TCP: too many orphaned sockets
      • 搜索一番确定 orphaned 连接太多一般有两种可能:一是 tcp 连接的内存用尽导致无法为新连接分配内存,二是 TIME_WAIT 导致的 orphaned 连接。所以解决方法是调整 tcp 内存相关参数,启用 TIME_WAIT reuse
  • 读了一点《深入理解 Linux 网络》这本书,因为这两天搞 APISIX 网关,深刻意识到自己对相关知识缺乏了解
  • 英语
    • The Unlikely Pilgrimage of Harold Fry - 13/100
    • 一点英语 270 天英语学习 - 14/270
    • Moon Palace, by Pual Auster - 10.6%
  • APISIX 504 问题
    • 上周给这个 case 提了个 issue 到 APISIX 社区,但是官方给出的思路并无参考价值。
    • 今天晚上左思右想,最可能还是 TCP/IP 协议栈有问题,网上搜了下「丢包 504 超时」,然后根据找到的流程排查了一下,第二个排查项直接命中,就是 nf_conntrack 满了导致的问题!
      • 就好像是找到了正确的房门钥匙是「丢包 超时 排查」,困扰我好几天的问题,瞬间就找到了突破口。
    • 此问题相关的笔记,我后续会在 Linux 504 超时丢包问题解决思路.md 更新
  • 沉迷学英语…
    • 薄荷英语 100 天阅读一本英文书 - 11/100
    • 一点英语 270 天英语学习 - 12/270
    • Moon Palace, by Paul Auster - 6.5%
  • 完成 TLPI 第 5/6 章的习题
    • 习题告诉我 longjmp 是个大坑,能不用千万别用,出错的现象太诡异了。
  • 沉迷学英语…
    • 薄荷英语 100 天阅读一本英文书 - 10/100
    • 一点英语 270 天英语学习 - 11/270
    • Moon Palace, by Paul Auster - 4.2%
  • 最近一直在跟薄荷英语的原版书课程《The Unlikely Pilgrimage of Harold Fry》,就想再次挑战下自己直接去读英文原版书。结果发现 Paul Auster 的《Moon Palace》意外地好读,生词很少,读得很流畅。
    • 然后又陆续试了下《Sophie’s World》、《Majo no Tabitabi(魔女之旅)》,难度都不高,只有《Tasogare-iro no Uta Tsukai(黄昏色的咏使)》生词偏多,读着费劲。
  • 阅读了几篇介绍向量数据库与相似度检索技术的文章,写得非常简洁直观
  • 学英语
  • 完成 TLPI 练习题 4-1 与 4-2,节奏是每天晚上完成一个习题
    • 有点慢,不过毕竟是起步阶段,也能接受。
    • 习题 4-1 主要考察如何读写文件,如何使用 getopt 函数解析命令行参数
    • 习题 4-2 主要考察如何读写含有空洞的文件,主要就是遍历缓存空间,并使用 lseek 跳过空洞部分的写入操作。
  • 学英语
  • 看了 TLPI 作者的演讲 Kernel Recipes 2022 - Once upon an API
    • 以 prctl 为例介绍了 Linux 中一个 API 的错误设计如何影响到 Linux 的其他部分,而且因为缺少文档,也没人维护,其中部分问题直到十多年后才被发现。为了兼容性,这些错误的设计就成了永远不可能被修复的 bug
    • socket api 中有一些错误设计已经在 Linux 中存在了近 40 年,这类错误设计给 Linux 系统编程造成了太多的痛苦。
    • 还有 inotify api、cgroup v1,都是错误设计的典型,它们产生了很多作用,但是考虑的问题都过于片面,由此引发了许多问题。
    • 介绍了可用于避免这些 API 错误设计的一些方法。
  • 看了 TLPI 作者的演讲 An introduction to control groups (cgroups) version 2 - Michael Kerrisk - NDC TechTown 2021
    • 主要介绍了 cgroup v2 的历史,演示了如何使用 cgroup v2 进行 cpu/pid 限制,以及如何使用嵌套 cgroup v2 进行更细粒度的资源限制。
    • 发现 cgroup v2 跟目前内核领域最火的 eBPF 也有些交互,有点意思。
  • TLPI 作者做了很多 cgroup/namespaces/capability model/seccomp 的演讲,可以在 Conference presentations - man7.org 中找到,有时间再看看其他的。
  • 学英语
  • Linux/Unix 系统编程手册(上册) - 进度 136/572
    • 这本书的主要内容就是在介绍 Linux 的各种 C 语言 API,跟想象中的还是有些不一样。(我以为可能像《深入理解 Linux 内核》一样,还会讲内核的一些实现细节。)
      • 也能感觉到 Linux 中也存在相当多的历史包袱,比如说一个文件描述符复制就有 dup() dup2() dup3() 三个函数可用,大文件读写的支持也有好几种实现方式,另外标准 API 中错误值返回方式也存在一些特例需要记忆。总之就是很多地方都有补丁的痕迹,Linux 在不断地进化,许多旧的 API 会慢慢被弃用,新的 API 也会被不断地添加。
    • 虽然不是很有趣,但是还挺好读的,进度已经差不多 1/4 了。不过今天跳过了所有习题,打算明天把跳过的习题都做一遍(不然读了过两天就忘了,等于没读)
    • 这个月或许能把这本「上册」读完,并且完成对应的练习题。
  • 迭代了一波旧文章,修改了几个 typo,调整了部分内容使其更易理解。
  • 发现今天距离这份 history 记录的开始时间刚好一年半,犒劳自己一顿?emmmm
  • 「英语流利说 懂你英语 A+」的 AI 语音太枯燥,放弃继续该课程,卸载了「英语流利说」。
  • 继续「一点英语」、「薄荷阅读」学习打卡
  • 参与开言英语的 WeMeet 英语角,又遇到了 Felix,跟几位 partners 聊得很开心~
    • 主要交流了如何通过各类电影、电视剧等材料去学习英语。明确的一点就是单纯为了娱乐看美剧,对学英语的帮助是很小的。
    • 关键就是重复听,一直到不看字幕能听懂的程度,还可以去领会其中词组、语法、句式的用法。
  • 下午到晚上在 Discord 的中英交流 Chatting Room 里泡了大半天,很多英语还听不太懂,但是氛围很好,聊得很舒服。
  • Linux/Unix 系统编程手册(上册) - 进度 72/572
  • 「一点英语」、「英语流利说 懂你英语 A+」打卡
  • 2022-09-08 开始在「薄荷阅读」上阅读《一个人的朝圣》英文原著,体验甚佳~
  • 试用了常见的各种英语学习软件,做了一些笔记
    • 为了提升阅读能力,购买了薄荷阅读 199 块钱 100 天会员,选的书是《一个人个朝圣》
    • 各个软件都做了一波能力测评,我目前的英语水平应该属于 CEFR 框架的 B1 到 B2 之间,其中最差的是语法跟口语交流能力,其次是词汇量。
    • 各英语学习软件使用体验(仅体验了匹配我当前水平的课程)
      • 流利说挺好用的,价格是 198 元 / 每月
      • 一点英语 APP 测出的水平测评偏高,但是它基于各种视频资料的学习过程真的做得很有趣~ 但是价格也比流利说贵了很多。
      • 开言英语是专业外教录制的视频课,体验也还不错,价格比流利说略高一点,2598 元一年。

/images/now/ryan4yin-english-level.webp

  • 偶然发现手机桌面上有一个安装了好久但是一直没用过的 APP 英语流利说,顺手用它测了下自己的英文水平
    • 流利说把英语分成 7 个 Level,它评价我属于 Lv.5。五个评级维度中我的发音是最好的,口语是最差的。而词汇量大概在 5000 这个档位(我觉得如果算上我懂的计算机名词可能会更高些 emmmm)。
    • 测出的结果跟我的自我感觉基本吻合,之前有跟 AWS 工程师做过几次英语沟通,发现我的口语勉强可以支撑日常技术沟通,但是感觉很费劲,原因显然是口语基本没怎么练过。而我的发音之所以好,主要是大三的时候专门跟着奶爸推荐的《赖世雄美语音标》、《American Spoken English》等资料练习过。
    • 深入探索了下英语流利说这个 APP,花 49 元买了一个月的个性化学习计划,还给分配微信学习社群跟班主任,每天坚持 30 到 60 分钟。第一天体验这个学习计划,感觉确实跟我比较契合,而且也不枯燥,打算坚持一个月试试。
    • 我学英语的目的:听说能力(日常对话)、阅读各类英文资料、写英文博客。
      • 听说能力(日常对话):已经测过非常差了,亟待提升。
      • 阅读:目前可以无障碍阅读大多数编程相关的博客跟文档,但是我对自己的阅读速度以及词汇量还不够满意。
      • 写作:语法这么差,词汇量又低,而且高中后基本就没怎么练过英文写作,我的写作能力显然还有很大的提升空间。
  • 英语流利说「懂你英语 A+ 学习计划」34 课 - 进度 1/34
  • 排查与解决了博客的一个隐藏 bug,记录下排查的思路与流程(省略了其中一些探索性的、方向不正确的步骤)
    1. 朋友反馈站点评论系统登录异常,我着手排查
    2. 通过 firefox devtools 定位到是点击登录后被重定向到了错误的页面
    3. 进一步确认是 utterances 的登录按钮上的 redirect url 参数有问题
    4. 在 DoIT 主题的 issues、代码中寻找 utterances 相关逻辑,未发现问题
    5. 尝试在 utterances issues 中搜索关键字 redirect,找到 https://github.com/utterance/utterances/issues/474
    6. 定位到是页面跳转时仅做了局部刷新,未更新 header 中的 canonical link 导致的问题。
    7. 进一步排查到 DoIt 主题使用了 PaperStrike/Pjax 做页面局部刷新,目的是提升性能
    8. 阅读 Pjax README 发现它的初始化代码格式为 new Pjax({...}),尝试在主题中搜索关键字 new Pjax({ ,找到对应的代码块
    9. 找前端的朋友给了个 canonical link 的 CSS 选择语法,使用该语法修改主题,测试发现问题解决
    10. 提 PR 给这个 Hugo 主题的 github 仓库: https://github.com/HEIGE-PCloud/DoIt/pull/709
    11. 总共用时大约 1h
  • @Bensz 的友链时,发现 APISIX高级路由之通过Body参数转发请求 - 张戈博客这篇文章,它为我正在解决的一个问题提供了非常优雅的思路——使用 apisix routefilter_func 功能,真的是意外之喜~

一直很疑惑,我站点的访客数一直是起起伏伏,但是站点的流量却越来越高。而且流量是平缓地上涨,也不像是有人在恶意刷我流量。

之前没有做过详细的排查,不过觉得估计是跟图片啥的有关吧,把图片全换成了 webp,体积下降约 80%。 但是发现图片这波优化对流量没有任何帮助,流量还是在缓慢上升…

今天跟朋友讨论时,突然发现居然是 index.xml 在跑我的流量,我之前一直以为这个地方显示的是 index.html 首页,就没觉得它有问题…

最后确认这个是我站点的 RSS Feed 文件,也就是 RSS 订阅造成的。 我全站现在一个月也就大概 80G 流量,其中接近 90% 都是这个 RSS Feed 跑出来的 —_—||

排查之下发现是之前为了 RSS 订阅的体验,把所有文章的内容都嵌进去了,导致体积有 2.8M,可能因为订阅量越来越多,以及 RSS 订阅的周期性拉取,导致数据量一直在涨。

解决方法:

做了一波修改,现在只将最新的 15 篇文章内容嵌入到 RSS 里,其他文章只给个标题跟原文 URL,使 RSS Feed 文件的大小降到了 700K,暂时应该不用担心 Vercel 流量用光了…

/images/now/rss-feed-used-too-much-traffic.webp

  • 根据 APISIX 官方建议,使用 priority=-1proxy_next_upstream 实现了请求的 fallback 功能,赞一个。
    • 直接使用 k8s service FQDN 作为 node host 了,因此实质是通过 APISIX + kube-proxy 实现的功能,kube-proxy 负责在 pods 之间做四层负载均衡,负载测试也很正常。
    • 在上游服务挂掉的情况下,所有请求都会首先尝试请求默认服务直到超时,这会导致延迟暴增,所以建议尽量调低 APISIX upstream 中的几个超时时间。
    • 在使用 APISIX 的 proxy-mirror 插件时也遇到了超时的问题,mirror 服务器挂掉导致请求延迟暴增,原因是未调整 proxy-mirror 插件的超时时间,所有请求都会卡在 mirror 请求这里,一直等待完 60s… 将 proxy-mirror 插件的超时时间调整为 300ms 后解决了这个问题。
  • 有个 HTTP 请求失败后 fallback 到备份服务器的需求,想写个 lua 插件来支持它,在 Github 上咨询 APISIX,聊了两天官方一直建议我看看这个 nginx_next_retry,之前一直感觉不太合适,APISIX 的文档也语焉不详,但是今天研究了一波 Nginx/OpenResty 的官方文档,好像又有戏 hhhh
    • https://github.com/apache/apisix/discussions/7773
      • 重点有二,一是设置 proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_403 http_404 http_429 non_idempotent;,二是设置 node 的 priority=-1
    • 也思考了一波,这类需求很特殊的专用网关,到底应该用 Envoy 还是 APISIX/OpenResty,还是说自己写一个…
  • 了解 zig 语言时,读到一篇写得很好的现代化 C 使用体验,写得很好
  • 为了练习 C 语言,使用 ffmpeg 完成了一个 video2ascii 项目
    • 项目地址 video2ascii-c
    • 花了较长时间研究 Makefile 语法跟 clang 的参数,然后又花了很长时间熟悉 ffmpeg 的 api
    • 目前已经集齐用五种不同语言实现的 video2ascii 工具,除了 C 语言是调用的原生 API 外,其他语言都是使用 ffmpeg/opencv 的 wrapper 实现的。
  • 读完 The ANSI C Programming Language
    • 笔记:C 语言笔记
    • 明天写几个小程序练练手,比如 video2chars 哈哈
  • C 语言补完了,开始读 Linux/Unix 系统编程手册 - 进度 56/572
    • 挺好读的,慢慢来感觉了~

/images/now/the-asni-c-programming-language.webp
The ANSI C Programming Language

/images/now/the-linux-programming-interface.webp
Linux/Unix 系统编程手册(上册)

  • Nginx 网关的 TLS 加密:打算换一个思路,用 APISIX 搞个网关再测一波。下周搞搞看吧
  • 晚上读完了《在峡江的转弯处 - 陈行甲人生笔记》
    • 这本书写得极好,作者分享的洞见非常契合我,感觉于我是很有益的。
    • 文字中的感情相当丰富,有人在豆瓣上评论说为此感觉到不适,可我觉得这才是真性情,如此丰富的感情其实正说明了作者的感性,以及对生活的态度。因为看到这样亮眼的光芒而难以直视的人,或许只是因为待在黑暗中太久了(如果是大四颓废的我读这本书,大概就会是这个感觉吧)。
    • 在这里,我也用书中一句话来回答一下 2017 年 2 月 6 日写下「山岭就像时间一样看不到边,翻过了一座又是一座,这又是一种更大的痛苦」的我,告诉他我现在的想法是「脚下虽有万水千山,但行者必至。」至于我是不是在说空话,事实胜于雄辩,就让时间来证明吧。

/images/now/life-notes-of-chenxingjia.webp
陈行甲人生笔记

  • 尝试上线 Nginx Gateway 的 TLS 加密功能,使用了 Google Public CA 提供的三个月有效期 TLS 证书
    • AWS NLB 上观察到大量连接被 Client Reset,tcpdump 抓包后通过 wireshark 分析,确认是大量的 TLS 握手在 Change Cipher Spec 这一步后,被客户端强制 RST。正在到处查 TLS 握手的资料…
    • 奇怪的是,TLS 加密功能放量到 0.5% 左右后,各项 QPS、可用率、延迟等指标都没啥明显的变化,客户端上报的业务指标也正常,就好像 RESET 对业务没任何影响一样…
    • 本地压测一切正常,无法复现这个 RESET 问题
    • 还有一个问题是,发现 cert-manager 给出的证书文件包含了域名证书、中间证书、根证书,导致 TLS 握手阶段发一个证书给客户端直接用了 4000 bytes… 有点费流量…
  • 听歌,看着《江城》,我意识到一件事——多记日记跟笔记,这样到了想要写些有意思的文字的时候,就能发现手边已经有了大量的一手资料,或者发现自己在这方面的积累还很少,或许现在还不是时机。
  • 阅读《在峡江的转弯处 - 陈行甲人生笔记》 - 进度 153/278
    • 第五记「密歇根湖上有一千种飞鸟」,其中有些言行我敬佩不已,有些瞬间让我唏嘘感叹,有些经历我感同身受。
    • 备考清华以及在清华两年学习生涯的描写让我惊觉自己已经工作三年多了,正好仍然是一人吃饱全家不饿的状态,得益于良好的公司文化跟领导带团队的风格,我工作闲暇时间好像也不少,也一直想在业余时间进行一些针对性的学习,提升自己的专业能力跟英文能力。看在大佬们在这个年纪都这么努力的份上,我也应该再加一把劲吧!
  • 阅读《在峡江的转弯处 - 陈行甲人生笔记》 - 进度 36/278
    • 读完了第一记「我和我的母亲」,很久没有这样被感动过了。
  • 2022 年已经过去三分之二,回过头看看这份记录,发现自己确实还是学了不少东西的。值得肯定,周末犒劳下自己~
  • 拿 VISA 信用卡开了个 Azure 云的试用账户,研究了一波。
    • https://thiscute.world 加了个 Azure 的 Front Door 作为 vercel 的前置 CDN,发现效果出奇的好!现在站点访问速度跟国内服务器基本没差了,即使缓存不命中,回源速度也特别得快!
      • 不过价格也比较感人,也只有试用阶段才舍得用。
    • 据说 Azure CDN (Microsoft Standard) 在国内虽然比 Front Door 差一点,但是速度也要强过 CloudFalre/CloudFront,试用期之后可以试试。
      • 算了下 Azure CDN 一个月可能也就 10 刀出头,数据即使丢在 Azure Blob Storage 对象存储里,以我不到 1G 的总数据量一个月才不到 1 刀,完全可以接受。
    • 堪称免备案站点加速方案中的战斗机!
  • 选 Azure 本来只是因为工作天天接触 AWS/GCP,想试用下全球排名第二的 Azure 是个啥感觉,结果意外发现它的国际 CDN 在国内这么快。
  • 当然 Azure 的坑也多,我遇到的有
    • 资源的删除操作存在各种延迟。比如列表还显示该资源,点进去又提示 not available,提示删除失败,但是点进页面资源又已经没了…
    • Azure CDN 的坑
      • 不支持通过 CNAME 绑定根域名,这一点官方没有任何文档说明,但是根据这个博客,实际上可以通过添加值为 cdnverify 的 CNAME 记录到 cdnverify.<endpoint-name>.azureedge.net,就可以解决这个报错…但是即使这样解决了报错信息,仍然存在一个问题——Azure CDN 现在不再给根域名提供 TLS 证书服务,也就是说 HTTPS 没戏了…
      • HTTPS 证书的申请与部署、配置的修改速度特别的慢。
      • 但是 Azure CDN 的上述这些毛病 Azure Front Door 都没有!Azure Front Door 唯一的缺点就是太贵(这或许是我自己的缺点…)
    • 目录是用的 Active Directory,原生的多租户设计,但是感觉真的好难用啊,跟 AWS/Alicloud 的设计区别很大。
    • 所有资源都是 uuid 这一点,感觉不太友好。
    • 删掉了一个旧 CDN endpoint 后,又建了一个跟之前名字一样的 endpoint,结果创建成功了,但是页面到处报错 s[’@odata.type’] is not a function
      • 2022-08-16 更新:这个 bug 持续四天了,而且我测试站点的 http 端口目前仍然报错… 我怀疑是 rules engine 配置错了,但是这个页面也挂了,现在没办法修改,简直离谱。
      • 不得不说 Azure CDN 是我用过的稳定性最差的 CDN,要不是国内速度确实快,我就直接弃坑了
    • CDN 如果把源站改为 custom origin,会有五六分钟的时间疯狂报错 404,之后又莫名其妙地恢复…
  • 收费:Azure 的大部分资源价格AWS 相差无几,都是「平民止步」的定价策略。
    • 而且 AWS/Azure/GCP 的出网流量、跨可用区流量都是额外计费的,不像国内云厂商,云服务器跟网络带宽可以绑在一起买。
  • InfoQ 翻译了一篇文章 为了追求速度,我们测试了全球所有的 CDN,测试了全球的 CDN 速度,画出了一张全球速度最快的 CDN 厂商分布图。其中显示 Azure 的确是中国区域最快的 CDN(仅比较了国际 CDN 服务商,不包含国内)。
  • 试用了通过 Github Action azcopy 将站点上传到 Azure Blob Storage,发现上传太慢了,居然跑了 4mins+,权衡之下还是决定先使用 Vercel 作为 CDN 源站,免费而且部署比 Azure Blob Storage 快多了。
  • 整理与补充今年 5 月份做的学习笔记《分布式数据库的一致性问题与共识算法》,并发表到博客中
  • 极客时间《OpenResty 从入门到实战》
    • 目前市面的网关产品中,性能、可定制性、稳定性三者兼得的仍然只有 openresty
      • 基于 OpenResty 的 APISIX 有丰富的插件,支持插件热加载与配置动态更新,还有实验性的多语言插件支持,长远看或许也是一个很好的选择。
    • 新兴的 envoy 等主推 wasm 插件的网关,性能仍然不如 openresty。另外 envoy 虽然也支持 lua,但是它的 lua 环境没有任何预置的 library,远不如 openresty 这样开箱即用
    • 我目前判断,新兴的 envoy/traefik 等网关的优势在于配置语法简单、支持动态配置。但是如果需要写一些复杂的流量处理逻辑,openresty 仍然是最佳选择。
    • openresty 仍然是最流行的 CDN/软 WAF/边缘网关,在绝大多数公司的网关/CDN 中,都有 openresty 的身影。
  • Misaka 大佬在 twitter 上回复说,ambassador 可能最后会发现都不如 Istio 一把梭
    • 仔细想了下还真挺有道理…毕竟都是 Envoy,而研究一圈发现 ambassador 好像也没比 Istio 多很多功能。目前就看到个不太用得上的 OpenAPI 支持?
  • 今天研究了下 CNCF 中的 API 网关
    • 目前发现 ambassador 的文档是比较不错的,我关心的点(Istio 集成、HTTP/3、Gateway API)都有写到,值得研究一波。
    • 目前就找到这么两个 Istio 网关的潜在替代品:ambassador 跟之前研究过的 APISIX
    • 其他的网关项目有的是功能上不太契合、有的是性能差了点、还有的是不够成熟度或者活跃度不够。
  • Nginx Gateway 进展
    • 在 AWS NLB 上添加 TLS 终止,遇到 AWS NLB 的 TLS 流量费用高、而且 Nginx 无法通过 X-Forwarded-Proto 判断客户端协议的问题
      • 解决方法:使用 cert-manager 在 Nginx 中进行 TLS 终止,AWS NLB 改为纯 TCP
      • 需要注意在 Nginx 上配置使用 OCSP stapling 等 TLS 性能优化手段,并淘汰掉旧的 TLS 协议与 ciphers.
  • 研究了一波 cert-manager 通过 ACME 申请权威证书,并绑定到 Istio IngressGateeway 或者其他网关上
  • 实施网关优化方案,使用 Go 语言写了一个 Nginx Gateway 控制器
    • 目标:
      • 将目前运行在虚拟机上的 Nginx 搬到 K8s 中运行,通过 Istio Sidecar 接入服务网格,并取代掉当前的 Istio IngressGateway 网关
      • 使用 AWS NLB 作为 Nginx 的前置负载均衡器
    • 功能:包含 Nginx 配置同步与 Reload、AccessLog 日志文件的收集与上传
    • 使用 kubernetes/client-go 监控 configmap/pod 的变动
      • watch 接口不会处理网络问题,失败会直接断开连接,实践中不建议直接使用它!
      • 更建议使用 informer,这是一个带缓存的接口,底层是使用 watch 接口 + 队列实现,而且会自动处理网络问题(自动重连),也提供接口强制更新本地缓存
    • 体验:
      • 是第一次用 Go 语言写项目,体验还不错,编译期检查跟语法提示比 Python 强多了
    • 遇到的问题与解决方法
      • Nginx 无法解析 K8s 内部域名
        • 解决方法:在 http 配置块中添加 resolver kube-dns.kube-system.svc.cluster.local valid=10s; 即可,另外所有 k8s 域名都得使用 FQDN 形式,因为 Nginx 不会使用搜索域配置!
      • 客户端 Host 透传:改用 X-Forwarded-Host,而原 Host Header 仅供 Istio/Nginx 用于流量管理。同时在流量走到 Istio SIDECAR_OUTBOUND 时,再通过 Envoy 参数 host_rewrite_header: X-Forwarded-Host 将 Host rewrite 回来。
      • 安全组问题:为了获取客户端 IP 需要在 NLB 上启用客户端 IP 透传,但是这样会导致流量被内网安全组拒绝!
        • 解决方法:在 Nginx 所在的 EC2 上添加安全组,允许公网 IP 访问其 http/https 端口即可
      • 使用 aws-load-balancer-controller 绑定 IP 模式的 NLB,发现 pod 被重新调度会导致请求超时!
      • Nginx 注入 Istio Sidecar 后,响应头里带了些 x-envoy- 开头的不必要 headers
      • Istio Sidecar 性能很差,Nginx 与 Sidecar 的 CPU 比值接近 1:2.3
        • 解决方法:为 pod 添加 annotation traffic.sidecar.istio.io/includeInboundPorts: "",即可禁用掉 Istio Sidecar 的 inbound 流量拦截。
      • AWS NLB 跨可用区负载均衡会收跨区流量费
        • 解决方法:关闭跨区负载均衡功能,不同可用区的 Nginx 使用不同的 Deployment+HPA+PDB,就是都独立进行扩缩容。
  • 2022/7/20,Leader 告诉我,我上半年的表现出乎他的意料,综合表现上看,得到的绩效评价是 S,第一次拿 S,还是挺开心的。
    • 我的优点:
      • 善于观察与思考,真正做到了目标驱动,积极挖掘各种可能性。
      • 善于将优秀前沿技术落地并取得价值,能够不盲从、玩的转、有落地。
  • The ANSI C Programming Language - 83/236
    • 快速过一遍语法
  • 研究云上网关及 Kubernetes 集群的网络架构优化方案
    • 从之前的「多云+多集群网络方案」,先简化为各集群互相独立的网络方案,之后再往多集群、多云等方向去迭代(迂回策略)。
      • 将遗留的 Nginx 网关直接移到 K8s 集群内,并注入 Sidecar 以接入 Istio 服务网格,由 Sidecar 帮助 Nginx 实现集群内的服务发现、流量切分、多集群支持等能力。好处是遗留的一堆 Nginx 配置基本不需要什么改动,改造难度低,收益明显(动态扩缩容的 Nginx、更短的网关链路、更简洁的配置)。后续还可以逐渐切换到新的 API 网关提升可维护性。
      • Nginx 可以通过云服务商提供的 L4 负载均衡(如 AWS NLB)暴露到公网,也可以自建 keepalived 高可用方案(自己整个 Pod 动态注册控制器,或者搞套静态的节点组都行),不过要注意跨区流量,网关最好是每个可用区单独部署一套,互相隔离。
      • 相当于暂时使用 Nginx+Sidecar 彻底取代掉 Istio 的 IngressGateway。讲道理 Istio 的 IngressGateway 功能还是有点弱
      • 等这个方案实施后,我们可能会考虑使用 APISIX/Traefik 或其他基于 Envoy 的网关来取代掉这个容器化后的 Nginx。目的是提供更简单的网关配置方法,当前写 Nginx 配置的方式还是不太友好。
  • Linux/Unix 系统编程手册(上册) - 进度 21/572
  • 感觉最近学东西有点随心所欲,东一榔头西一棒槌,感觉自己还在找方向吧。不过 Linux 跟 Kubernetes 开发这两件事应该能坚持下来。
  • 《语言学的邀请》- 进度 68/288
    • 感觉解答了一些我以前的对人类的一些疑惑
  • 《Intimate Relationship》 - 14/449
    • 读了文化对亲密关系的影响
  • 跟堂弟大谈如何怀揣理想,平实生活,一点点地进步。 谈我们这一代,我想不必悲观也不必绝望,我们的未来由我们自己创造。 有学术大佬们走在学术前沿,有技术高手们工作在工程一线,我们也完全有能力去做一些有价值的事情,赚更多的钱,也帮助更多的人。
  • 读完了《在生命的尽头拥抱你-临终关怀医生手记》
    • 读这本书时,我也在持续回忆我的爷爷奶奶。很难去说明我从这本书中读懂了啥,本质上我只是想从这本书中找到一些慰藉,顺便了解下「死亡」,大概确实部分达成了目标。
  • 买了一千多块钱的书,最近陆续到货了,现在还差一本《我的青春恋爱物语果然有问题——原画集》
    • 多买了一本罗翔老师的《圆圈正义》,打算送给堂弟
  • 阅读了《Intimate Relationships》的第一小节
    • 了解了人类社会性动物的本质,这可以用进化论解释——越社会性的个体存活率越高,基因也越容易传续。
    • 亲密关系的建立是很容易的,「你是我的唯一」更多的是一种浪漫的说法,只是「因为刚好遇到你」而已。
    • 一旦建立了亲密关系,我们就会抗拒这份亲密关系的解离。当亲密关系遭遇危机时,我们会茶不思饭不想。
    • 在 Youtube 上搜了下 Intimate Relationships,找了几个相关的 TED Talks 看了看。
    • 还找到 UCLA 一个比较老的课程:Intimate Relationships: Undergraduate Lectures at UCLA,可以跟书一起看看。
  • 折腾一晚上博客的 Hugo 跟 DoIt 主题
    • 发现本地生成出的站点,mermaid 跟 music 两个插件的问题莫名其妙修复了,怀疑跟今天跑了一波 brew upgrade 有关
    • 但是云上 github action 跟 vercel 都还有问题,同样的命令同样的 hugo 版本,本地生成的静态文件 mermaid 跟 aplay 正常加载,云上生成的就有问题,也是醉了…
  • 观看 KubeCon + CloudNativeCon 2022 中我比较感兴趣的部分
    • 主要关注与当前工作相关的点:多云管理、多集群(karmada)管理与应用部署、跨集群网络(Istio)、API 网关
    • 有一些收获,但是都是比较浅的,只能提供个别方向的一些思路,主要还是得靠自己探索。
  • 研究了一波 dapr,理念很先进,但是发现很多功能都还处于 alpha 阶段,不太适合向业务侧推广,继续观望吧。
  • 研究跨云应用部署方案,如 karmada/kubevela
    • 以 karmada 为代表的多集群 Deployment/Service 管理,需要一个控制面集群+多个子集群
      • 配置只往控制面集群部署,karmada 负责按配置在子集群中创建或更新对应的资源
  • 研究多云+多集群网络方案
    • 以 Istio 为代表的多集群服务网格,部署模型之一也是控制面集群+多个子集群
      • 配置只往控制面集群部署,istio 会将配置下发到数据面的 sidecar 与 gateway,完成相应的网络配置
    • 其他的如 karmada 等也集成了一些集群间的网络打通方案,但是感觉都还不太成熟
    • cilium 的 service mesh 也是一个潜在的多云 k8s 网络方案,但是还处于 beta 状态,有待观望
  • 研究云上 L4/L7 层网关的开源/商业方案
    • 如 L4 的 dpvs/katran 与 L7 的 APISIX/Traefik/Contour,以及 AWS Gateway LoadBalancer
    • 暂时认为云上 L4 还是直接使用云服务商的方案最合适,没必要自己搭
    • L7 为了支持多集群切量,同时尽量缩短链路,目前感觉使用 Istio 最合适
  • 研究各跨云网络方案(L7 负载均衡(ADC)、SD-WAN、WireGuard、服务网格等):
    • 一是多云之间相互隔离,但是长远看不太现实
    • 二是多云使用不冲突的 CIDRs 作为它们的 VPC 网段,然后使用 VPN 把多云网络直接串起来
    • 三是直接在多云上搭建一套 overlay 网络,完全屏蔽掉不同云之间的网络差异
      • 仅针对 k8s 的方案主要是 kilo,基于 wireguard 直接通过公网实现 overlay 网络,但是感觉时延很可能难以接受,还是得用 VPN 才行。
      • 整个云通用的方案目前只有部分供应商在做,而且不开源,有 vendor lock-in 的可能,而且不清楚封装出的具体效果如何
  • 动手学深度学习 - Pytorch 版 - 14.3%
    • 学习第二章:预备知识
      • 微积分:复习了单变量函数的微分(导数) => 多变量函数的偏微分,单变量函数的斜率 => 多变量函数的梯度(梯度,即函数 $f(x)$ 关于输入向量 $x$ 的所有偏微分组成的一个向量)
        • 深度学习模型的训练,即搜索出使损失函数的值最小的模型参数。而梯度下降是应用最广泛的一种损失函数优化方法。
        • 梯度下降,即始终朝着损失函数的梯度值下降的方向进行模型参数的搜索
        • 深度学习中的多元(变量)函数通常是复合的,而链式法则 $\frac{dy}{dx} = \frac{dy}{du} \frac{du}{dx}$ 使我们能够微分复合函数。
      • 自动微分:为了计算梯度我们必须要对函数进行求导,而手工求复杂函数的导数不仅容易出错,而且函数的更新也过于繁琐。深度学习框架通过提供自动微分能力解决这个问题。
        • 实际上,深度学习框架会构建一个计算图(computational graph)用于跟踪所有数值是由哪些操作生成的,有了这个计算图后,我们还可以通过数值反向去更新每个参数的偏导数,这被称为反向传播(backpropagate)。
        • 自动微分的另一个好处是,即使输入函数是一个由代码定义的黑箱,根本不清楚它的具体表达式,仍然可以通过反向传播自动计算出它的微分。
      • 概率论:
        • 采样
        • 随机变量的分析方法:联合分布、条件分布、Bayes 定理、边缘化、独立性假设
        • 概率分布的关键特征度量方式:期望、平方差/标准差
    • 学习第三章:线性神经网络
      • 线性回归模型是一个简单的单层神经网络,只有输入与输出两层
      • 学习了「从零开始实现线性回归」的一小部分
  • 动手学深度学习 - Pytorch 版 - 10.6%
    • 学习第二章:预备知识
      • 通过搜索 cheat sheet + 《Python for Data Analysis》学了下 Numpy/Pandas/Matplotlib 的使用方法
      • 复习线性代数
  • 动手学深度学习 - Pytorch 版 - 7.8%
    • 完成第一章前言,了解了深度学习是机器学习的一个分支,机器学习的用途、分类,深度学习的简单原理及优势,近十年此领域的爆炸式发展
    • 监督学习、无监督学习、强化学习
    • 音视频数据生成领域的重要方法:GAN
  • 分布式系统与区块链
    • 极客时间《分布式协议与算法实战》 - 40%
  • AI
    • 被 ACE 深度学习歌声合成激励到了,花了近两个小时简单学了点吴恩达的机器学习课程、微软的 ML for beginners,李沐的《动手深度学习》
    • 明确了目标是「快速学习,暂时只是为了玩一玩」,确定我应该通过《动手深度学习 - Pytorch》入门。
  • 极客时间《分布式协议与算法实战》 - 36%
  • 学习极客时间的《深入剖析 Kuberntes》 - 100%
    • 学完后第一次做测验,拿了 50 分,陷入自我怀疑 emmmm
    • 容器运行时
      • Kubelet 控制循环 SyncLoop 绝对不会阻塞,任何长时间任务都会创建新的 goroutine 来异步执行
      • CRI 的接口非常简单宽松,给予了底层容器运行时足够大的自定义空间
    • 云原生的发展方向
      • Kubernetes 的强大之处:声明式 API 和以此为基础的控制器模式将「政治」与「技术」拆分开的社区运作模式
      • Kubernetes 生态与传统 PaaS 的区别:Kubernetes 提供了基础设施层能力(编排、调度、资源管理等),使得其上的 PaaS 可以专注于应用服务和发布流程管理这两个最核心的功能,开始向更轻、更薄、更以应用为中心的方向进行演进。从而 Serverless 开始蓬勃发展
      • Serverless 的本质:高可扩展性、工作流驱动、按用量计费
      • 「云原生」是一个使用户能低心智负担的、敏捷的,以可扩展、可复制的方式,最大化利用“云”的能力、发挥“云”的价值的一条最佳路径。
  • 学习分布式系统的一致性问题与共识算法 并记录笔记
    • 一致性问题的核心是「ACID 理论中的事务一致性」,与「CAP 理论中的数据一致性」
      • 数据一致性又分为强一致性与弱一致性,而弱一致性的最低限度就是最终一致性:数据最终会一致(再低就永远不会一致了)
      • 最终一致性太模糊,具体实现上往往会最加上一些限定,得到许多一致性模型:读自己写一致性/写后读一致性、单调读一致性、前缀一致性、线性一致性、因果一致性
  • 学习极客时间的《深入剖析 Kuberntes》 - 87%
    • 简单学习了 CRD + Controller 的编写,包含 Informer 机制等。不过内容太老了,还是之后看 Programming Kubernetes 再详细学吧。
    • K8s API 资源的组织方式为 api/<apiGroup>/<GroupVersion>/<Resource>,yaml 中的 apiVersion<apiGroup>/<GroupVersion>,而 Kind 的值就是 <Resouce>
      • Pod/Node/configmap 等几个核心资源的 <apiGroup> 为空,因此可以直接省略掉
      • 其他核心资源都是以功能分类的,都有 <apiGroup> 属性
    • RBAC 是以 Role 为授权的基本单位,Role 的规则会指定用户对不同 apiGroups/Resources/resourceNames 可以执行哪些动作 verbs
      • apiGroups/Resources 属性跟前面介绍的 API 资源的组织方式是完全对应的,但是 Resources 需要使用复数形式,如 pods/configmaps/nodes
      • 如果是核心资源如 Pod/Node,则 apiGroups 应该设为空字符串 apiGroups: [""]
    • RoleBinding/ClusterRoleBinding 有两个部分:subjects 被作用者,以及 roleRef,用于声明这两者之间的绑定关系
      • subjects 被作用者可以是集群内的 ServiceAccount,也可以是外部定义的对象如 User
      • User 在集群中是一个不存在的对象,它的认证需要一台外部系统
    • RBAC 中还存在 Groups 用户组的概念
      • 比如任意名字空间中所有 serviceaccount 的用户组,名称为 system:serviceaccounts:<Namespace名字>
      • 每个 serviceAccount 的全名为 system:serviceaccount:<Namespace名字>:<ServiceAccount名字>
      • 我们可以在 subjects 中填写一个用户组,为整个用户组内所有的 ServiceAccount 授权
    • Kubernetes 中默认已经内置了多个 clusterrole,可通过 kubectl get clusterroles 查看
      • 开发测试时,我们可能会经常用的一个 clusterrole 就是 cluster-admin,这个 role 拥有整个集群的最高权限,相当于 root,非开发测试环境一定要谨慎使用它。
      • view/edit 这两个 clusterrole 分别拥有整个集群的查看/编辑权限
    • Kubernetes 存储
      • 存储的两个绑定阶段:
        • 第一阶段(AttachDetachController,运行在 kube-controller-manager 中),K8s 将 nodeName 传递给存储插件,插件将数据卷 attach 到该节点上
        • 第二阶段(VolumeManagerReconciler,运行在 kubelet 中),K8s 将 dir 传递给存储插件,插件将数据卷挂载到该目录下(如果是新数据卷还会提前格式化该卷)。
      • 云上 K8s 存储的一个缺陷:无法跨可用区调度。如果你通过 affinity 强制把一个 p8s 调度到别的可用区,因为它的数据卷不在目标可用区,这会导致它无法被调度,卡在 Pending 状态。
      • 学习了已被废弃的 FlexVolume 的实现方式,以及它的替代者 CSI
      • csi-digitalocean 为例,学习了一个 CSI 插件的实现原理
    • Kubernetes 调度
      • 根据容器的 requests/limits 参数,k8s 将 Pod 分为三种类型:BestEffort Burstable Guaranteed
      • 在因为资源不足而触发驱逐 Evection 时,会按 BestEffort => Burstable => Guaranteed 的顺序进行驱逐
      • 当 Pod 中所有容器的 requests/limits 都相等的时候,Pod 的 QoS 等级为 Guaranteed
        • 如果这时容器的 cpu requests 为整数值,K8s 会自动为容器进行绑核操作,这可以大幅提升容器性能,常用在在线应用场景下
        • 疑问:如果 istio sidecar requests/limits 不相等,但是应用容器是设的相等的,这种情况下是否会执行绑核操作呢?
      • Pod 的优先级与抢占机制
        • 首先创建不同优先级的 PriorityClass,然后为 Pod 指定 priorityClassName
        • 调度失败的 Pod 会被放到 unschedulableQ 中,这会触发调度器为这些调度失败的 Pod 寻找牺牲者的逻辑
        • 基于优先级与抢占机制,创建一些优先级为 -1 的占位 Pod,可以实现为整个集群预留一部分资源。这种方法被称为「Pod 空泡」资源预留法
      • Device Plugin: 负责管理集群中的所有硬件加速设备如 GPU/FPGA 等
        • Device Plugin 只能基于「数量」进行调度,无法进行更复杂的异构调度策略,比如「运行在算力最强的节点上」
      • 日志与监控:对我来讲,没什么新东西
      • 容器运行时
        • gVisor - 在用户态重新实现了一遍 Linux ABI 接口、网络协议栈,启动速度跟资源占用小。但是工程量大,维护难度大,对于系统调用密集的应用,性能会急剧下降。
        • kata containers: 据说是性能比较差,运行了一个真正的 Linux 内核与 QEMU 虚拟设备实现强隔离
        • aws firecrackers: 跟 kata containers 的思路一致,但是使用 rust 实现了自己的 vmm,性能更高
  • 了解到 2021 年是区块链投资大涨的一年,总投资涨了 7 倍多到了 252 亿美元,NFT 更离谱直接从 2020 年的 37m 涨到 4802m 美元,感觉确实非常有前景
  • 分两次从币安转了 0.01 ETH + 0.05 ETH 到 Ethereum,币安收了固定手续费 0.0016 ETH * 2
    • 购买 ENS 域名 thiscute.eth 10 年并设为我的主域名,花了约 0.027 ETH,算上 gas 费一共花了 0.0321 ETH 也就是 67 刀
  • 给自己再次整了一个 mirror.xyz 账号,有了 ENS 就是爽。
  • 但是发现我现有的几个域名如 thiscute.world,其实可以直接通过 DNSSEC 导入到 ENS,感觉血亏 0.027 ETH…
  • 阅读郭宇最近写的《Web3 DApp 最佳编程实践指南》
    • 晚上去测核酸的路上还参与了他开的一个 twitter space 聊 web3 开发,发言的很多大佬,很多干货。
    • 也明确了,目前区块链还处于战国时代,百家争鸣
  • 再次确认今年学习路线,精简与调整之前年度的计划(之前的计划太多了搞不定,而且当时没排区块链)
    • 先学好分布式原理与算法这块
    • 然后是 Kubernetes 编程,同时结合极客兔兔的几个教程深入学习 Go
    • 深入学下 Go 语言底层
    • 搞一搞区块链
    • 学习 C 语言
    • 通过 TLPR 学习 Linux 系统
    • 通过 CS144 系统学习计算机网络
  • 阅读 Web 3.0:穿越十年的讨论 - 知乎 系列内容,了解 Web 3.0
  • 阅读 dcbuild3r/blockchain-development-guide,了解如何进行区块链开发
    • 我把这个 guide 完整过了一遍(后面关于自我提升、社会影响力啥的仅走马观花看了看),真的好长的一篇文章啊。
    • 很多干货,现在我对搞区块链开发要学的东西,认知更清晰了。
  • 迭代博客内容《关于 NAT 网关、NAT 穿越以及虚拟网络》- 90%
    • 真的低估了 NAT 网关与 NAT 穿越技术的知识量,又折腾了一个晚上,文章还没完成…
    • 5/9 的时候我就觉得文章已经完成了 90%,结果今天又折腾了一晚上迭代了大量内容,现在感觉文章的进度还不到 90%…越学发现自己懂得越少
  • 学习极客时间的《深入剖析 Kuberntes》 - 53%
    • 学习了 NetoworkPolicy、kube-proxy 的实现原理,其实都是用 iptables 实现的,原理挺简单的。
    • 不过 kube-proxy 很早就支持了 ipvs 模式,它在大规模场景下比 iptables 性能更好一些。但是 AWS EKS 目前官方仍然并不支持 ipvs 模式,打开可能会有坑。
  • 极客时间《分布式协议与算法实战》 - 4%
    • 过了一遍常见共识算法的名字:两阶段提交、Try-Confirm-Cancel、Paxos、ZAB、Raft、Gossip、PBFT、PoW、PoS、dPoS
    • 过了一遍上述共识算法的特性:是否支持拜占庭容错、支持哪种程度的一致性、性能、高可用性
  • 了解了一些区块链相关公司的方向,区块链开发岗位的要求
  • 还研究了一波性能测试工具:grafana/k6
  • 学习极客时间的《深入剖析 Kuberntes》 - 48%
    • 复习了 Linux 虚拟网络接口以及容器网络原理、学习了 CNI 网络插件的原理
    • 学习了两个 underlay 网络实现:flannel 的 host-gw 模式实现原理、calico 基于 BGP 的实现原理
    • calico 在跨 vlan 时需要使用 IPIP,学习了相关原理
  • 完成博客《关于 NAT 网关、NAT 类型提升、NAT 穿透以及虚拟网络》- 90%
    • 简单研究了 Go 的 STUN/TURN/ICE 库,以及 coturn server
  • 简单学习了零知识证明的应用,zk-SNARKs,区块链混币服务,以及拜占庭将军问题
  • 完成博客《关于 NAT 网关、NAT 类型提升、NAT 穿透以及虚拟网络》
    • 已发布,但是还有些细节需要填充,另外还需要补些示意图
  • 学习极客时间专栏《深入浅出 Kubernetes》 - 37%
    • 主要学了下 Pod 的结构、名字空间共享等细节信息,这部分我以前只了解个大概
    • 集群安装、Deployment、StatefulSet、Service 这几个部分我都已经比较熟了,走马观花看了看。
    • 粗略过了下目录,其中对我而言最有价值的,应该就是容器网络、调度器、容器运行时
  • 学习极客时间专栏《深入浅出 Kubernetes》 - 20%
    • Kubernetes 与其他败北的编排工具比,最大的优势在于它的设计思想:
      • 从更宏观的角度,以统一的方式来定义任务之间的各种关系(最底层是 Pod 与 PV,之上是各种控制器、亲和反亲和、拓扑扩散、自定义控制器,网络侧有 service,底层网络插件等等),并为将来支持更多种类的关系留有余地(开放、强大的自定义能力催生出了丰富的生态)
      • 基于状态的声明式配置,由控制器负责自动达成期望的状态
  • 研究 FinOps 与 kubecost,总结工作上的经验,完成一篇 Kubernetes 成本分析的文章 - 100%
  • 研究 FinOps 与 kubecost,完成一篇 Kubernetes 成本分析的文章 - 50%
  • 学习极客时间专栏《深入浅出 Kubernetes》,复习容器技术(Namespace/Cgroups/rootfs)
    • Docker 最核心的创新:
      • 将 rootfs 打包到镜像中,使镜像的运行环境一致(仅与宿主机共享内核)
      • 使用 Dockerfile 描述镜像的打包流程,使构建出的镜像可预期、可重新生成
  • 2022-04-28 调薪结果出来了,突然觉得身心都有点累了,有点惆怅。总之还是继续努力吧,技术才是我的核心竞争力,少管他什么妖风邪雨。
  • 完成了 19 年创建的 go 项目:https://github.com/ryan4yin/video2ascii
  • 失眠,半夜随便翻了翻,把《Go 程序设计语言(英文版)》走马观花过了剩下的一部分,算是完成了一周目
  • 阅读 Programming Kubernetes - Developing Cloud Native Applications - 进度 7%
    • 主要是通过案例讲解 CRD Operator Controller 等 Kubernetes 编程技术

/images/now/the-go-programming-language.webp
Go 程序设计语言(英文版) 2022-08-19 补图

  • 阅读《Go 程序设计语言(英文版)》 - 进度 90%
    • 目前还剩两章未读:反射 reflection 与底层编程 unsafe/uintptr
  • 阅读《Go 程序设计语言(英文版)》 - 进度 72%
    • 主要完成了 goroutines/channels 以及「并发与变量共享 sync」两个章节
  • 多抓鱼买的一批新书到手了,大致读了下几本书的前几页。
    • 目前比较感兴趣的有:《复杂》、《陈行甲人生笔记》、《原则 - 应对变化中的世界秩序》、《这才是心理学》
    • 打算首先读《复杂》
  • 使用 kubernetes/autoscaler 实现集群弹性扩缩容
    • 发现社区的这个工具(简称 CA),确实没 aws 出品的 karpenter 好用。
    • CA 自身的实现很简单,主要是依靠 AWS ASG 实现扩缩容。
    • 而 EKS 的 NodeGroup 说实话做得太垃圾了,底层 ASG 的很多功能它都不支持,一旦创建很多参数(VPC 参数、实例类型、等等)就无法通过 EKS NodeGroup 变更了。如果越过 EKS NodeGroup 直接修改底层的 ASG 配置,它还会提示「Degraded」说配置不一致,真的是无力吐槽。
  • 《在生命的尽头拥抱你-临终关怀医生手记》 - 进度 73%
  • 使用 aws/karpenter 实现集群弹性扩缩容
    • 已上线 prod 环境,目前给 EMR on EKS 集群专用。
  • 更新 /now 页面以及 knowledge 的内容
  • 研究使用 aws/karpenter 实现集群弹性扩缩容
  • 阅读《Go 程序设计语言(英文版)》 - 进度 53%
    • 第 7 章「接口」读了一半,大概 22 pages,预计明天能完成
  • Operating Systems - Three Easy Pieces
    • 读到 Introduction 一章,行文真的很有趣,看 projects 也有深度,决定了要把这本书看完,把习题做好。
    • OSTEP 后面的部分会涉及 vx6 源码,这要求比较深的 C 语言知识以及 x86 汇编知识,不过这些可以在学到的时候,再做补充。
    • 在需要用到的时候,学习 CSAPP 的 x86 汇编部分会是一个比较好的补充。
  • 阅读《Go 程序设计语言(英文版)》 - 进度 7/13
  • 《在生命的尽头拥抱你-临终关怀医生手记》 - 进度 61%
  • 重新整理书单,放到 /now 页面中
  • 学习 NAT 原理知识
  • 阅读《Go 程序设计语言(英文版)》 - 进度 5/13
  • 阅读《Go 程序设计语言(英文版)》 - 进度 4/13
  • 阅读《Go 程序设计语言(英文版)》 - 进度 3/13
  • 学习 3D 引擎的使用,简单试用了 unity3d 与 unreal engine 5.
    • 确定学习方向:先学学 UE5 蓝图入个门,然后试试把 MMD 模型导入到 UE5 做做动画,中间也会简单接触下 Blender.
    • 感受:UE5 挺不错的,尤其是它还提供 VR 编辑模式,手上的 Quest 2 又能派上用场了
    • 输出文档:3D 图形相关
  • 阅读《Go 程序设计语言(英文版)》 - 进度 2/13
    • 第一章「导览」大概过了下 Go 的关键特性:完善的工具链,丰富的标准库,goroutine, channel
    • 第二章主要讲程序结构,包含变量、类型声明、指针、结构体、作用域、包与文件结构等等
  • 阅读《在生命的尽头拥抱你-临终关怀医生手记》
  • 在 Manager 的帮助下申请职级晋升(初级 => 中级 SRE)
    • 再一次认识到我自己写的文字有多么随意… Manager 帮我提炼补充后,文字变得言简意赅,精确客观,瞬间高大上档次了。
  • 《写给开发人员的实用密码学》
    • 完成第七篇「非对称加密算法」的 ECC 部分,并为 RSA 部分补充了部分 Python 代码
    • 将去年写的文章《TLS 协议、TLS 证书、TLS 证书的配置方法、TLS 加密的破解手段》改写并补充内容,改名为《写给开发人员的实用密码学(八)—— 数字证书与 TLS 协议》
    • 为第五篇「密钥交换」补充了 DHKE/ECDH 的代码示例,另外还补充了 DHE/ECDHE 一节
    • 此系列文章的其他小修改与润色
  • 业务大佬在 gRPC 的基础上再添加了 gzip 压缩,TX 流量再次下降 80%+
    • 侧面说明以前业务侧对 HTTP 的用法是多么豪放 emmmm
    • 周末上 gzip 压缩功能,业务大佬太肝了啊…
  • 发布《写给开发人员的实用密码学》系列第七篇:非对称加密算法,但是暂时只完成了 RSA 部分
  • 跟推荐系统大佬一起将服务从 HTTP 切换到 gRPC,效果立竿见影,服务流量下降 50% ~ 60%,延迟下降 30% ~ 50%
    • 提升了服务性能,降低了 AWS 跨区流量成本
  • 发布《写给开发人员的实用密码学》系列的第六篇:对称加密算法
  • 深圳疫情形式严峻,开始居家办公
  • 整理润色后,发布《写给开发人员的实用密码学》前五篇的内容
  • 发现我们的 EKS 集群主使用的是 AWS Spot 实例,这类实例的 c6i/c6g 性能与价格差距并不高,做 ARM 化的 ROI 貌似并不高
  • 发现对 aws 的 RDS/EC2-Volume/Redis 等资源进行全面评估,删掉闲置资源、缩小实例/集群规格,可以轻易节省大量成本(说明以前申请资源时风格比较豪放 2333)
  • 继续迭代个人博客
  • 迭代我的独立博客 https://thiscute.world
    • 添加「阅读排行」页,定期从 Google Analytics 同步数据
    • 从博客园迁移部分有价值的文章到独立博客
  • 购入 Synthesizer V + 青溯 AI 声库,简单调了几首歌试试,效果非常棒。
  • 也调研了下歌声合成领域目前的进展,试用了免费的移动端软件 ACE 虚拟歌姬,渲染效果真的媲美 CNY 999 的 SynthV AI 套装,不得不感叹 AI 的效果真的强啊。
  • 了解 APISIX/Nginx/Envoy 中的各种负载均衡算法,及其适用场景、局限性。
  • 练习二个半小时轮滑,学会了压步转弯技术
  • 无聊,但是又啥都不想干,耽于网络小说…
  • 感觉有点现充了,感觉需要找个更明确的、能给人动力的目标
    • 做个三年的职业规划以及生活规划?
  • 轮滑:复习前双鱼、前剪、前蛇,尝试侧压步、倒滑
  • 将上次 EKS 升级过程中,有问题的服务迁移到 1.21 的 EKS 集群,直接切线上流量测试。
    • 复现了问题,通过 JFR + pods 数量监控,确认到是服务链路上的个别服务频繁扩缩容导致的,这些服务比较重,对扩缩容比较敏感。
    • 测试在 HPA 中添加 behavior 降低缩容速率,同时添加上 PodDisruptionBudget 以避免节点回收导致大量 Pod 被回收,经测试问题基本解决。
  • 遭遇 AWS EKS 托管的控制平面故障,controller-manager 挂了一整天。现象非常奇怪,又是第一次遇到,导致长时间未排查到问题。
    • 确认问题来自 HPA behavior 的 Bug
      1. 储存于 etcd 中的 object 仅会有一个版本,透过 apiserver 读取时会转换成请求的 autoscaling API 版本。
      2. autoscaling/v2beta2 scaleUp 及 scaleDown 对象不能为 null,并在其 Kubernetse 代码可以查看到相应的检查机制。
      3. 当使用 autoscaling/v1 时,v2beta2 版本中的相关对象字段将作为 annotation 保留,apiserver 不会检查 ScaleUp/ScaleDown 的 annotation是否为 non-null,而导致 kube-controller-manager panic 问题。
      4. 我们可以使用 v1 或 v2beta2 创建一个 HPA 对象,然后使用 v1 或 v2beta2 读取、更新或删除该对象。 etcd 中存储的对象只有一个版本,每当您使用 v1 或 v2beta2 获取 HPA 对象时,apiserver 从 etcd 读取它,然后将其转换为您请求的版本。
      5. 在使用 kubectl 时,客户端将默认使用 v1(kubectl get hpa),因此我们必须明确请求 v2beta2 才能使用这些功能(kubectl get hpa.v2beta2.autoscaling)
      6. 如果在更新 v1 版本的 HPA 时(kubectl 默认用 v1),手动修改了 v2beta2 功能相关的 annotation 将 scaleUp/scaleDown 设为 null,会导致 controller-manager 挂掉.
  • 跟公司冲浪小分队,第一次玩冲浪,最佳成绩是在板上站了大概 6s…
  • 将 EKS 集群从 1.17 升级到 1.21(新建集群切量的方式),但是遇到部分服务迁移后可用率抖动。
    • 未定位到原因,升级失败,回滚了流量。
  • 学习极客时间《10X程序员工作法》
    • 以终推始
    • 识别关键问题
    • ownership
  • EKS 集群升级
    • 了解 EKS 集群的原地升级的细节
    • 输出 EKS 集群原地升级的测试方案,以及生产环境的 EKS 集群升级方案
  • 学习使用 kubeadm+containerd 部署 k8s 测试集群
    • 涉及到的组件:Kuberntes 控制面、网络插件 Cilium、kube-proxy、coredns、containerd
  • 思考我在工作中遇到的一些非技术问题,寻找解法
    • 效率:如何在没人 push 的情况下(没有外部压力),维持住高效率的工作状态(早早干完活下班它不香么?)。
      • 建立有效的「自检」与「纠错」机制
        • 自检:
          • 列出目前已知的「异常」和「健康」两类工作状态,每日做一个对比。
          • 每日都列一下详细的工作计划,精确到小时(预留 1 小时 buffer 应对临时需求)。
    • 沟通:遇到问题(各种意义上的问题)时,及时沟通清楚再继续推进,是一件 ROI 非常高的事。否则几乎肯定会在后面的某个节点,被这个问题坑一把。
    • 目前的关键目标是啥?存在哪些关键问题(实现关键目标最大的阻碍)?我最近做的主要工作,是不是在为关键目标服务?
    • 如何把安排到手上的事情做好?
      • 思考这件事情真正的目标的什么?
        • 比如任务是排查下某服务状态码有无问题,真正的目的应该是想知道服务有没有异常
      • 达成真正的目标,需要做哪些事?
        • 不仅仅状态码需要排查,还有服务负载、内存、延迟的分位值,或许都可以看看。
      • 跟需求方沟通,询问是否真正需要做的,是前面分析得出的事情。

这些问题都是有解法的,关键是思路的转换。


  • 容器底层原理:
    • linux namespace 与 cgroups
    • linux 虚拟网络接口 macvlan/ipvlan、vlan、vxlan

  • 阅读 rust 语言的官方文档:the book
  • 边读文档边做 rustlings 的小习题
    • 目前完成了除 macros 之外的所有题
    • 遇到的最难的题:conversions/{try_from_into, from_str}
  • 使用 rust 重写了一版 video2chars

  • Linux 的虚拟网络接口
  • Linux 的 netfilter 网络处理框架,以及其子项目 iptables/conntrack

  • 学习 nginx - openresty - apisix
  • 工作中,在自己负责的领域,建立起 ownership
  • 学习新公司的工作模式:OKR 工作法
  • 学习新公司的思维模式(识别关键问题)
    • 如何从公司的角度去思考问题,找到我们目前最应该做的事情
    • 从以下角度去评价一件事情的重要性
      • 这件事情对我们目前的目标有多大帮助?
      • 需要投入多少资源和人力?
      • 在推进过程中,有哪些阶段性成果或者 check point?