在你家公司使用 Django Migrate

Posted on by 2 Comments

Django 自带一个成熟的 ORM，提供了数据库结构迁移的功能。通过两个命令可以很方便地执行表结构更新：

  1. python manage.py makemigrations 生成迁移的 Python 脚本；
  2. python manage.py migrate 将脚本转换成 SQL 来执行，并在数据库保存已经执行过的 migrations；

但是这种方便的方法在大公司基本上都没办法直接使用，因为一般是不允许直接让你从笔记本去使用具有 ALTER 权限的数据库用户连接数据库的。有些公司是有在线的平台，只能通过平台提交数据库变更，有些是只能 DBA 来执行数据库变更。

在这种情况下我们就无法使用 Django 自带的 migrations 的功能了。那么有哪些可选的替代方案呢？

第一种是自己手写 SQL 建表，来对应代码的结构声明。之前公司在 Java 中的方案就是这种，有很多弊端。ORM 很多时候都有 length 之类的定义，这种手动对应很容易让两边不同步，没有那边是 source of the truth. 不过好像大家的忍受能力比较高，比较喜欢这种手工工作。

第二种是直接使用声明式编程。意思就是你只要声明你需要什么 table 就可以了。其实 Django 的方案就可以认为是一种声明式的。不过“声明式数据迁移”的本质是语言无关的，你写两张 create table，这个工具就可以产生从 table 1 迁移到 table 2 的 alter SQL. 不过我只听说过，没有见过落地的这种工具。

退一步，有 1st1 的公司 EdgeDB 和 Prisma 实现了一种通过 DSL 来完成的声明式，思想和 Django 是差不多的，声明式的数据库结构迁移。

第三种，就是只适用于 Django 的方案。Django 自带了一个命令，sqlmigrate, 可以从 migrations 的文件生成 SQL 语句。

但是，还有一个问题是怎么知道哪些 migrations 执行过了，哪些没有执行过。

在原生的 Django 方案中，这个问题是通过在数据库的一张表存储 migration 的文件名来解决的。

我们也可以通过命令查询。

在每次进行 python manage.py migrate 命令的时候，Django 就去查询数据哪些 migrations 是已经完成了的，然后只执行没有执行的。

由于无法直接连接生产环境的数据库，我们就需要其他的方法来找到没有执行的 migrations.

这里我使用的方法是通过代码来记录：

  1. 部署的时候，通过和上一次代码的 diff, 就可以找到新生成的 migrations, 执行这些 migrations;
  2. 每次部署代码，都执行所有没有执行过的 migrations;

这样，migrations 代码就可以作为 source of the truth.

步骤如下：

  1. 先通过 git 命令找出改动的 migrations 文件；
  2. 处理文件名，解析成 app migration 的格式；
  3. 通过 sqlmigrate 命令生成 SQL，以及回滚的 SQL；
  4. 得到 SQL 执行文件，去执行。

这个流程应该在多数的公司都可以行得通了。

使用 Makefile 可以写成以下的脚本：

执行的效果：

生成的数据库文件如下：

几点要注意的事情：

  1. 以前我习惯通过 migrations 来做数据迁移，但是现在这种形式显然是无法为数据迁移生成 SQL 的。所以数据迁移只能通过 SQL 来做了。不过问题也不大，我写 SQL 的功力已经提高了，大部分的逻辑都可以通过 SQL 写出来；
  2. 注意 database constrains 的问题。Django 要有办法为 contrains 命名，所以原则上要提供一个数据连接让 Django 知道现在有哪些 contrains 存在了。我们是禁用了外键约束的，如果你用的话，要注意名字的重复问题。

This requires an active database connection, which it will use to resolve constraint names; this means you must generate the SQL against a copy of the database you wish to later apply it on.

doc

 

好了，到此为止，就可以愉快地使用 Django 了。

 

Docker (容器) 的原理

Posted on by 33 Comments

第一次接触 docker 的人可能都会对它感到神奇，一行 docker run，就能创建出来一个类似虚拟机的隔离环境，里面的依赖都是 reproduceable 的！然而这里面并没有什么魔法，有人说 Docker 并没有发明什么新的技术。确实是，它只不过是将一些 Linux 已经有的功能集合在一起，提供了一个简单的 UI 来创建“容器”。

这篇文章用来介绍容器的原理。

什么是一个容器？我们从容器的标准开始说起。

一、OCI Specification

OCI 现在是容器的事实标准，它规定了两部分的标准：

  1. Image spec：容器如何打包
  2. Runtime spec：容器如何运行

Image Spec

容器的运行时是通过 Image 创建的，Image Spec 规定了这个 Image 里面要放什么文件。本质上，一个 Image 就是一个 tar 包。里面一般包含这些内容：

manifest 里面包含 config 和 layers，其中 config 包含以下内容的配置：

  1. 创建运行时(container)的时候需要的配置；
  2. layers的配置
  3. image 的 metadata

layers 就是组成 rootfs 的一些文件。base 层的 layer 有所有的文件，之后的 layer 只保存基于 base 层的 changes。在创建容器的时候需要打开这个 Image，先找到 base layer，然后将之后的 layer 一个一个地 apply changes，得到最后的 rootfs。

