2022年11月第四周周报

这周的周报又可以按时交了

生活

本周的早睡时间保持的不错，不过导致我看番时间少了很多
药物反应好了不少
本周的娱乐时间
1. 德凯第19话，坂本接久弥出院了？我为什么会做这样的梦啊（不是。不过说回来，这话有个我很不爽的点就是对于战队的刻画太过于玩笑了。一个维护世界和平战队居然在队员失踪后没有响应我觉得属实离谱。目前来看奥系列两个刻画最好的战队一个是
  XIG 一个是 TCP，其余都有点玩笑（当然旧平成和昭和还是比新生代好了不知道多少个假面骑士（
2. 间谍过家家第21话，我觉得这几话质量都不太行
3. 柯南剧场版万圣节的新娘，简而言之是长征五号柯南限定皮肤，不过比绀青还是好了太多
4. 樱花庄的宠物女孩，可爱（
5. COD19 的战区模式我还是落地成盒
6. 刷完了食梦者，哇，真的好看看看看看看看！
本周的闲书时间继续
1. 继续捡起《上帝的骰子》看
这周是继续在家封控的一周，得自己做很多吃的。我突然有了一个梦想，就是有钱有闲之后去开一家以不亏本就行为目标的平民餐馆
家里的小猫咪们这周偷吃火腿的偷吃火腿，拆家的拆家。收拾现场时流得泪，是当年决定养猫时脑子进的水
这周和一位群友一起聊了聊，感慨不同的人真的有不一样的人生，这样听别人讲自己的人生的经历真的很棒

技术

这周的我 be like：怎么一周突然就过去了

我开始使用vim啦！经过周末两天的学习，我现在已经能正常使用了（本周报就是 vim 写的（某回忆出来挨打
1. 我放弃了 Lunavim 的配置，因为使用还是比较复杂了，我基于 cosynvim 的模板，封装了一套自己的配置
2. 我在配置里加了一些自己需要的功能，比如 LSP 自动安装管理，比如 GitHub Copilot 支持
3. LSP 现在的使用体验真的不错
4. 基于 LUA 写配置写插件真的很爽，看起来我之前入坑 vim 的原因就是 vimscript
5. 过程式的声明真的很符合直觉
这周群里在讨论 envd 的时候，聊到了 Docker 的几个缺陷
1. Dockerfile 的可复用性太差了
2. 很多 Buildkit 支持的很有用的特性支持都很奇葩
3. Dockerfile 很多时候的还是面向状态的描述而不是过程的描述，进而导致其可复用性太差
这周还是花了一些时间在 nerdctl 上
1. Issue1425 写了一个正式的 Proposal，参见 Issue1560
2. Issue1329 的进度比我想的慢一些
3. 这周和 @yuchanns 聊了下为什么 nerdctl 现在都还不支持 network connect 的原因，本质上还是因为 nerdctl 在设计之初的定位在一个弱状态的 CLI，没有 daemon，很难去维护一些重状态的操作。network connect 是个很典型的例子，将 network 和一个已经存在的 container 打通。这个过程一旦状态维护不对，那么 iptables 之类的资源泄漏的副作用会非常大
这周查了业务那边比较蛋疼的一个线上事故，对于慢查询这种东西，日志的存在过于重要
这周群里大概定了一下明年大家集体的 OKR
1. O1: 公益
  1. 通过公益刷题/分享之类的活动，凑集超3000元捐款
2. O2: 开源项目
  1. 新增一位开源项目的 maintainer
  2. 全年各开源项目代码 PR 数超过 15
这周读了 SEDA: An Architecture for Well-Conditioned, Scalable Internet Services 这篇论文，有点年头了，UCB 在 SOSP 2021 上的论文（里面测试环境都还是 2G RAM（XD，不过里面的思想在后面很多的项目上都能见到影子，可能会在群论文分享会上聊下这篇文章，这里先简单记一下
1. 这篇文章的核心还是在说处理高负载流量下的一些手段
  1. 基础的 per-request, per-thread 模形，在这篇论文的写作的时间下，Apache，IIS 之类的都是这个模型。缺陷就很明显了，请求多的时候，线程太多，导致系统的负载太高，调度 overhead 太大（经典面试八股文)，作者有个很经典的描述 “the design of these systems is still based on multiprogramming, as the focus continues to be on safe and efficient resource virtualization, rather than on graceful management and high concurrency.”
  2. 线程池模型，作者认为这个模型的缺陷在于，线程池的大小是固定的，如果线程池的大小不够，那么就会导致请求的排队，这个排队的过程会导致请求的延迟变大，如果线程池的大小太大，那么就会导致系统的负载太高，调度overhead 太大。另外一个是，需要根据不同的负载进行线程池的划分，有个很好的例子，比如有两类请求，一类是读文件再返回的重请求，一类是直接从缓存里返回的轻请求，即便在整体系统负载偏低的情况下，如果突然来了几个重请求，把所有线程池的线程都吃了。这个时候后续的轻请求就只能继续排队了，即便只需要一个线程处理就行了。换句话说线程池的公平性调度是个问题。
  3. 事件驱动模型，所有 blocking I/O 都被转化成 event，然后投递到各个子模块进行执行。每个子模块都有自己的 FSM，request context 就会被 FSM 管理起来（有没有很熟悉，实际上就是 Nginx 的经典做法）。不过缺点也很明显
    1. request context 的维护实际上比较麻烦
    2. 一处 blocking 可能会导致全局 blocking
    3. 每增加一处子模块可能就需要修改 event dispatcher 的逻辑（
2. 然后提出了核心的 SEDA 模型，将一个理想系统的处理划分为若干个 stage，stage 之间通过 event queue/subroutine call 进行通信。每个 stage 的 controller 面对 resource 建模，支持批处理，这样来尽可能的扩大系统的吞吐能力。不过缺陷也比较明显
  1. stage 的合理划分。论文本身建立在业务都是可以抽象为一个理想的 pipeline 的基础上，理想很丰满，现实很骨感。实际上这个就有点变成领域建模的意思了
  2. 批处理还是需要对任务载荷进行分类，而且受限于这篇论文所处的时代，可能没考虑批处理的原子性的问题
3. 作者表示能正确衡量系统 bottleneck 的测试集很重要。瞎 benchmark 等于没 benchmark，点名批评现在各路 DB 动不动就 benchmark（逃
这周我被提名为 nerdctl 的 committer 了，拥有对仓库更大的权限了（意味着更大的责任了。新进群的 @yuchanns 也被提名为 reviwer 了，开心（
写了一篇水文聊聊我的开源经历，参见我所热爱的开源社区。