Hi，欢迎来到 卡瓦邦噶！ 我叫 laixintao，我有一种特别的幽默感。我的梦想是让网络变得更加开放、自由和快速。这个博客发布我的一些想法，编程相关的文章，以及书、电影、游戏和音乐。
声明：本博客内容仅代表本人观点，和我的雇主无关。本站所有内容未加说明均为原创，一经发布自动进入公共领域，本人放弃所有权利。
玩了一下 Github 个人首页的 Profile （使用 Action 自动更新）
Github 最近推出了一个 Profile 功能，大体上就是用户层面的 Readme。如果你新建一个和你的用户名一样名字的仓库，这个仓库的 Readme 就会展示在你的个人主页上。
虽然仅仅是一 Markdown 形式的 Readme，但是可玩性也很多了。
比如有一个服务，将这个服务 URL 的参数改成用户名，就可以用一个图片显示个人的开源贡献信息等，原理和项目上的 badge 差不多。
还有展示自己的睡眠数据的：
还有展示年度进度的：
还有在主页交换链接的，并且把这些链接做成了很漂亮的卡片：
我一直很喜欢看维基百科的 Picture of the Day，甚至有一段时间写周报的时候，每周都会贴一张 Picture of the Day 的图片在周报的末尾。一个原因是这些图片都非常精美，是由一个小组挑选出来的，普通用户也可以贡献，你可以发现这个世界上还有这么漂亮的地方。另一个原因是阅读维基百科可以学到知识。
2020-01-02 的 POTD
所以我就做了一个每天更新 Picture of the Day 的 Github Profile。基本的原理就是使用 Github 的 Action 功能，每天跑一个脚本，去维基百科查到今天的 Picture 地址，然后更新 Readme 中 Picture 的 URL，这个 Readme 就会展示在我的首页上。
实现非常简单，所有的东西都在这个仓库里面。如果你想制作定时更新的 Profile, 可以参考一下这些脚本：https://github.com/laixintao/laixintao
有几个可以少走的弯路，分享一下：
- 让 Action 的机器人 push commit 是一个比较 tricky 的事情，好在可以直接用别人写好的 Action，这就是 Github Action 的设计精妙之处吧。像 checkout, setup-python 这种东西，都有现成的 Action 了，不同的用户之间可以组合 Action 实现自己的 CI。git push 使用的 Action 是这个：https://github.com/ad-m/github-push-action 使用方法可以参考这里，可以说非常简单，甚至 Github 的 Action 运行的时候默认就会设置环境变量 secrets.GITHUB_TOKEN，连你手动给机器人设置 Write 权限的 Token 都省去了。
- 使用 Action 更新 commit 是一种方法，应该也是简单的方法。一开始我是想用 clock.sh ，不需要 clone 下来仓库，直接使用 Github 的 API 去创建 block，然后创建 tree 和 commit，但是这样操作太复杂了，就放弃了。有想法的用户可以研究一下 Github 的这套 API。
- 放弃了 clock.sh 的代价就是…… Github Action 的
schedule功能感觉有 bug. 如果 workflow.yml 写的有问题，Github 不会告诉你哪里有问题，直接就不会运行，对于调试来说还是挺不方便的；使用schedule会有一些坑。比如一你开始写了一个 crontab15 * * * *，调来调去最后发现无论如何改都生效不了了。而且 Github 这边就是不运行，没有调试方法。比较直接的方法就是直接将 workflow 换一个名字，push 过去，这样相当于在 Github 那边新建了一个 workflow，重新 schedule. 所以遇到此类问题不要怀疑是不是你的 crontab 写错了，直接换一个 filename 吧。 schedule功能最短的运行时间是 5min 1次，所以写* * * * *是没有意义的；
最后，我发现维基百科有时候会更新出来很恶心的图片，比如今天的…… （恶心，慎点 https://en.wikipedia.org/wiki/Template:POTD/2020-10-08 ）
对中台的一些想法
声明：本文仅代表个人想法，不代表我的雇主的想法，也不代表我的同事的想法。
一开始有人开始提出“中台”这个概念的时候，我对此是嗤之以鼻的，认为又一个的炒作的概念。对于中台，我的认识是，将一个垂直领域的东西做成一个 SaaS 平台，它的价值就是避免一定程度的重复建设。举个例子，比如一家公司的很多个 BU 都有播放客户的广告的业务，那么追踪广告的效果就是每一个 BU 做的事情。这个事情需要做 N 遍，但是如果将广告效果追踪变成一个 SaaS 服务，就不需要大家都去做一遍了，只要接入并使用这个服务就可以。这是我理解的中台，可能和其他人的理解有出入。即使在最初提出“中台”的那帮人里面，估计也有很多不同的理解吧。
总之，后来我的 title 也不知不觉地变成了中台开发工程师。这篇文章就讲讲我们走过的弯路吧。
我们做的中台叫做故障定位中台。出现这个“中台”也有一定的历史原因，我们公司很多 BU 都有做故障定位的 SRE，也就有很多故障定位系统。我们在中台想做的就是把这些故障定位系统给统一接入进来，复用一些能力。
至于具体的实现就不多说了，没有什么魔法，如果让你来实现，估计跟我们现在的样子也不会差太多。主要说一下我们做的不好的地方吧。
简单
对于一个需要其他系统接入的中台来说，我觉得最重要的东西就是简单。在一个垂直的领域做中台，不可避免的要引入一些新的，抽象的概念。但是引入概念越少越好。印象比较深的，红姐以前试图教我设计 DSL 的时候说过，先实现功能，然后看哪些东西是可以去掉的，最后剩下的就是 DSL. 我觉得非常对。只有简单，才能让出错的概率更小，接入的成本才会低，别人才会愿意用你的系统。中台最大的失败就是没有人使用。
先实现功能，然后看哪些东西是可以去掉的，最后剩下的就是 DSL.
我觉得一个产品在不知道将什么作为自己的竞争力的时候，“简单”就是最好的竞争力。比如 clock.sh ，一个可以托管 cronjob 的平台，创建一个新的任务只需要填写 4 个值，你的 cronjob 就可以跑起来了。
没有保持简洁，就没有用户。没有用户，也就没有后面的故事了。
而我觉得踩过的最大的坑， 就是这里。有同事之前是做交易系统的，我感觉他们设计的东西都非常复杂。以我们的接入接口来说，入参有 20 个参数，返回值需要用户填 20 个参数，就太复杂了。每次新用户接入，我基本上要给他们培训 4 个小时的时间，后续配合调试的成本也巨大。
作为一个平台，至少要做到用户自己看文档就可以进行接入。不然每次接入都需要进行特殊的培训，显然是不具备通用性的。
度量指的是对于接口方需要让他们看到一个运行的状态，知道自己的东西运行了多少次，效果是什么。
度量与统计（管理）
大部分的中台会作为一个服务提供方让别人来接入吧。所以就有对接入能力管理的要求。对于我们的平台来说，这个管理的需求统计这些接入方运行了多少次，失败了多少次，运行的效果如何。
不同的平台对于统计和度量的需求也不是一样的，分情况具体对待吧。我们的情况更有一些棘手，就是很难通过程序来判断运行结果的正确性。这里有一个悖论，就是如果我们如果事先知道一个结果对不对，那么就相当于我们已经知道了“正确的答案”了，后面做的事情也就没有必要了。所以现阶段我们的度量还是基于人工的。
集成功能
中台一个核心的思想就是 1）减少重复劳动，将一些轮子一次性做好，其他人只要用就可以了 2）结合一些已经有的系统，发挥1+1 > 2 的效果。
所以对于一些常用的操作，可以封装成 SDK。这句话说起来很简单，门槛也很低，谁都可以写。但是实际做的好不简单。可惜的是，很多喜欢写 PPT 的人认为“写代码是最简单的事情，是没有技术含量的事情，是谁都可以做的事情”。我见过的大多数的 SDK 都乱七八糟，一通乱写。
要注意一个点是，尽量地少抽象新的概念，如果没有必要，不要增加实体。尽可能地减少框架对用户的束缚。尽量让自己提供的东西成为一种“选择”，而不是一种“约束”。
说到这里，我又佩服 prompt-toolkit 写成了一个库，而不是一个框架。框架是它来调用你写的 API，就增加了很多的限制。而库是你去调用它的 API. 举个例子，从上手成本上说，一个库你可以看一下函数声明就上手开始用了，对于一个框架，你要知道它是怎么运行的，它是怎么调用你的代码的。
实时上传数据备份文件到S3
最近写了一个小工具，用处是可以将数据库的备份文件上传到 S3 上面去。学到了一些很有意思的东西，觉得值得记录一下。
工具的源代码：https://github.com/laixintao/mydumper2s3
备份数据库的方法
最简单的方法，只要将数据库 dump 出来，然后上传到 S3 即可。
但是全量 dump 出来数据库占用磁盘的空间较大，并且上传完之后一般都删掉了。有一种可以不浪费本地磁盘的空间的方法，之前在博客《用 ssh 传输文件》中介绍过。我们可以用管道将 dump 的进程和上传的进程连接起来，这样就不需要本地的磁盘了。
类似这样的方法：
|
1 |
mysqldump database | gzip | aws s3 cp - s3://bucket/aws-test.tar.gz |
MySQL 自带的 mysqldump 命令是支持将数据库 dump 到 stdout 的，然后我们使用 aws s3 的 cp 命令，将源文件设置为 stdin，中间加了一个 gzip 做压缩上传。因为 SQL 文本压缩空间很大。
使用 mydumper 的问题…
mydumper 是一个第三方的开源 dump 工具（只有 3k 行 C 语言代码）。做的事情其实和原生的 mysqldump 差不多，但是有几点好处（引用 Readme）：Parallelism, Easier to manage output, Consistency, Manageability. 在我看来，最重要的是 Parallelism，它比原生的 mysqldump 要快很多，（猜想）这个速度快是用了很多黑魔法来实现的，比如采用了多线程同时写入多个文件的方式，因为多线程 dump，并不支持输出到 stdout，因为每一个线程都需要一个 fd 来写入（还是我的猜想）。在不修改 Mydumper 的代码的情况下，直接使用 Unix pipe 是不可行的。
所以，要是使用 mydumper 的话，我想到了以下几种方法。
1. 将 S3 挂载到系统上，作为一个文件系统
考虑使用 https://github.com/s3fs-fuse/s3fs-fuse 将 S3 直接挂载到操作系统上，这样 mydumper 并不知道自己在往网络上上传，fuse 封装出来一套 POSIX API，不是完全兼容的，还不知道够不够 mydumper 用，但是感觉问题不大。
这里的问题是，每次文件创建，每一次写入，都是通过网络做的，网络不稳定可能会有问题。也不知道问题会多大，我还没时间测试。
2. 黑魔法，使用 LD_PRELOAD 直接覆盖 write_data
链接的时候可以提前 load 我们定义好的函数，来覆盖 mydumper 的函数。（相当于 Python 的 mock.patch 功能）
比如写一个这样的函数：
|
1 2 3 |
int rand(){ return 42; //the most random number in the universe } |
然后定义环境变量：
|
1 2 |
gcc -shared -fPIC unrandom.c -o unrandom.so export LD_PRELOAD=unrandom.so |
这样在运行程序的时候，随机数得到的就永远是 42 了。
看了下 mydumper 的源代码，只有3k+行 clang，考虑可以使用 ld_preload 直接将他的 write_data （以及打开文件相关的操作）直接覆盖（考虑使用golang，比较好些），将实现直接替换成写 s3。
这样相当于不需要本地磁盘就可以上传了。
参考：https://jvns.ca/blog/2014/11/27/ld-preload-is-super-fun-and-easy/
3. 两个进程，一边 dump 一边上传
这个思路比较朴素，就是 mydumper 只管普通的上传，而另一个进程（我们就叫它 mydumper2s3 吧），只管上传，然后上传文件完成之后，就将上传完成的删掉。
这样，只要上传的速度比 dump 的速度快，就依然还是可以继续的。就怕磁盘空间不够，上传的速度又比 dump 的速度慢，就悲剧了。
这个问题我一开始纠结了很多，最后发现应该也不是什么大问题。以为：
- 看了一下 S3 的技术规格，如果在同一个局域网内，速度是 GB 级别的，而 mydumper 是几十M1秒；
- Mydumper 支持
--compress，自带压缩功能，那实际的写入速度又要慢上一些； - 实在不行，可以用 systemd/ionice 这种工具对 mydumper 的进程限速；
所以就不去考虑这个问题了。
有趣的是，我去翻 mydumper 的 issue，发现竟然有人抱怨在磁盘慢的时候 iohang 住，而不是报错（issue）。不过作者回复说这样挺好的啊，这样不就给你时间释放磁盘空间了吗：）
我也想要这样的 T T
实现细节
在 mydumper 还在写入文件的时候上传，需要注意，正在被打开并写入的文件先不要上传，等文件被关闭之后在开始上传。所以需要维护 4 个文件列表：
- 当前 dir 下的所有文件；
- 正在被打开的文件；
- 正在被上传的文件；
- 已上传的逻辑；
然后每隔 1s 扫描一次文件夹，将 “当前 dir 下的所有文件” 中，没有被打开、没有被上传、没有已上传的文件，加入到上传队列中。其中要注意好多线程之间的逻辑，至少需要一个定时扫描的 watcher 线程，然后需要一个上传的线程池（注意连接池的大小不要小于线程池的大小）。比如我写的一个 bug 是这样的，将这些文件加入到上传队列，但是没有立即更新到 “正在被上传的文件”中，而是线程池真正开始上传的时候才更新。这样就导致下一秒扫到的时候认为这些正在队列中的文件还没有上传，又入了一次队列，导致文件被重复上传了非常多次。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
+-----------+ | mydumper | +-----+-----+ | | v +-----+------+ upload +-------------+ +------+ | local disk +----------> mydumper2s3 +------> s3 | | <----------+ | |bucket| +------------+ delete +-------------+ +------+ after upload |
一开始我是想用 inotify 这种接口去监听文件变化的，最后变成了定时扫描（扫描间隔是可以用命令行参数 --interval 控制的），是考虑到下几点：
- inotify 只能在 Linux 系统工作，不同的操作系统，文件变化的事件不同；
- 实现太复杂，需要3个线程，监听创建 + 监听关闭 + 上传线程，这些线程之间需要通讯；
- 需要处理一些临时文件的变化，比如
metadata.partial最后 dump 完会被重命名成metadata；
最后实现的效果如下：
验证备份文件
还写了一个工具可以校验上传文件的 md5.
有个有意思的地方，如果文件太大（超过5M？），S3 的 SDK 在上传的时候会使用 multipart 上传，如果是multipart上传的，s3上面的 e-tag 不是整个文件的md5，是每段的md5合起来再md5. 这样校验就非常复杂。
我发现了这个神奇的bash，按照s3的逻辑在本地文件切段，然后计算hash：https://gist.github.com/emersonf/7413337 （from: https://www.savjee.be/2015/10/Verifying-Amazon-S3-multi-part-uploads-with-ETag-hash/）。
最后，这个工具的源代码在这里：https://github.com/laixintao/mydumper2s3
近况更新
好久没写博客了，决定唠叨一下最近的生活和工作，避免这个博客长草。
大约从5月份开始，我们项目进入了“闭关室”，几乎是封闭开发的状态，但是我没想到的是，到现在我都没有从闭关室里面出来。这几个月的工作中经历了很多事情，大多都不顺，但是总之还是坚持到现在。最有意思的是我在很短的时间内换了 4 个老板：一开始的老板突然就转岗了，我直接汇报给老板的老板；2天后，老板的老板“拥抱变化”了，我就汇报给老板的老板的老板；最近老板的老板的老板招来一位转岗过来的博士，博士就成了我现在的老板。
虽然工作内容没有太大变化，但是工作的思路变化了很多。一开始的老板在，很多决策上都坚持的比较彻底（现在想想好像有些错了），他走之后，我们的思路几乎就变了，然后我就在原来的基础上做很大的调整。我觉得之前的设计太复杂了，我们作为中台，设计的接口里面入参有二十几个，出参有二十几个，每次接入方来找我的时候，我都要费半天的功夫给他们讲这些参数是干嘛的（大部分时间你们都用不到，这是为了“将来的扩展性”）。接下来我想找时间实现一个新的接口（但是兼容之前的接口，让两种接口同时存在）。关于设计上的复杂性，我跟前老板争论了很多次，我坚持应该保持简洁，代码写的越少越好，给别人的参数应该越少越好，我们现在几乎还在 POC 阶段，应该保持足够的简单来适应将来的变化，快速试错。但是被“要考虑扩展性，要考虑将来的需求，要考虑3年的长远目标”给驳回了。导致现在的系统中充斥着各种复杂的概念，实现一个简单的需求需要大规模的重构。
老板走后，我们在去年成立小组的时候的4个人，就只剩下我一个了。另外两个一个是转岗，一个因为工作地的问题划到另外一个组了。好消息是，8月初入职了一个新同学（我也理所当然地成了新人的师兄），所以应该是剩下我们两个人。然后几乎所有的事情都到我这里了，每天不停的有人找我提新的需求，由于平台（设计上）的复杂性，几乎每个需求我都要和同事分析半天。这些复杂的东西也要讲给新人。说实话我好怕新人一看我们这些过度设计提桶跑路。不过好的地方是，我不再像1年那样抵触这些过度设计了。要是那样的话，估计我现在都有很多代码看不懂。现在我已经把系统的代码看了好几遍，很多过度设计的地方也理解了是想到了将来的什么地方。不必要的地方可以自信的删除掉。
我发现起名字真是写好代码的一个硬实力。我们的代码中有很多 invoker, execute, doExecute, item, call 之类的名字，不同的概念起的名字几乎一样，比如 Action, ActionItem, ActionInfo 这种。导致非常难以理解。该加注释的地方不加，不需要加注释的地方乱加，看起来注释率很高，但是大多数都是废话。非常头疼。
说回工作，这个事情感觉我已经做了两年，但是依然没有满意的成果，有点力不从心了。自己的想法没有机会去做，总是感觉是在一堆摇摇欲坠的系统上做一个火箭。不知道这样做下去会是什么结果。有时候会想，要是我自己完成所有的事情，不需要PD，不需要UI，也不需要前端开发，都是我自己去做，实现的效果可能会更好一些。现在是大家的想法（主要是老板的），然后开五六个会确定怎么做，然后我来做主系统分析设计，告诉其他的几个系统怎么配合，这样做下来几乎每个人只会理解70%（还有人不停地问讲过好几遍的问题，心好累），做出来的东西就差一大截。
唉，不说工作了，越想越烦。
搬了新家，开始扔掉一些“觉得有用但是一直没有用过的东西”，感觉很幸福。处理掉了200来本书，都送出去了，留下十几本还没看完的。感觉换一个环境住是一件很快乐的事情。
最近在玩《荒野乱斗》，也有1万杯了，有玩这个游戏的朋友欢迎加个好友，我的玩家标签是：#PYLL90LR 。最近茶杯头登陆 PS4 了，想玩。糖豆人 PS4 港服的会员赠送了，我也有了，也想玩，可惜没时间。想玩微软的模拟飞行，可惜没电脑。
DDIA 快要看完了，真是一本不可多得的好书！
iredis 最近攒了很多 Feature 没有做，最近下了班会找时间搞一搞。
睡觉去了，不知道自己都写了些啥，好乱。
Reaper 使用 ReaFir 插件对音频降噪教程
最近和 Luke 录制了一期播客。本来我们是买了一个话筒寄给嘉宾的，但是这个话筒不知为啥有电流声。所以就临时改成用手机录音了，出了点状况，导致最终出来的音质不是很好，Luke 的音轨底噪有一些强。放弃这一期不发布实在可惜，一筹莫展之际，我把剪辑好的 Mp3 文件发给最近一直在催更我的朋友听了，他说他用 iMovie 降噪之后听着还可以。这让我重新看到了希望，我去找了一些 Reaper 的降噪教程，想尝试对 Luke 的音轨进行降噪。最后的效果还不错，所以这里将我学到的降噪技巧分享一下，方便制作播客的兄弟们参考。
降噪的原理
如果你用过降噪耳机，你应该听说过「主动降噪」 这个词。它的原理就是，耳机会采集周围的环境声音，然后播放音乐的时候，播放一个和环境声音相反的声波。到你耳朵里的时候，因为耳机的反向噪音和环境噪音抵消了，就只剩下播放音乐的声音了。
剪辑技术中的降噪也是一样。先采样环境噪音，然后对整个音轨播放一个反向的声波，这样噪音就被抵消了。
上手操作
ReaFir 是 Reaper 自带的一个插件，可以完成降噪这项工作。Reaper 是一款非常优秀的音频处理软件，配合 UltraSchall4 插件，简直就是我一直在寻找的那个完美的播客剪辑软件！建议剪辑播客的朋友都尝试一下，UltraSchall4 专门为剪辑播客设计，里面的像 Normalize，切分，删除口头禅这样的常用剪辑操作都设计地非常方便。可以大大节省我们的剪辑时间。
话说回来，ReaFir 是 Reaper 自带的一个插件，不需要安装就可以使用。像一次典型的降噪处理，流程主要如下。
下面是我的剪辑界面，如果你没有安装 UltraSchall4 的话，看起来可能会稍微有些不一样。不过没关系，你只需要参考我的这张截图看如何找到对应的按钮就好了。
假设在这个剪辑界面中，我们的第二条音轨——Luke 的音轨底噪比较强。我们要对这条音轨进行降噪。首先在左下角用 FX 按钮打开音效插件界面。第一次打开可能没有我这里的 ReaFir 的，这时候点击 Add，先添加这个 ReaFir 插件。
图2 – 添加 ReaFir 插件
在弹出的窗口中，选择 Cockos（Reaper的公司名字），然后选择 ReaFir。
点击OK，你就会在上面图2中看到 ReaFir，一般会出现在已有插件的下方，需要用鼠标拖动到最上面去，排在其他的效果器前面。至于为什么要挂在最前面，K酱解释的很好：
任何降噪插件，都建议挂在干声轨的第一个位置，ReaFir 也不例外。
为什么呢？比如你在降噪插件之前挂了个EQ，你采样过的噪声特征是经过EQ处理了的，后来你又重新调了一下EQ，然后新的噪声特征就跟采样到的特征不一样了，降噪效果就下降了。再比如你在降噪之前挂了个压缩，底噪部分电平比较低，达不到压缩器的 threshold，采样到的噪声特征是未经压缩处理的，人声的部分被压缩了，噪声的电平也变小了，这样再用采样到的特征去降噪，可能会降噪太多导致失真。总之，请把 ReaFir 放在效果链的第一位。另外，如果你在采样完之后，需要调整干声的音量大小（拖动干声对象上边缘，不是音轨上的推子），那么你需要在调整完之后重新采样。
然后双击 ReaFir，可以打开主界面。降噪这个功能需要设置 Mode 为 Substract，其他参数按照下图调整，经验上是效果比较好的。
接下来就是采样的步骤。首先在上图选中 Automatically build nosie profile，再选中一段嘉宾没有说话的部分，因为我们要对噪音采样。我们是每个人录制一段音轨，后期合成的播客制作方式，所以找一段没有说话的部分是非常简单的。最后点击循环和播放（下图最上的按钮），其实只播放一遍的话也足够啦。
播放之后，你就会看见这里的红色曲线会变化，最终稳定。这就是对噪音的采样啦。
最后一步，就是生成反向声波进行降噪。其实就是将嘉宾的声轨减去这段噪音的 profile。做法其实很简单，就是取消 Automatically build nosie profile 就可以啦。Done！选取一段嘉宾说话的声音，对比一下和之前的区别吧，底噪应该好很多了的。
底噪降的太强，会减去人声，造成音质损失；底噪降的太弱，会降噪不够。所以在上图中，降噪的强度是可以调节的。在这个界面中，按住 Command 键（Windows系统是 Ctrl 键），用鼠标拖动红色线可以调节降噪的强度。可以循环播放一段嘉宾说话的音频，一边播放一边调整，找一个合适的位置。
如果还看不懂的话可以看下这个视频教程：https://www.youtube.com/watch?v=31phzT7pxkk 我就是看这个视频学会的。
广告时间~
这里的（傻瓜）降噪教程就结束啦，如果有问题可以留言问我。我和 Luke 录制的这一期应该就会在最近发布啦，我们聊的是 CI，flake8，lint 等话题。大家在我们的网站关注我们 http://pythonhunter.org/ ，可以通过泛用型客户端订阅我们的播客。
如果喜欢我们的节目，可以给我们捐赠一些钱，我们会用来购买话筒，邮寄给嘉宾，嘉宾用完之后给嘉宾报销邮费收回话筒，购买剪辑软件，制作周边回馈听众等用途，我们会尽最大努力保证节目的质量和音频质量~
捐赠在爱发电：https://afdian.net/@pythonhunter 支付宝和微信可以直接扫码付款。