我们可以下载一个 Nginx 的 Docker Image 来看下里面都有什么。

首先 pull 下来 docker 的 image，然后将它保存为一个 tar 文件。

然后再把它解压开：

然后使用 tree 命令看下里面的结构：

打开 manifest.json 就会发现里面标注了 config 文件，以及 layers 的信息，config 里面有每一层 layer 的信息。

如果解压 layer.tar，就可以看到里面用于构建 rootfs 的一些文件了。

容器运行的时候，就依赖这些文件，而不依赖 host 系统上的依赖。这样就做到和 host 上面的依赖隔离。

Runtime Spec

从 Image 解包之后，我们就可以创建 container 了，大体的过程就是创建一个 container 然后在 container 中运行进程。因为有了 Image 里面的依赖，容器里面就可以不依赖系统的任何依赖。

容器的生命周期如下：

Image, Container 和 Process

  1. Containers 从 Image 创建，一个 Image 可以创建多个 contaners
  2. 但是在 Container 作出修改之后，也可以直接将里面的内容保存为新的 Image
  3. 进程运行在 Container 里面

实现和生态

runc 是 OCI 的标准实现。Docker 是在之上包装了 daemon 和 cli。

Kubernetes 为了实现可替换的容器运行时实现，定义了 CRI (Container Runtime Interface)，现在的实现有 cri-containerd 和 cri-o 等，但是都是基于 oci/runc 的。

所以后文中使用 runc 来解释容器用到的一些技术。

2. 进程之间的隔离

如果没有 namepsace 的话，就不会有 docker 了。在容器里面，一个进程只能看到同一个容器下面的其他进程(pid)，就是用 namespace 实现的。

namespace 有很多种，比如 pid namespace, mount namespace。先来通过例子说 pid namespace。

运行 runc

要运行一个 runc 的容器，首先需要一个符合 OCI Spec 的 bundle。我们可以直接通过 docker 创建这样的一个 bundle。

首先我们创建一个目录来运行我们的 runc，在里面需要创建一个 rootfs 目录。然后用 docker 下载一个 busybox 的 image 输出到 rootfs 中。

然后运行 runc spec ，这个命令会创建一个 config.json 作为默认的配置文件。

进入到 containers 文件夹，就可以运行 runc 了（需要 root 权限）。

查看 namespace

容器只是在 host 机器上的一个普通进程而已。我们可以通过 perf-tools 里面的 execsnoop 来查看容器进程在 host 上面的 pid。execsnoop 顾名思义，可以 snoop Linux 的 exec 调用。

我们退出刚才的 runc 容器，先打开 execsnoop，然后在另一个窗口中在开启容器。会发现 host 上有了新的进程。

新的进程的 pid 是 92528.

可以使用 ps 程序查看这个 pid 的 pid namespace.

可以看到在宿主机这个进程的 pidns 是 4026534092。

这个命令只显示了 pid namespace, 我们可以通过 /proc 文件系统查看这个进程其他的 pidns.

使用 cinf 工具，可以查看这个 namespace 更详细的内容。

可以看到这个 ns 下面只有一个进程。

到这里可以得出结论，当我们启动一个新的容器的时候，一系列的 namespace 会自动创建，init 进程会被放到这个 namespace 下面：

  • 一个进程只能看到同一个 namespace 下面的其他进程
  • 在容器里面 pid=1 的进程，在 host 上只是一个普通进程

docker/runc exec

那么当我们执行 exec 的时候发生了什么呢？

运行 runc exec xyxy /bin/top -b ，从 execsnoop 中可以看到 pid：

直接使用 runc 的 ps 命令也可以看到 pid，但是 pid 会和 execsnoop 显示的命令不一样：

在运行原来的 cinf 命令查看这个 namespace:

可以看到现在这个 namespace 下面有两个进程了。

在 runc 的容器里面我们去看 top，会发现有两个进程，它们的 pid 分别是 1 和 13，这就是 namespace 的作用。

3. cgroups

Namespaces 可以控制进程在 container 中可以看到什么（隔离），而 cgroups 可以控制进程可以使用的资源（资源）。

我们可以使用 lscgroup 查看现在系统上的 cgroup, 然后将它保存到一个文件中

然后使用 runc run xyxy 启动一个名字叫 xyxy 的容器，再次查看 cgroup：

可以看到容器创建之后系统上多了一些 cgroup，并且它们的 parent 目录是我们的 sh 所在的 cgroup.

cgroup 可以控制进程所能使用的内存，cpu 等资源。

在容器的 cgroup 中也可以加入更多的进程。

首先使用 runc 查看一下进程的 pid：

然后查看这个 cgroup 下面有哪些进程：

发现只有这一个。

下面通过容器的 exec 命令加入一个新的进程到这个 cgroup 中：

然后再次查看是否有新的 cgroup 生成：

输出为空，说明没有新的 cgroup 生成。

然后通过查看原来的 cgroup，可以确认新的进程 top 被加入到了原来的 cgroup 中。

总结：当一个新的 container 创建的时候，容器会为每种资源创建一个 cgroup 来限制容器可以使用的资源。

那么如何通过 cgroup 来对资源限制呢？

默认情况下的容器是不限制资源的，比如说内存，默认情况下是 9223372036854771712：

要限制一个容器使用的内存大小，只需要将限制写入到这个文件里面去就可以了：

内存是一个非弹性的资源，不像是 CPU 和 IO，如果资源压力很大，程序不会直接退出，可能会运行慢一些，然后再资源缓解的时候恢复。对于内存来说，如果程序无法申请出来需要的内存的话，就会直接退出（或者 pause，取决于 memory.oom_control 的设置）。

上面这种修改 cgroup 限制的方法，其实就是 runc 在做的事情。但是使用 runc 我们不应该直接去改 cgroup，而是应该修改 config.json ，然后 runc 帮我们去配置 cgroup。

修改方法是在 linux.resources 下面添加：

然后 runc 启动之后可以查看 cgroup 限制。

我们可以验证 runc 的资源限制是通过 cgroup 来实现的，通过修改内存限制到一个很小的值（比如10000）让容器无法启动而报错：

从错误日志可以看到，cgroup 的限制文件无法写入。可以确认底层就是 cgroup.

4. Linux Capabilities

Capabilities 也是 Linux 提供的功能，可以在用户有 root 权限的同时，限制 root 使用某些权限。

先准备好一个容器，带有 Libcap，这里我们还是直接使用 docker 安装好然后导出。

然后将这个 docker 容器导出到 runc 的 rootfs:

最后生成一个 spec：

然后进入到容器里面验证，会发现在容器里面无法修改 hostname，即使已经是 root 了也不行：

这是因为，修改 hostname 需要 CAP_SYS_ADMIN 权限，即使是 root 也需要。

我们可以将 CAP_SYS_ADMIN 加入到 init 进程的 capabilities 的 bounding permitted effective list 中。

修改 capabilities 为以下内容：

然后重新开启一个容器进去测试，发现就可以修改 hostname 了。

查看 Capability

要使用 pscap ，首先要安装 libcap-ng-utils，然后可以查看刚刚打开的那两个容器的 capabilities:

可以看到一个有 sys_admin ，一个没有。

除了修改 config.json 来添加 capabilities，也可以在 exec 的时候直接通过命令行参数 --cap 来要求 additional caps.

在容器中，可以通过 capsh 命令查看 capability:

可看到 Current 和 Bounding 里面有 cap_sys_admin。+ep 的意思是它们也在 effective 和 permitted 中。

5. 文件系统的隔离

在容器中只能看到容器里面的文件，而不能看到 host 上面的文件（不map的情况下），做到了隔离。

Linux 使用 tree 的形式组织文件系统，最底层叫做 rootfs, 一般由发行版提供，mount 到 / 。然后其他的文件系统 mount 到 / 下面。比如，可以将一个外部的 USB 设备 mount 到  /data 下面。

mount(2)是用来 mount 文件的系统的 syscall。当系统启动的时候，init 进程就会做一些初始化的 mount。

所有的进程都有自己的 mount table，但是大多数情况下都指向了同一个地方，init process 的 mount table。

但是其实可以从 parent 进程继承过来之后，再做一些改变。这样只会影响到它自己。这就是 mount namespace。如果 mount namespace 下面有任何进程修改了 mount table，其他的进程也会受到影响。所以当你在shell mount 一个 usb 设备的时候，GUI 的 file explorer 也会看到这个设备。

Mount Namespace

一般来说应用在启动的时候不会修改 mount namespace. 比如现在在我的虚拟机中，就有以下的 mount namespace:

现在启动一个 container，可以看到有了新的 mount namespace：

在 host 进程上查看 mount info：

可以看到这个进程的 / mount 到了 /dev/mapper/vagrant-root 上。

在 host 机器上，查看 mount，会发现这个设备同样 mount 在了 / 上。

所以这里就有了问题：为什么 container 的 rootfs 会和 host 的 rootfs 是一样的呢？这是否意味着 contianer 能读写 host 的文件了呢？contianer 的 rootfs 不应该是 runc 的 pwd 里面的 rootfs 吗？

我们可以看下 container 里面的 / 到底是什么。

在 container 里面查看 / 的 inode number:

然后看下 Host 上运行 runc 所在的 pwd 下面的 rootfs：

可以看到，容器里面的 / 确实就是 host 上的 rootfs。

但是他们是怎么做到都 mount 到 /dev/mapper/vagrant-root 的呢？

这里的 “jail” 其实是 privot_root 提供的。它可以改变 process 的运行时的 rootfs. 相关代码可以查看这里。这个 idea 其实来自于 lxc。

chroot

要做到文件系统的隔离，其实并不一定需要创建一个新的 mount namespace 和 privot_root 来进行文件系统的隔离，可以直接使用 chroot(2) 来 jail 容器进程。chroot 并没有改变任何 mount table，它只是让进程的 / 看起来就是一个指定的目录。

关于 chroot 和 privot_root 的对比可以参考这里。

简单来说，privot_root 更加彻底和安全。

如果在 runc 使用 chroot，只需要将 {“type”:”mount”} 删掉即可。

也可以删掉这部分，这是为 privot_root 准备的。

然后创建一个新的容器，发现依然不能读写 rootfs 之外的东西。

Bind Mount

Linux 支持 bind mount. 就是可以将一个文件目录同时 mount 到多个地方。这样，我们就可以实现在 host 和 container 之间共享文件了。

在 config.json 中作出以下修改：

这样， host 上面的 /home/vagrant/test_cap/workspace_host 就会和容器中的 /my_workspace 同步了。可以在 host 上面执行：

然后在 container 里面：

Bind 不仅可以用来 mount host 的目录，还可以用来 mount host 上面的 device file。比如可以将 host 的 UBS 设备 mount 到 container 中。

Docker  Volume

Volume 是 docker 中的概念，OCI 中并没有定义。

本质上它仍然是一个 mount，可以理解为是 docker 帮你管理好这个 mount，你只要通过命令行告诉 docker 要 mount 的东西就好了。

6. User and root

User 和 permission 是 Linux 上面几乎最古老的权限系统了。工作原理简要如下：

  1. 系统有很多 users 和 groups
  2. 每个文件属于一个 owner 和一个 group
  3. 每一个进程属于一个 user 和多个 groups
  4. 结合以上三点，每一个文件都有一个 mode，标志了针对三种不同类型的进程的权限控制: owner, group 和 other.

注意 kernel 只关心 uid 和 guid，user name 和 group name 只是给用户看的。

执行容器内进程的 uid

config.json 文件中的 User 字段可以指定容器的进程以什么 uid 来运行，默认是 0，即 root。这个字段不是必须的，如果删去，依然是以 uid=0 运行。

在 host 上，uid 也是 0：

不推荐使用 root 来跑容器。但是好在默认我们的容器进程还受 capability 的限制。不像 host 的 root 一样有很多权限。

但是仍然推荐使用一个非 root 用户来运行容器的进程。通过修改 config.json 的 uid/guid 可以控制。

然后在容器中可以看到 uid 已经变成 1000 了。

在 host 上可以看到进程的 uid 已经不是 root 了：

创建容器的时候默认不会创建 user namespace。

使用 User namespace 进行 UID/GID mapping

接下来我们创建一个单独的 user namespace.

在开始之前我们先看下 host 上现有的 user namespace:

然后通过修改 config.json 来启用 user namespace. 首先在 namespaces 下面添加 user 来启用，然后添加一个 uid/guid mapping：

然后重新运行容器，再次查看 user namespace:

在容器里面，我们看到 uid=1000：

但是在 host 上，这个进程的 pid=2000：

这就是 uid/gid mapping 的作用，通过 /proc 文件也可以查看 mapping 的设置：

通过设置容器内的进程的 uid，我们就可以控制他们对于文件的权限。比如如果文件的 owner 是 root，我们可以通过设置 uid 来让容器内的进程不可读这个文件。

一般不推荐使用 root 运行容器的进程，如果一定要用的话，使用 user namespace 将它隔离出去。

在同一个容器内运行多个进程的场景中，也可以通过 user namespace 来单独控制容器内的进程。

7. 网络

在网络方面，OCI Runtime Spec 只做了创建和假如 network namespace, 其他的工作需要通过 hooks 完成，需要用户在容器的运行时的不同的阶段来进行自定义。

使用默认的 config.json ，就只有一个 loop device ，没有 eth0 ，所以也就不能连接到容器外面的网络。但是我们可以通过 netns 作为 hook 来提供网络。

首先，在宿主机上，下载 netns 到 /usr/local/bin 中。因为 hooks 在 host 中执行，所以这些 Binary 要放在 host 中而不是容器中，容器的 rootfs 不需要任何东西。

使用 netns 设置 bridge network

在 config.json 中作出如下修改，除了 hooks，还需要 CAP_NET_RAW  capability, 这样我们才可以在容器中使用 ping。

然后再启动一个新的容器。

可以看到除了 loop 之外，有了一个 eth0 device.

也可以 ping 了：

Bridge, Veth, Route and iptable/NAT

当一个 hook 创建的时候，container runtime 会将 container 的 state 传给 hook，包括 container的 pid, namespace 等。然后 hook（在这里就是 netns ）就会通过这个 pid 来找到 network namespace，然后 netns 会做以下几件事：

  1. 创建一个 linux bridge，默认的名字是 netns0 ，并且设置 MASQUERADE rule；
  2. 创建一个 veth pair，一端连接 netns0 ，另一端连接 container network namespace, 名字在 container 里面是 eth0;
  3. 给 container 里面的 eth0 分配一个 ip，然后设置 route table.

bridge and interfaces

netns0 创建的时候有两个 interfaces，名字是 netnsv0-$(containerPid)：（brctl 需要通过 apt install bridge-utils 安装）

netnsv0-8179 是 veth pair 其中的一个，连接 bridge，另一个 endpoint 是 container 中的。

vthe pair

在 host 中，netnsv0-8179 的 index 是7：

然后在 container 中，eth0 的 index 也是7.

所以可以确认容器里面的 eth0 和 host 的 netnsv0-8179 是一对 pair。

同理可以确认 netnsv0-10577 是和 container 10577 中的 eth0 是一对 pair。

到这里我们知道容器是如何和 host 通过 veth pair 搭建 bridge 的。有了 network interfaces，还需要 route table 和 iptables.

Route Table

container 里面的 routing table 如下：

可以看到所有的流量都从 eth0 到 gateway，eth0 的另一端是 netnsv0-8179，连接在 bridge netns0 上面：

在 host 上：

以及：

192.168.1.1 是 home route，一个真实的 bridge.

总结起来，ping 的时候，需要一出一进两条路有：

  1. 从 container 出去：包会从容器内，发到 virtual bridge netns ，发送到一个真正的 route gateway，然后到外网去。
  2. ping 包的回复，进入到 Host 中，会走第二条路由，发送到 netns0 ，然后根据 IP 进入到容器中。

这样，我们就可以从容器中 ping 通外面的地址了。但是还有一个问题：我们是用 172.19.0.0 这个地址段去 ping 的，假设同一个局域网内有两个电脑，分别运行 docker，那都使用默认的这个地址段，不就乱套了嘛？

iptable/nat

netns 做的另一个事情是设置 MASQUERADE，这样所有从 container 发出去的包（source是 172.19.0.0/16 ）都会被 NAT，这样外面只会看到这个包是从 host 来的，而不知道是否来自于一个 container，只能看到 host 的 IP。

 

至此，容器用到的一些技术基本上就讲完了。所以说容器本质上是使用 Linux 提供的一些技术来实现进程的隔离，对于 host 来说，它仍然只是一个普通的进程而已。

参考资料：

主要是一些 Linux 手册，以及最主要的，Bin Chen 的博客：Understand Container. 本文基本上是我在学习他的博客的笔记。

 

软件的分层

Posted on by 12 Comments

在关于软件的复杂度上， David J. Wheeler 说：

“We can solve any problem by introducing an extra level of indirection.”

在使用了一段时间的 React Hook 之后，对于分层有一些感触。可能在维护和管理规模较大的软件上，添加更多的抽象和分层是必不可少的。但是分层不一定会带来更多的复杂度，巧妙的设计可以让软件依然容易维护。

我发现设计好、接受度高的软件，代码倾向于让用户按照业务逻辑来组织，而不是按照框架的实现来组织。

比如 React Hooks，在没有它之前，在一个组件中，你要将所有的所有组件的 ComponentDidMount 放在一起，将 ComponentDidUpdate 放在一起。如果一个页面有 5 个组件构成，那么每一个组件都要分别写到两组里面去，如果涉及更多的状态管理，涉及同一个组件的状态管理将分散在更多的地方。

但是 Hooks，让你可以把通一个组件的状态、控制逻辑、渲染逻辑都放在通一个地方。

这就使得代码的阅读性和可维护性变得很好。

另外一个例子是 Django 框架组织代码的形式。Django 使用 app 来组织用户的代码，在每一个 app 里面都有 view model 等，控制这个 app 的内容。这样的好处有：这个 app 只管理这一部分的逻辑，与其他 app 的耦合性很低，“高内聚，低耦合”。

一开始接触这样的框架的时候比较不适应， 比如怎么划分 app，是一个经验问题。新手很容易将所有的内容都写到同一个 app 中，或者直接按照团队的分工来划分 app。但如果正确掌握了这种组织代码的形式的话，代码就的可维护性就会提高很多。

一个反例是蚂蚁的 SOFA 框架。以前的同事跟我说，“来蚂蚁就要学习 SOFA 的分层，学会了这个就掌握了精华了。” 使用这个框架写了一年多的代码，我还是无法理解其中的智慧。撇开启动速度长达三分钟、配置混乱并且难以理解这些问题不说。就说你要把代码写在哪一层这个问题，就会难倒很多新手。下面是一个新项目默认的分层结构，实际上随着项目的开发，层数会增加很多：

这样的设计默认了用户必须理解框架对每一层的设定。将项目变得难以管理，并且增加了很多工作量。比如对某一个 model 添加一个评论功能， 在 Django 中几乎是一小时就可以完成并上线的工作量， 在 SOFA 中可能需要几天的时间，在不同的层上添加逻辑。实际上大多数时候这些“层”什么都没有干，只不过是直接去调用下一层。

好的设计应该是 “make the easy things easy, and the hard things possible.” 显然，这种设计是让所有的事情都变得一样复杂。即使写一个 Hello World 出来，你用这个框架也需要创建出来一个庞然大物。

实话说，我在蚂蚁的这段工作经历，从开发体验上说，是非常痛苦的。包括框架启动慢、复杂并且混乱的配置，对 Java 语言的强绑定，缺少文档，代码难以测试（因为即使是本地开发也连接了很多其他服务）等等。

那么为什么会造成这种情况呢？我认为和组织形式有关。康威定律说“设计系统的架构受制于产生这些设计的组织的沟通结构。” 我认为可以再扩展一下，不光受制于沟通结构，和整个组织的政策都有很大关系。做一个事情的方案有很多种，可以使用一层抽象，也可以使用三层抽象，甚至可能有某种优雅的方法不添加额外的实体概念去实现。这不是一件简单地事情，需要极具经验的工程师才能做得很完美。然而假如 KPI 的压力太大，以及 KPI 只看结果贯彻地太好，那么怎么做就不会变的不重要，毕竟都可以达到一样的效果（但从某一个量化指标上来说），虽然可能会带来更大的理解成本，以及潜在的维护成本、沟通成本，甚至带来的稳定性隐患等。但是这不重要，KPI 怎么完成无所谓，只要完成了都一样。

另一个表现是晋升，一些公司像是封建社会一样有着森严的等级，某一等级的工程师只能做那一等级的事情，大家都想着向上晋升。但是很多晋升过去的人已经不写代码了，很多高等级的 SRE 工程师甚至都已经很久不使用终端了。这就导致在晋升的时候，这些高等级的工程师组成的评委团不会太过于注重技术方案。本来评审一个候选人的时候应该问 “为什么选择使用 A 而不使用方案 B？” “你这样做会有某某问题是如何解决的” “XX是怎么处理的”，由于无法理解技术所以只能问出这种问题：

你发这个的底层逻辑是什么？顶层设计在哪里？最终交付价值是什么？过程的抓手在哪里？如何保证结果的闭环？能否赋能产品生态？你比别人发的亮点在哪？优势在哪？我没有看到你的沉淀和思考，你有形成自己的方法论吗？你得让别人清楚，凭什么发这个的人是你，换别人来发不一样吗？

或许觉得这是网友的调侃，但是在当你确确实实要在晋升的时候去想破头思考这些问题该怎么回答的时候，就不那么好笑了。

在这种环境下，像是压测、限流、熔断、容灾等等方案，只要去做肯定是可以完成的，但是你可以因为这件事带来非常大的改造成本，造成严重的开发效率问题，搞出来很多让开发人员难以理解的概念，和蹩脚的设计，也可以做的很漂亮。虽然对于将来评价你的评委来说，这并没有很大的不同。甚至你因为设计的拙劣带来了很大的改造成本，却又给你带来了更多的工作量，加班卖力的完成，于是又成了一个可以被人称道的点，可以凸显你的推动能力、领导能力，这是评委们非常喜欢的能力。虽然本质上只是给大家带来了一堆麻烦而已。

另外，这种晋升机制又会让大家去强行给自己加活。通常的套路表现为：找出开源软件中的一两个毛病，然后以此为借口声称这无法满足我们公司的需要，所以需要“自研”一套，然后“自研”的软件解决了自己当初找到的那几个毛病，成功获得晋升。而实际上，自研的东西可能又带来了成百个其他的问题，但除了给使用者造成了痛苦之外，倒没有什么问题，因为还有其他人虎视眈眈地想再重新研发一次，替换掉你这个项目呢。

如此对技术的不够重视，加上繁杂的会议积压开发时间，工期紧，导致大部分的工程师不会有时间去思考设计、分层的问题了。虽然有时候停下来思考可能带来更多的收益，但是弥漫在焦虑中很难停得下来。我在这种环境中也写出了不少垃圾。在这种情况下，人们就越倾向于使用自己非常熟悉的技术，不愿意学习新的东西，因为这会减少自己工作中的麻烦。懒惰地使用分层和抽象解决问题，导致软件越来越复杂。声称 Java 才是适合“企业级”应用的最佳解决方案，实际上只是懒得思考和设计。毕竟，现在的事情已经够多了，我们应该把更多的时间放在“顶层设计”，思考“业务价值”上，技术方面，只要实现了就好，怎么实现的，没有人关心。我觉得这也就是为什么蚂蚁的很多人将很多东西做成了自己熟悉的系统的样子，比如很多中间件经过内部的修改变得只支持 Java，如果你在蚂蚁使用除了 Java 之外的语言几乎是难上加难（2020年）；比如很多写过交易系统人去写一个逻辑非常简单的东西都会分成7层来写，甚至类的名字会使用交易系统的概念来明令，XXOrder，XXTransaction；比如听说 Python 实现东西很快，但是会把 Python 去写成 Java 的样子。

说了这么多，需要提醒一下读者的是，这并不能代表蚂蚁所有的技术，甚至有人会觉得 SOFA 非常成功，给无数小微企业带去了收益。总之，只是我自己的想法而已，如果我很喜欢蚂蚁的研发环境，我也不会离开蚂蚁。也可能是我天生愚钝，无法理解里面的大智慧吧。

复杂是很简单的，简单是很困难的。好的软件需要很多年的持续耕耘才行，一边做一遍思考，从自己现在做的事情开始，一点一滴，随着时间慢慢积累才行。

最后给读者推荐我比较喜欢的一个视频吧，John 讲的 A Philosophy of Software Design | John Ousterhout | Talks at Google 。以及他的书：A Philosophy of Software Design .

2021年06月15日更新：

一点想法。有关 web 框架，好的框架都是从简单的开始，随着项目的发展，逐渐变得越来越复杂，比如说 Flask，项目开始的时候可能就是一个文件，用户可以根据需要，引入依赖，拆分模块。虽然有些框架采用了不一样的哲学，比如 Django, React, 但是一开始脚手架生成的框架总是简单的。不好的框架，一开始就会给你生成大量的代码，即使你要完成一个很简单的功能，也要给你分个七八层，引入几十个依赖。记得以前有一次公司让领导亲手用我们自己的框架写一个 Hello World 类似的东西，领导们写了一整天，搞的满头大汗。

 

我在新加坡一个月的生活费明细

Posted on by 8 Comments

来新加坡之后经常被很多朋友咨询在这边的生活水平如何，一个月会花多少钱。2020 年在世界房价前 5 名中新加坡的房价占据第三，生活水平成本占据第四。这会吓到很多想来新加坡工作的朋友。这些数字相对于个体来说可能反应不了什么，比如是否开车、从事什么职业，年收入多少，这些对于生活成本都会有不同的理解。

本博客的读者可能都是和我一样的程序员，所以我想我个人的数据对于读者来说可能具有更大的意义。

我一直有用 Beancount 记录账目的习惯，因为一月份我购买了很多家具，以及花了一些中介费（半个月的房租）、酒店费用等用来安顿下来，所以可能没有什么参考价值。二月份的开销相对稳定，所以可以在这里分享一下自己的账目。以供大家参考。

2月份一共花费 3797.18 SGD。其实不全是日常的生活费用，但是为了真实，我也记录一下这些额外支出吧。以下用一个缩进列表描述每项的花费内容。以下货币都使用 SGD，汇率可以按照 1SGD=4.85CNY 来计算。

3797.18

  • 1536.79 住房
    • 1400 房租
    • 25 宽带
    • 86.89 水电煤气
  • 89 衣服
    • 在新加坡只穿的到 T 恤，所以穿衣方面是很便宜的。我2月份只买了一双 Vans 的经典款的板鞋，比国内的电商略贵一些
  • 1413.6 其他
    • 18 银行续费：往国内汇了一笔钱，使用的汇款公司每笔汇款收取固定手续费18新币
    • 83 去迪卡侬买了一些游泳装备，迪卡侬的价格跟国内基本一致
    • 2.6 和同事去公共泳池游泳，每次 1.3 新币，很便宜
    • 1310 情人节给老婆买了个包，奢侈品的价格比国内便宜很多，可以直接参考官网
  • 755.79 日常生活
    • 678.84 吃饭
      • 200.49 年夜饭
        • 新年请大家来我家吃火锅，买的东西比较多，导致我们从七点钟吃了一晚上，吃到第二天4点，聊得很 high……
      • 478.35 日常吃饭
    • 76.95 交通
      • 13.50 打 Grab 出租车（其实公司 2.2 大促还打了两次，不过公司报销了，不记录了），大约5公里，打车还是比较贵的
      • 61.65 日常通勤坐公交车

可以看到如果不算买的礼物的话，一个月正常的衣食住行大约是 1万2 人民币左右。如果不算过年我们买了一些年货的话，1万人民币完全没有问题的。另外2月份好像出去吃饭的次数也比较多，看了下大约下馆子了十五六次……

费用解释

首先大头是房租，新加坡租房确实比较贵，我和朋友整租了一整套，可以理解成所有的费用我只支付了一半。比如宽带实际是 50/月，等。这个价格的房子在市中心的区域，去乌节路只需要20min左右，去公司15min左右。楼下就是地铁站（<30m）超市（<50m），带有游泳池，健身房，公共休息室，桑拿室，网球场等，住在30楼，楼前面无遮挡，能看到半个新加坡，视野非常好。所以如果要比的话，同样的价格在上海市租不到这种房子的，也没有贵的离谱。之前跟银行的经理聊过，他们5个人租的 HDB，每个人400新币。HDB 是新加坡为了实现“人人有房住”的住房项目，有很多优惠政策给真正需要房子的人，比如你买 HDB 有 N 年内不能出售，收入限制，名额限制等。如果有资格买的话，首付比上海要低太多，月供基本无压力。HDB 的缺点是没有泳池等设施，小区没有围墙。但是这些问题都不大，新加坡的公共泳池有很多，也很方便。

然后是交通，交通是比较贵的，公交做一次新币要 1元起，算成人民币要五六块了。但是没啥办法，太热了，不想走路。

吃饭。这个是很便宜的，因为新加坡的食阁到处都是，类似于大学时候的那种食堂，平均 5 新币一餐。但是偶尔要出去改善一下的话，就确实比较贵了。按照菜单价格点完菜之后要加收 10% 的服务费和 7% 的消费税。注意并不是✖️1.17，而是 x 1.1 x 1.07，即 x 1.177。

这是我截取的一段日常账本：

 

写油猴脚本的传统艺能（Tampermonkey）- 教程

Posted on by 3 Comments

如果你在一家大公司工作，十有八九要面对百十个内部的所谓“自研系统”——大部分体验都非常拉跨。自研 SCM 的，自研 Ticket 系统的，自研文档系统的，还有一些很神奇的、搞不懂明明有很好的开源系统为啥不用偏要自研的系统。

不管出于什么原因，我们的大公司自研了这些系统，他们无一都有着一个共同点：体验很糟糕。包括：使用了先进的 SPA 技术但是 90% 的内部系统都没办法处理好 Url 的前进后退历史，翻页过滤等保持状态，甚至很多系统干脆就只有一个 URL: 比如 xdb.alipay.com…… 好吧，我猜这些都是专业团队开发的，专业领域比较强但是缺一个“专业前端”吧。

在这种环境中生存，尤其是作为一个“专业”的 SRE，我们就需要一些传统艺能：Python 爬虫，浏览器模拟器爬虫，油猴脚本。帮助你在各种险恶的内部系统中存活。

本文试图用 30 分钟（请现在开始计时）学会写油猴脚本，希望能在你快乐的 SRE 生涯中每天节约你几分钟的时间。

首先，先介绍下油猴脚本是什么（如果你真的不知道的话，我感谢你读到现在还没有走）：油猴，Tampermonkey，是一个 Chrome 插件。我们都知道，JavaScript 本质上是客户端，就是运行在客户这边的软件。那么当客户这边的软件用着不爽的时候，客户是不是可以直接去修改软件呢？毕竟 JavaScript 也是脚本语言。当然可以！客户就是你，油猴就是帮助你修改 JavaScript 页面的软件。

油猴运行的方式是，你可以写一个 JavaScript 脚本，然后指定在什么 URL 运行，当你用浏览器打开这个 URL 的时候，油猴就会运行你的 JavaScript。这样，我们就可以把这些拉跨的网站变成我们想要的样子。

接下来我们安装油猴插件，Chrome 搜索安装即可。

安装好之后，我们来写你的第一个油猴脚本。

题目如下：你（其实是我自己）用 Roam Research 来记录工作笔记，你的公司用 JIRA 作为工单系统。每次你在处理一个工单的时候，你希望把这些过程都记录下来。比如你处理一个 URL 是 https://jira.mycompany.io/browse/IT-25582 的工单的时候，你想以下面的形式开始在 Roam Research 里面做记录： [[Ticket/IT-25582: Fix Alice's Computer]] ( https://jira.mycompany.io/browse/IT-25582 ) #IT #Computer #Alice。现在你是怎么做的呢？你要复制 Url，复制标题，复制工单编号，然后复制标签，最后在 Roam 里面打出来这句话。2分钟过去了……

所以我们希望能够一键做这个事情。效果是在“分享”按钮的后边会有一个一键复制的按钮，按下这个按钮，就会自动在你的剪切板插入这段格式的文本。然后你只要去 Roam 里面粘贴就可以了。

原理是：

  1. 从页面中使用 JavaScript 拿到标题，Url，标签等，拼出来要粘贴的内容
  2. 然后在页面上找一个合适的地方，加上我们的 Copy as Roam 的按钮
  3. 最后加一个监听的函数，这个按钮按一下，就把这段拼出来的文本放到剪切板里面去

首先，第一步，我们从页面找拿标题。这一步没什么难的，就是使用 JavaScript 的 API document.querySelector() 把想要的东西都拿出来即可。然后拼成一段文本。

然后，第二步，操作剪切板的函数（咦？不是加按钮吗？那太难了，待会在搞）。操作剪切板现在已经有 API 可以直接操作了。在这里我们需要搞一个假的 textArea, 然后把文字填进去，复制到剪切板。

最后一步，添加一个按钮。听起来这应嘎是最简单地一步，只要找到一个 Element 然后 Append 就好了，但确实最难的。因为现代网页用 JavaScript 太多了，你要找的 Element 也许根本就不存在。

解决方法是使用一个循环，延迟这个操作，一旦发现元素，则停止循环。

还有一个难点，因为 SPA 都是编译出来的，所以很可能整个网页都没有什么 id 可以用，如果有，它们的值也是每次编译自动生成的。这很头疼，我也没想到什么好办法，只能祝你好运了。

另外添加元素的时候，可以不比写自己的 CSS，直接 Copy 一下旁边的按钮的 class 用就好了，可以完美地混入其中。

油猴的原理大致就是这样，如果你要做的事情，八成就要去看浏览器提供了什么样的 API 了。大部分情况也不必自己从头开始写，一般有人做过类似的事情了，可以直接去搜索一下现成的脚本改一改。比如我这个教程，其实源代码就是抄了别人的。只不过我觉得他写的太繁琐了，就改了一些内容。

PS：量子幽灵 提醒我可以使用 MutationObserver 这个 API，这个 API 可以直接在某个 DOM 出现的时候去调用一个回调函数。

 

完整的脚本如下，贴在这里也没法直接用，但是相似的事情可以基于这个改一改。