将它拆开来看，工具是 “工” 与 “具” 的结合。这是一个理解我们所创造的一切的强大模型。

工​

工 - 工作、劳动、技巧、能力、标准

它不是指那个物件本身，而是指使用物件所要达成的“事”或所蕴含的“巧”。

它强调 功能。

具​

具 - 器物、器具

它强调的是一个实际存在的、有形的、可以被掌握和使用的物件。

它强调 具象化。

工具​

没有“工”，只有“具”：那就是一堆没有意义的原材料。一块石头、一根木头，在没有被赋予“砸开坚果”或“支撑重物”这些“功能”之前，它们只是自然物，而不是工具。

没有“具”，只有“工”：那就是一个无法实现的想法或概念。我想“更快地移动”，这个“功能”需求是存在的，但直到有人发明了轮子、马车、自行车、汽车这些“具象化”的载体，这个功能才得以实现。

工具 = 工 + 具 = 用 + 体

• 工 - 功能 - 灵魂
• 具 - 载体 - 肉体

当我们说“创造一个工具”时，我们不仅仅是在制造一个物件，更是在为某个特定的功能寻找最佳的具象化方案。

研发与工具​

后端是“工” - 应用程序的引擎、大脑和骨架。它负责

• 核心逻辑
• 数据管理
• 安全认证
• 算法与服务

但这一切对于终端用户来说，都是不可见、不可直接感知的。它拥有强大的潜在能力，就像一个装备了顶级发动机和精密传动系统的裸露底盘。它能跑，但你没法开。

前端是“具” - 应用程序的外观、界面和交互。

• 信息呈现
• 用户交互
• 用户体验

前端将后端那些抽象的、基于数据的“功能”，转化为了用户可以看见、点击、触摸的具体形态。它为那个强大的引擎装上了方向盘、仪表盘、座椅和漂亮的外壳，让一个普通人也能驾驭它。

API - 连接“工”与“具”的契约 - 血脉

用户价值实现​

“Accessable”（可触达/可用性）在很多时候比功能本身更重要。

“Accessible”本身不是结果，但它是通往结果的唯一桥梁。一个无法被用户触达、理解和使用的功能，其结果等于零。

用户获得的最终结果 = 核心功能(工)的潜在价值 × 可用性(具)的实现程度

“Accessable”

• 它是价值的“最后一公里”
• 它定义了目标用户
• 在功能同质化的世界里，它本身就是核心竞争力

只有被用户“Accessable”地体验到的那部分功能，才构成了真正的“有效结果”。

举例来说

• 潜在结果： 后端实现了100个功能。这是理论上的、潜在的价值。
• 有效结果： 用户因为界面友好、引导清晰，最终只使用了其中最重要的10个功能，并解决了他们的问题。这10个功能带来的价值，才是“有效结果”。

• “工”决定了一个工具的价值上限，它能走多高、多远。
• “具”则决定了这个价值上限中有多少能够被实际交付给用户，它决定了工具能走多宽、多广。

在一个追求极致功能和性能的“工程师思维”里，“工”是核心。 但在一个以用户为中心的“产品思维”里，确保“工”的价值能通过“具”顺畅地传递出去，才是通往成功的关键。

工与具 = Function and Interface​

• 工 = Function
  • 它关乎“为什么”和“做什么” (Why & What it does)。
  • 它是内在的逻辑、目的、能力、过程。
  • 在软件中，它就是后端逻辑、算法、数据处理、业务规则。
  • 它是工具的灵魂和价值核心，但本身是抽象的、不可见的。
• 具 = Interface
  • 它关乎“是什么”和“怎么用” (What it is & How to use it)。
  • 它是外在的形态、载体、交互点、呈现方式。
  • 在软件中，它就是图形用户界面(GUI)、应用程序编程接口(API)、命令行(CLI)。
  • 在硬件中，它就是产品的外观、按钮、屏幕。
  • 它是功能的身体和表达形式，是连接用户和功能的唯一桥梁。

Function and Interface​

• 好界面 + 好功能 = 理想的产品。 价值最大化。
• 坏界面 + 好功能 = 璞玉，但难以触及。
• 好界面 + 坏功能 = 金玉其外，败絮其中。
• 坏界面 + 坏功能 = 电子垃圾。

“用户界面”不是结果

• 用户要的结果不是“点击一个支付按钮”，而是“成功买到一件商品”。
• 用户要的结果不是“看到一个漂亮的图表”，而是“理解了这个月开支的变化趋势”。

但从用户的感知和体验来看，“用户界面”就是他们能体验到的那个“结果”的全部。

例如一个餐厅

• 最终结果是： 一次满意而饱足的用餐体验。
• 核心功能 (工) 是： 厨师烹饪出的美味菜肴。
• 用户界面 (具) 是： 餐厅的装修、菜单的设计、服务员的态度、餐具的摆放、菜品的呈现方式（摆盘）。

你不能“吃”菜单和服务员，你最终吃的是菜。但如果菜单模糊不清、服务员态度恶劣、环境嘈杂脏乱，那么即使菜本身再好吃，你获得的“结果”（用餐体验）也是糟糕的。

反过来说，如果整个“界面”体验极佳，它甚至能提升你对菜品（功能）的评价。

用户界面不是结果本身，但它是对结果的封装 (Packaging) 和呈现 (Presentation)。 在用户的主观世界里，这个封装和呈现的好坏，直接定义了他们所获得的最终结果的质量。

一个功能（工）无论多好，都必须通过界面（具）这个唯一的通道才能抵达用户。在这个传递过程中，界面既是守门人，又是放大器。

• 守门人： 决定了用户能不能、愿不愿进来体验核心功能。
• 放大器： 决定了核心功能的价值是被增强了，还是被削弱了。

结论​

• 创造一个好的工具，本质上就是为卓越的“功能”寻找最恰当的“界面”。
• 无论是代码、产品，还是一个团队、一套流程，这个“工与具”的思维模型都同样适用。它是创造与设计的核心。

回忆里模糊的片段，没有前因的后果，没有起承的转合，甚至连当初跌宕的起伏，心潮的澎湃都已经平静。

只剩下片段，仍旧有一些脸庞。

剩下的，就像是故事的注脚，没有主角但似乎又是牵连的一系列故事。

一直以来的我主张是活在当下。

但回忆美妙的是，能从一个第三者的视角，去重新审视那些曾经发生的故事。

但早已忘记是怎么开始的，不过，索性是有个合适的结尾。

开始的故事​

时间回到初中时代，新鲜和无聊的信息充斥着每天重复的生活。

而这个男孩有个简单的期盼：每天能看到她。

女孩很喜欢笑，这应该是男孩记忆最深刻的部分。她的笑容像是阳光，能照亮整个教室。

男孩很傻，只希望能尽量靠近她，即便是什么都没能说。

男孩很傻，只希望能和她坐在一起，即便是什么都不可能做。

男孩很傻，只希望能和她一起放学，即便是什么都不可能聊。

但唯一能做的，只能是每天看到她，则已经很满足了。

男孩总是喜欢自持矜持，也或许她并不会主动。

一天天这样过这，从未想过故事会有转折，只需要这样的美好生活一直延续，不，这对他来说就是美好的。

原来，他从来没在脑子里出现过喜欢两个字，因为他从来没想过要拥有她。

原来，他从来没意识到，或许他曾经喜欢过她。

原来，他真的很傻，但这却很美好。

他说他从来没有后悔，美好是需要回头看才能发现的。

原来，他真的很傻。

要点

• 拿到 password
  • 可能内置了
    • META-INF/.classes/org.springframework.config.Pass
  • 可能需要通过外部方式获取
    • 命令行参数或者环境变量或者拦截 Class 加载
  • 总的来说比较容易获取
• 将 jar 添加到 classpath - 方便直接调用 net.roseboy.classfinal 内内容
  • 通过 IDE 或者通过命令行参数
• 解压 jar 到当前 目录 tmp
• 解密 class
• 反编译得到 java
• 添加 lib 目录到 classpath
• 通过 IDEA 可直接调用原始 jar 里内容或直接启动 Application
  • 可能需要修改反编译后的 java 文件 - 部分反编译语法错误

package main;

import net.roseboy.classfinal.JarDecryptor;
import net.roseboy.classfinal.util.EncryptUtils;
import net.roseboy.classfinal.util.StrUtils;

import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class DecryptClassFinal {
    public static void main(String[] args) throws IOException {
        String src =System.getProperty("user.dir") +  "/tmp/META-INF/.classes";
        String dst = System.getProperty("user.dir") + "/src/main/class";

        File srcDir = new File(src);
        JarDecryptor.getInstance();
        // 默认 password 位置
        String pass = Files.readString(Path.of(src+"/org.springframework.config.Pass"));
        char[] password =  EncryptUtils.md5(pass.toCharArray());

        System.out.printf("src:%s\n", src);
        System.out.printf("dst:%s\n", dst);
        System.out.printf("password:%s\n", pass);

        if (srcDir.isDirectory()) {
            for (File file : srcDir.listFiles()) {
                String fp = file.getName();
                if (fp.startsWith("org.springframework")) {
                    continue;
                }

                byte[] fileBytes = Files.readAllBytes(file.toPath());
                byte[] out = dec(password, fp, fileBytes);

                String[] split = fp.split("[.]");
                String fn = split[split.length-1];

                String p = dst+"/"+ fp.substring(0, fp.lastIndexOf('.')).replaceAll("[.]", "/");
                new File(p).mkdirs();
                String f = p+"/"+ fn +".class";

                System.out.println("Write to: "+f+" Len:"+out.length);
                Files.write(new File(f).toPath(), out);
            }
        }

    }

    public static byte[] dec(char[] password, String fileName, byte[] bytes){
        char[] pass;
        pass = StrUtils.merger(new char[][]{password, fileName.toCharArray()});
        return  EncryptUtils.de(bytes, pass, 1);
    }
}

运行 main 后 src/main/class 目录下会生成解密后的 class 文件。

# 假设是 macOS 安装的 IDEA
# IDEA 自带的反编译工具解密即可
java -cp ~/Applications/IntelliJ\ IDEA\ Ultimate.app/Contents/plugins/java-decompiler/lib/java-decompiler.jar \
  org.jetbrains.java.decompiler.main.decompiler.ConsoleDecompiler \
  -dgs=true \
  src/main/class/ src/main/java/

执行后 src/main/java 目录下会生成反编译后的 java 文件。

如何用记笔记来索引知识​

2022-07-21 的一些思考

1. 工作 是重复的任务 - Job is recurring work
2. 经验 是解决重复问题的方案 - Experience is solution for recurring situation
3. 知识 是重用经验 - Knowledge is about reusing experience
4. 记笔记 是重用获取知识的时间 - Noting is about reusing time used to acquire the knowledge

要完成任务，只需了解一点点知识。知识是积累、演变和时间的结果，由小片段组成。条条大路通罗马，你必须找到自己的那条。

通过记笔记，首先做一组标记，然后深入挖掘，最终形成一个知识池。

索引知识

• 大脑容量有限（字面意义上的）
• 索引是为了直达重点
• 重点如：列表、表格、代码 这样的表现方式
• 记录内容是关于：上下文、背景、原因、关系、为什么、注意事项 等

重点可能非常简单，例如 Next.js 不支持 ESM，这就足够做出决策。 但如果你想了解更多，你将花费更多时间得出结论，是的，它还没准备好，但是...。

不要浪费5分钟选择技术，使用你已经足够了解的无聊技术。

Thoughts

• 体系结构和设计 - 选择是关键，你最好了解它们。
• 不要在同一块石头上绊倒两次。
• 记笔记是为了自己，写文章和博客是为了别人阅读。
• 记笔记可以释放大脑压力，就像将思维分散到另一个地方。

记笔记是思考的反映，就像散点图，索引将其变成有向图，这是我们建模知识的方式。 写作就像绘画，试图在说服你一个观点，这个观点在在标题或第一段中已经提出，其余的文字都是在证明“我早就告诉过你了”。

• Linode
  • 32 GB + RTX6000 GPU x1 + 8C 32GB
    • $1000/mo,$1.50/hr
  • 只有 eu-center 地区，太慢太慢了
• GCP
  • NVIDIA Tesla L4 + 4 vCPU + 16 GB
    • US$598.46/mo, US$0.82/hr
  • 有亚太地区 - 台湾

GCP Deep Learning VM​

• 存储至少 100 GB+
  • 3854 张图片，缓存为 .npy
• 基于 Debian 11 和 Ubuntu 22.04
• SSH 进入的时候会提示安装 driver
• 默认环境
  • conda
  • numpy
  • scipy
  • matplotlib
  • pandas
  • nltk
  • pillow
  • scikit-image
  • opencv-python
  • scikit-learn
  • CUDA, CuNN, NCCL
• https://cloud.google.com/deep-learning-vm/docs/introduction

sudo apt install -y neofetch ffmpeg libc-bin

# python 默认来自于 /opt/conda/bin/python
pip install --upgrade pip

# 确定环境驱动正常
cat /proc/driver/nvidia/version
nvidia-smi
sudo docker run --gpus all nvidia/cuda:12.5.0-base-ubuntu22.04 nvidia-smi

#
sudo apt install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev liblzma-dev git
#pip install nvidia-cublas-cu11 nvidia-cudnn-cu11

sudo apt install -y docker-buildx-plugin docker-compose-plugin

# ultralytics ->
# py-cpuinfo, mpmath, triton, sympy, opencv-python, nvidia-nvtx-cu12, nvidia-nvjitlink-cu12, nvidia-nccl-cu12, nvidia-curand-cu12, nvidia-cufft-cu12, nvidia-cuda-runtime-cu12, nvidia-cuda-nvrtc-cu12, nvidia-cuda-cupti-cu12, nvidia-cublas-cu12, nvidia-cusparse-cu12, nvidia-cudnn-cu12, nvidia-cusolver-cu12, torch, ultralytics-thop, torchvision, ultralytics

# better running in tmux
tmux new -A -s main

Could not load library libcudnn_cnn_train.so.8​

• /opt/conda/lib/python3.10/site-packages/nvidia/cudnn/lib/libcudnn_cnn_train.so.8
• /opt/conda/lib/python3.10/site-packages/torch/lib
• /usr/local/cuda/lib64

Could not load library libcudnn_cnn_train.so.8. Error: /usr/local/cuda/lib64/libcudnn_cnn_train.so.8: undefined symbol: _ZN5cudnn3cnn5infer22queryClusterPropertiesERPhS3_, version libcudnn_cnn_infer.so.8

ldd /opt/conda/lib/python3.10/site-packages/nvidia/cudnn/lib/libcudnn_cnn_train.so.8
ldd /usr/local/cuda/lib64/libcudnn_cnn_train.so.8

# 修改后就可以了
LD_LIBRARY_PATH=/opt/conda/lib/python3.10/site-packages/nvidia/cudnn/lib/:$LD_LIBRARY_PATH yolo

#LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/conda/lib/python3.10/site-packages/torch/lib

• https://github.com/pytorch/pytorch/issues/104591

Debian​

apt update
apt -y upgrade

apt install -y build-essential python3 python3-pip pipx htop curl wget git jq neofetch

# Components 增加 contrib non-free non-free-firmware
nano /etc/apt/sources.list.d/debian.sources
apt install -y firmware-misc-nonfree

#
apt install -y nvidia-detect nvidia-driver

# nvidia-cuda-toolkit - 非常大

nvidia-detect

# Docker Debian
# ====================
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

sudo apt-get -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Ubuntu​

• Ubuntu 22.04 LTS

apt update
apt -y upgrade

apt install -y build-essential python3 python3-pip pipx htop curl wget git jq neofetch
pipx ensurepath
#pipx install poetry
#curl https://pyenv.run | bash

# Nvdia Driver
# ====================
lspci -nn | grep -E -i "3d|display|vga"

# https://ubuntu.com/server/docs/nvidia-drivers-installation
# https://www.nvidia.com/download/index.aspx
# https://www.nvidia.com/Download/Find.aspx
# apt install -y ubuntu-drivers-common
# ubuntu-drivers list --gpgpu # 所有支持的 GPU
# ubuntu-drivers install # 自动检测安装所有驱动
# ubuntu-drivers install --gpgpu
# ubuntu-drivers install --gpgpu nvidia:535-server
# apt install nvidia-utils-535-server

# nvidia-utils-535-server
apt install -y nvidia-driver-535

# reboot # 重启后才能生效

nvidia-smi
cat /proc/driver/nvidia/version

#sudo add-apt-repository ppa:graphics-drivers/ppa
#sudo apt-get update

# Docker Ubuntu
# ====================
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

sudo apt-get -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Nvidia Container Toolkit
# ====================
# https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
    | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sed -i -e '/experimental/ s/^#//g' /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit nvidia-docker2

sudo systemctl restart docker

# 测试
# https://hub.docker.com/r/nvidia/cuda
sudo docker run --gpus all nvidia/cuda:12.5.0-base-ubuntu22.04 nvidia-smi

ENV​

# rclone for dataset sync
# ====================
curl -Lo /tmp/rclone.deb https://github.com/rclone/rclone/releases/download/v1.67.0/rclone-v1.67.0-linux-amd64.deb
sudo dpkg -i /tmp/rclone.deb
rclone --version

# Python
# ====================
python3 --version # 建议 3.9-3.11

sudo mkdir -p /data/ml
sudo chown -R $USER:$USER /data/ml
cd /data/ml

# YoloV10
# ====================
git clone https://github.com/THU-MIG/yolov10 /data/ml/yolov10
cd /data/ml/yolov10
python3 -m venv venv
source venv/bin/activate
pip3 install -r requirements.txt

# Yolo
# ====================
mkdir -p /data/ml/yolo
cd /data/ml/yolo
python3 -m venv venv
source venv/bin/activate
pip3 install openvino==2023.2 'datumaro[default]'
pip3 install ultralytics torch torchvision

# rclone for sync
# ====================
# 接受 FTP 上传 - 修改账号密码
rclone serve ftp --addr 0.0.0.0:18080 /data/ --user USER --pass PASS
# 同步 修改 IP、账号密码
# rclone sync /data/ds/ :ftp,host=127.0.0.1,port=18080,user=USER,pass=$(rclone obscure PASS):ds -P --stats-one-line --transfers 10 -M

• Nvdia Driver
  • NVIDIA RTX / Quadro Enterprise Driver Branch History for Windows

# for pyenv
apt install -y make build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev liblzma-dev git

pyenv install 3.9
cd /data/ml/yolov10
pyenv local 3.9

cat << 'EOF' >> ~/.bashrc
export PATH="$HOME/.pyenv/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
EOF
source ~/.bashrc

# 手动
export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

# 自动
# ~/.bashrc
eval "$(pyenv virtualenv-init -)"

nvtop​

curl -o nvtop -L https://github.com/Syllo/nvtop/releases/download/3.2.0/nvtop-3.2.0-x86_64.AppImage
chmod +x nvtop
./nvtop

from source

git clone https://github.com/Syllo/nvtop.git /data/gits/nvtop
cd /data/gits/nvtop
mkdir build
cd build
cmake ..
make
sudo make install

• https://github.com/Syllo/nvtop

FAQ

Non-monotonic DTS; previous: 22695088, current: 22695088; changing to 22695089. This may result in incorrect timestamps in the output file.​

ffmpeg -fflags +genpts -i input.flv -c copy -vsync 1 output.mp4

• flv -> mp4 出现
  • 实时视频流抖动导致
• DTS - Decoding Time Stamp

cache​

# clip gdown huggingface matplotlib pip torch
du -sh ~/.cache

Small. Simple. Secure.

Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.

Alpine Linux 是一个基于 musl libc 和 busybox, 面向安全, 轻量级的 Linux 发布版.

为什么​

small footprint, non-systemd, fast enough, good community, sane defaults.

阿里云、腾讯云、物理服务器、虚拟机、容器都适用 AlpineLinux.

1. 环境都一样，使用各方面熟悉，熟练
2. 小/快 - 阿里云 ECS 只需要上传一个 几十 MB 的镜像即可，从 0 安装只需要 3 分钟
3. 简单 - 可以由内而外的了解所有 alpine 细节，对于 debian 和 centos 我都做不到，因为太复杂
4. 跟上时代 - 内核 一般是最近的 lts，能快速利用上新的内核特性，比如现在 linux 内核支持 io_uring, ntfs
5. 快速更新 - 安全问题响应非常快 - 因为使用面非常广
6. 衍生业务集成系统 - 系统预装一些软件和服务 - 例如: k3sos

不适用场景

1. 机器学习 - ubuntu/debian 是最好的 - 最新 Linux 开始要集成 Nvidia 驱动，情况会有所好转，目前 Nvidia 官方尚未正式支持Alpine。
2. 商务用桌面系统 - 默认 xfce - 生态 和体验没有 ubuntu 好
3. 定制化嵌入式设备 - alpine 支持的 arch 远没有 debian 的多，如果 arch 支持可以考虑 alpine

Not Convinced?

• 轻量级
  • 最小安装 5MB
  • musl
  • openrc
• 部分包提供静态编译二进制，可在非 Alpine 环境使用
• 稳定滚动升级
  • 有稳定版和最新版
  • 每半年一个稳定版
  • 稳定版会维护两年
  • 可非常简便的升级
• 简单的包管理
  • APK 本地存储逻辑和结构非常简单
  • APK 仓库逻辑结构简单 - 不同于 deb/rpm
  • 包的构建也很简单 - abuild 能够在本地构建包
• 现代化
  • 内核版本较新
    • 能够利用上很多新内核的功能
  • 包版本比较新
    • 例如 zfs, docker 等都是对应版本的最新版
• 生态圈丰富
  • 包非常多
  • 兼容良好
  • 社区活跃
• 支持较多平台
  • x86_64
  • x86
  • aarch64
  • armhf
  • ppc64le
  • s390x
  • armv7
  • riscv64
• 支持树莓派
• 很多 docker 镜像基于 AlpineLinux
  • Docker For Mac 的基础系统是 AlpineLinux

Alpine 的缺点​

• 文档不够全面
  • Wiki 内容较少, 更新不多
  • 但大多文档可参考 Arch 和 Gentoo
• musl libc 可能有兼容问题, 有时候需要补丁
  • 但越来越多的开发者也都会做兼容了
  • 常见的 Musl 问题

使用过程常见问题​

# 建议安装基础包，对新人使用相对友好
apk add curl busybox-extras file nano libc6-compat gcompat bash

• 使用 Alpine 的常见问题
• 制作各种 Docker 可参考 wenerme/dockerfiles
• 针对 Alpine 的各种 Ansible 任务 wenerme/ansible-collection-wenerme-alpine

1. 路由器上配置 DNS 为局域网内的一个节点
2. 路由器上配置 路由 172.32.1.1 到内网的一个 IP
3. DNS 匹配需要代理的路由返回 172.32.1.1
4. 172.32.1.1 上部署 sni 代理，监听 80、443

前置条件

• 已有相关代理服务

后置条件

• 修改路由器配置

应用场景

• 家庭
  • 无感
• 服务器运维 - 云服务器、物理服务器
  • 无感
  • 能支持任意场景
• 公司局域网
  • 能限制范围

手动配置节点​

ip addr add 172.32.1.1/32 dev eth0 # 增加 IP

# 安装部署 gost - 提供 SNI 代理
# ===============
curl -LO https://github.com/go-gost/gost/releases/download/v3.0.0-rc8/gost_3.0.0-rc8_linux_amd64.tar.gz
tar zxvf gost*.tar.gz
# 监听 80, 443 - 上游代理为 192.168.1.2:7890，如果在当前节点也可以 127.0.0.1:7890
./gost -L sni://:80 -L sni://:443 -F socks5://192.168.1.2:7890
# 测试 gost 代理是否成功
curl -H 'Host: google.com' 127.0.0.1

# 安装部署 dnsmasq
# ===============
apk add dnsmasq
# 上游配置
cat << EOF > /etc/dnsmasq.d/main.conf
server=223.5.5.5
log-queries=extra
EOF

# 配置代理常用的域名
curl -L https://ghproxy.com/raw.githubusercontent.com/wenerme/wener/master/notes/service/dns/gfwlist.txt \
  | sed -E 's#.+#address=/&/172.32.1.1#' > /etc/dnsmasq.d/gfwlist.conf

# 测试启动
dnsmasq -d
# 测试，返回 172.32.1.1 为正常结果
nslookup google.com 127.0.0.1

# service dnsmasq start # 服务启动
# rc-update add dnsmasq # 开机自动启动

• 配置路由器
  • DNS
  • 路由 172.32.1.1 到内网节点

Docker 启动服务​

# --network=host or -p 80:80 -p 443:443 -p 53:53/udp
# -e FAKEIP=172.32.1.1
docker run --rm -it -e PROXY=socks5://192.168.66.1:7890 -p 80:80 -p 443:443 -p 53:53/udp --name proxy wener/sni-rev-proxy

nslookup google.com 127.0.0.1
curl --resolve google.com:80:127.0.0.1 google.com

# 添加 FAKEIP
ip addr add 172.32.1.1/32 dev eth0

• 配置路由器
  • DNS
  • 路由 172.32.1.1 到内网节点

FAQ

无法修改路由器​

本地使用直接修改 resolv.conf 或者 hosts

nameserver 127.0.0.1

• 使用部署 DNS 的节点 IP

172.32.1.1 docker.io
172.32.1.1 registry-1.docker.io

• 直接映射单个域名
• 注意： CNAME 的域名也需要映射

为什么用 172.32.1.1​

• 172.32.1.1 为公网 IP 地址，但这个地址被使用的概率非常低
• 如果不给代理节点一个公网地址而是使用内网地址，那么 iOS 访问网络时会提示 “是否允许应用访问本地网络”。

为什么选择 DNS+SNI 作为全局代理​

• 客户端无感，不需要改任何配置
• 能实现全局 - 例如 docker 不需要就行配置，k8s 不需要就行配置 就能拉取镜像
• 代理范围易于控制 - DNS 层控制

能不能不限制域名所有都代理​

• 可以，dnsmasq 默认全部返回固定 ip
• 确保上游代理支持策略控制即可，例如 clash

关于上游 DNS​

• 可以选择公共的，例如 223.5.5.5
• 也可以选择自己部署的 adguard 之类的
  • 支持拦截隐私相关域名
  • 避免 DNS 污染

其他无感全局代理的方式​

1. 修改网关，tproxy - 无感，但是重新部署 dhcp，替代路由作为网关
2. 在 WiFi+Lan 的节点上，将 WiFi 配置为走代理，连 WiFi 则走代理，增加一个 lan 不修改现有。

• Recover Synology from AlpineLinux
• btrfs report I/O Error

问题​

群晖的盘搞的很复杂

• mdraid -> lvm -> btrfs

只看到 btrfs 报错（I/O Error），无法使用，没看到具体的磁盘错误，只能逐级排查。

主要目的是挂载 btrfs 恢复数据。

操作​

file -s /dev/sda1 # linux_raid_member
file -s /dev/sda2 # swap
file -s /dev/sda3 # 发现是用的 mdadm RAID 6
# /dev/sda3: Linux Software RAID version 1.2 (1) UUID= name=DF:2 level=6 disks=4

apk add mdadm

mdadm --examine --scan  # 扫描
mdadm --assemble --scan # 添加
cat /proc/mdstat        # 状态

file -s /dev/md127 # 发现是 LVM
# /dev/md127: LVM2 PV (Linux Logical Volume Manager), UUID: , size: 11980386729984

挂载 LVM

apk add lvm2

pvscan
# PV /dev/md127   VG vg1             lvm2 [<10.90 TiB / 604.00 MiB free]
vgscan
# Found volume group "vg1" using metadata type lvm2

lvdisplay
lvs
# /dev/vg1/syno_vg_reserved_area
# /dev/vg1/volume_1

vgchange -ay vg1 # 激活 vg1

file -s /dev/vg1/volume_1 # -> /dev/mapper/vg1-volume_1
file -s /dev/mapper/vg1-volume_1
# /dev/mapper/vg1-volume_1: BTRFS Filesystem label "2022.12.04-17:42:08 v42661", sectorsize 4096, nodesize 16384, leafsize 16384, UUID=, 151894196224/11979737530368 bytes used, 1 devices

挂载 btrfs

apk add btrfs-progs btrfs-progs-extra
modprobe btrfs

btrfs device scan
btrfs filesystem show

btrfs check /dev/mapper/vg1-volume_1 # 尝试检测

ERROR: errors found in fs roots
found 151884984320 bytes used, error(s) found
total csum bytes: 2896392
total tree bytes: 127860736
total fs tree bytes: 99958784
total extent tree bytes: 15761408
btree space waste bytes: 25632487
file data blocks allocated: 103613448192
 referenced 103061467136

• 发现不少问题

mount /dev/mapper/vg1-volume_1 /mnt # 尝试挂载
# wrong fs type, bad option, bad superblock on /dev/mapper/vg1-volume_1

dmesg # 内核日志找原因
# BTRFS critical (device dm-1): corrupt leaf

mount -t btrfs -o recovery,ro /dev/mapper/vg1-volume_1 /mnt

btrfs check /dev/mapper/vg1-volume_1 --repair # 尝试修复，但是失败
# ERROR: failed to repair root items: I/O error

btrfs scrub start -Bf /dev/mapper/vg1-volume_1
# btrfs rescue zero-log /dev/<device_name>

• smartctl 尝试检测硬盘问题
• mdadm 尝试 resync

无解, TODO

/dev/mapper/cachedev_0 on /volume1 type btrfs (rw,nodev,relatime,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,subvolid=256,subvol=/@syno)

wrong fs type, bad option, bad superblock on /dev/mapper/vg1-volume_1​

mount -t btrfs /dev/mapper/vg1-volume_1 /mnt

BTRFS: device label 2022.12.04-17:42:08 v42661 devid 1 transid 449145 /dev/mapper/vg1-volume_1 scanned by mount (4067)
BTRFS info (device dm-1): using crc32c (crc32c-intel) checksum algorithm
BTRFS info (device dm-1): using free space tree
BTRFS critical (device dm-1): corrupt leaf: root=1 block=668844032 slot=1, invalid root flags, have 0x400000000 expect mask 0x1000000000001
BTRFS error (device dm-1): read time tree block corruption detected on logical 668844032 mirror 1
BTRFS critical (device dm-1): corrupt leaf: root=1 block=668844032 slot=1, invalid root flags, have 0x400000000 expect mask 0x1000000000001
BTRFS error (device dm-1): read time tree block corruption detected on logical 668844032 mirror 2
BTRFS error (device dm-1): open_ctree failed

btrfs check /dev/mapper/vg1-volume_1 --repair

ERROR: failed to repair root items: I/O error

S.M.A.T Check​

apk add smartmontools

smartctl -t long /dev/sda
smartctl -t long /dev/sdb
smartctl -t long /dev/sdc
smartctl -t long /dev/sdd

# 很慢
smartctl -l selftest /dev/sda
smartctl -l selftest /dev/sdb
smartctl -l selftest /dev/sdc
smartctl -l selftest /dev/sdd

smartctl -a /dev/sda

LVM Check​

vgck vg1 -v
pvck /dev/md127

mdadm check​

4*10T SAS 需要跑 8h, iostat -> ~200MB/s

mdadm --detail /dev/md127
mdadm --action=check /dev/md127

# 查看有问题的块
watch cat /sys/block/md127/md/mismatch_cnt
# 查看进度
cat /proc/mdstat
cat /sys/block/md127/md/sync_action

md127: mismatch sector in range 713232-713240

echo idle > /sys/block/md127/md/sync_action # 停止 check
mdadm --action=repair /dev/md127            # 尝试修复 - repair=resync
iostat -h                                   # write 是有修复

# K/Sec
cat /proc/sys/dev/raid/speed_limit_max
sysctl dev.raid.speed_limit_max # 200000
sysctl dev.raid.speed_limit_max=2000000

# 不是平滑限速，而是平均 - 因此 resync 一会儿满速，一会儿 0
sysctl dev.raid.speed_limit_max=100000 # 如果觉得修复了问题，可以降低速度，然后尝试系统操作

• https://unix.stackexchange.com/a/531230/47774

BTRFS critical (device dm-1): corrupt leaf​

BTRFS error (device dm-1): read time tree block corruption detected on logical 668844032 mirror 2
BTRFS critical (device dm-1): corrupt leaf: root=1 block=668844032 slot=1, invalid root flags, have 0x400000000 expect mask 0x1000000000001
BTRFS error (device dm-1): read time tree block corruption detected on logical 668844032 mirror 1
BTRFS critical (device dm-1): corrupt leaf: root=1 block=668844032 slot=1, invalid root flags, have 0x400000000 expect mask 0x1000000000001
BTRFS error (device dm-1): read time tree block corruption detected on logical 668844032 mirror 2
BTRFS error (device dm-1): open_ctree failed

btrfs check /dev/mapper/vg1-volume_1 --repair

[1/7] checking root items
checksum verify failed on 711114752 wanted 0xed010ef2 found 0xb32e10d9
checksum verify failed on 711114752 wanted 0xed010ef2 found 0x3a406fa5
checksum verify failed on 711114752 wanted 0xed010ef2 found 0xb32e10d9
Csum didn't match
ERROR: failed to repair root items: I/O error

BTRFS: device label 2022.12.04-17:42:08 v42661 devid 1 transid 449145 /dev/mapper/vg1-volume_1 scanned by btrfs (22854)

btrfs backup​

apk add partclone

#btrfstune -u /dev/mapper/vg1-volume_1

https://manpages.debian.org/jessie/partclone/partclone.btrfs.8

noerror: Instructs dd to continue operation, ignoring all read errors sync: Instruct dd to fill input blocks with zeroes if there were any read errors

dd if=/dev/sda of=/dev/sdb1 bs=1MB conv=noerror,sync status=progress | gzip -c > backup.img.gz gunzip -c /PATH/TO/DRIVE/backup_image.img.gz | dd of=/dev/sda

LV Status NOT available​

是因为没有 active

vgchange -ay vg1

WARNING: PV /dev/md127 in VG vg1 is using an old PV header, modify the VG to update.​

不管

File descriptor 63 (pipe: 111755) leaked on pvck invocation.​

LVM_SUPPRESS_FD_WARNINGS=1 vgck vg1

参考​

• btrfs.8
• btrfs-check.8
• vgchange.8
• vgck.8
• md.4
• mdadm.8
• BTRFS: failed to read log tree
  • btrfs rescue zero-log /dev/<devicename>
  • https://www.suse.com/support/kb/doc/?id=000018761
• https://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html

clean up

apk del mdadm lvm2 btrfs-progs btrfs-progs-extra

每月节省 30¥ 阿里云全站 CDN 流量费用。

背景​

https://wener.tech 为国内备案域名，https://wener.me 为未备案域名，两个站点提供相同内容，数据都为 github pages

• wener.me https://github.com/wenerme/wener/tree/gh-pages
• wener.tech https://github.com/wenerme/wener.tech/tree/gh-pages
• https://charts.wener.tech https://github.com/wenerme/charts

因为一个 repo 只能有一个 CNAME，所以使用了两个。

在国内备案域名最省事的方式是放到国内云平台解析，迁出可能导致备案撤销，因此 wener.tech 使用了阿里云全站 CDN。

其中 charts.wener.tech 流量最大，因为加到一些 helm charts 的索引站里，且部署很多地方都用到了。 其中量最大的请求为 index.yaml ， 单个文件不小，请求次数高，每个月的全站 CDN 基本都花费在了 charts.wener.tech。

迁移​

每个月为 charts.wener.tech 流量付费也不是办法，因此打算迁移。

之前

import Mermaid from '@theme/Mermaid';

<Mermaid chart={graph TD charts.wener.tech --CNAME--> AliyunCDN AliyunCDN --> GitHubPages} />

之后

<Mermaid chart={graph TD charts.wener.tech -- CNAME --> fb.wener.me fb.wener.me --> ArgoTunnel --Kubernetes--> Nginx Nginx --> GitHubPages} />

因为 wener.tech 是在国内，因此只能使用 CNAME 方式到 cloudflare，cloudflare 支持为外部域名配置 ssl ，然后 fallback 到托管域名。

使用了 Nginx 作为反向代理缓存，尝试了 Varnish，但发现还是 Nginx 最为简单暴力。

GitHub Pages 有时候在国内也不一定能访问，加了本地缓存是最为保险的。

Note Why choose nginx as proxy cache.

Cloudflare 缓存命中问题

一开始缓存命中是很低的

因为 Cloudflare 基于 extension 缓存而不是 mime，且默认不缓存 html yaml 这种，在通过 Page Rule 添加全站缓存后，缓存命中率一下子就上去了。

就这样每个月节省了一小笔阿里云全站 CDN 流量费用。

穿透到 Nginx 的流量

v1​

• 后端 - Java - 2019.11 - 2021.01
• 前端 - NextJS v9 + Antd - 2019.11 - 2021.3
  • @reduxjs/toolkit

v2​

• 2020.01 - 2020.06
• 后端 - Node - nestjs
  • nestjs
  • objection - ORM
  • swagger
• 前端 - Antd v4+NextJS v9
  • react-final-form
  • redux
  • tinacms

v3​

• 后端 - Go - 2020.11 - 2022.07
  • gorm + restful - 前期
  • ent + gqlgen - 中期
  • gorm - 非核心 CRM 业务
• 前端 - 2020.11 - 2022.1
  • NextJS
  • BlueprintJS - 前期
  • graphql-codegen
  • urql - GraphQL
  • TailwindCSS - 后期
  • zustand - 后期
  • react-hook-form

v4​

• 2022.06 -> 2022.11
• 后端
  • 确定了要优先 GRPC，且使用标准 Schema。
    • 因此将 protobuf 的定义作为 Single-Source—Of—Truth Schema。
    • 分离接口 Schema 和 DB - 之前是 ent schema -> graphql schema
  • 虽然选择 GRPC 但也要直接能给前端访问
    • 选择了 connect 协议
    • 实现了 connect-gateway
      • 实现了基于 Redis 服务发现
      • 实现了基于 grpc reflection 自动暴露服务
  • DB 确定不要通过 ORM 自动维护而是手动维护
    • 实现基于 PG RLS 的多租户逻辑而非多 DB 模式
    • 实现 CRM 时 DB Schema 的重要性等同接口
    • 业务沉淀为数据库模型
    • 也因此分离 API 模型和数据库模型
  • Golang -> NodeJS
    • 初期尝试用 Golang 实现
    • 核心问题 ⚠️
      • 开发一段 前端再回到 Golang 会 痛不欲生 - 上下文切换、开发思路切换
      • Golang 生成代码只能静态生成，NodeJS 可以动态生成
        • NodeJS 更加灵活 - PoC 阶段更有优势
      • 使用 NodeJS 可以和前端在同一个仓库 - 核心逻辑开发维护更容易
  • NodeJS
    • fastify+jsonschema+sequelize
    • 通过 grpc 生成 descriptor, definitoon
    • 启动后通过 descriptor 生成 jsonschema
    • 通过 jsonschema+definitoon 生成 grpc-service - nice-grpc
    • 实现标准的 CRUD 语义
    • fastify POST -> grpc 实现 - 类似 connect 语义
    • grpc-server -> grpc 实现
    • 未来: web -> connect-gateway -> grpc-server -> grpc 实现
• 前端
  • daisyui+tailwindcss - 放弃 Blueprint
  • 不再直接选择成熟的 UI 框架，而是选择基于 CSS 的样式库
  • daisyui 提供了一套命名 class 的方式 - 有 Theme
  • 确定 管理功能优先于用户功能
  • 确定 功能能被看到才算开发完成
  • 模块化
    • 仍在尝试中 - 借鉴其他实现
    • 提供开放的 OSS 存储
    • 目前明确方向
      • 分离 os 逻辑和核心 route 逻辑 - 揉在一起困难

v5​

• 2022.11 -> 2023.03
• 方式的调整
  • 不只是独立于业务单纯的思考怎么做 CRM - 没有任何意义/产出的东西不可用
  • 业务层面将以前的思路以 DB Schema 的方式沉淀
  • 贴合现实做一些实际的事情
• 后端
  • RPC over NATS
    • 简单易用
    • 能实现多租户
  • 自定义 RPC
    • 弱 Schema - 一个人维护不过来
  • 重新定义分层
    • DB -> Entity -> EntityService -> RemoteService -> Controller, tRPC, GraphQL
    • 层次更多，但是更清晰
    • 改动相对独立，互不影响
  • 依然全面的 NodeJS/TS/NextJS/NestJS
  • 尝试更加轻量的服务 - HonoJS
  • 尝试更加轻量的前端 - Vite
    • 不能 SSR/SSG/Server Action
    • 添加多个页面相对麻烦
  • 尝试 Typescript 生成 zod/typebox - Single-Source-Of-Truth
• 前端
  • 大部分页面直接使用了 v4 的内容 - 逻辑结构上有一定调整
  • 证明 daisyui+tailwindcss 的移植性的确很好
  • 尝试引入了 shadcn
  • 核心功能能够做到模块化
  • 尝试重新恢复多窗口

v6​

• 2023.3 ->
• 基于 v5 大致内容不变的情况下调整以提升开发效率
• 主要调整内容
  • API 调整 - trpc -> GQL
  • 结构选型调整 - 轻量化, 开发效率优先
• 调整内容
  • Nats RPC + trpc -> GraphQL
    • trpc 内容多了过后类型推导太慢
    • GraphQL 直接对客户端保留
      • 避免要求通过 RPC+trpc 对客户端
      • 减少开发量
    • RPC 保留为对服务端
  • NextJS -> Vite - 纯静态前端 console
    • 开发反映要快得多
    • 现在的 NextJS 不适合做后台，不适合做太过动态的项目
    • Vite HMR 体验要好得多
  • fastify + NestJS Controller -> Hono
    • 保留 NestJS 作为 IoC 容器
    • Hono 简单容易维护
    • 缺点是 Hono OpenAPI 使用 zod-openapi
      • 没 NestJS Controller 那么好用
      • 但 可以 share schema 给前端 - 不过使用了 GraphQL Codegen 一般也不需要
  • GraphQL 使用 type-graphql+yoga+urql
  • 大量引入 mixin 来抽象业务逻辑
    • ORM 层 https://github.com/wenerme/wode/blob/main/packages/nestjs/src/entity/mixins/index.ts
    • GQL 层 https://github.com/wenerme/wode/blob/main/packages/nestjs/src/type-graphql/mixins/index.ts
  • Golang -> Bun
    • 将最后依赖 Golang 的 企业微信会话内容存档转为 Bun
    • bun:ffi 能很好的和 c interop
      • WeWorkFinanceClient.ts
• 领域开发
  • Follow 固定的 schema 模式 https://wener.me/notes/dev/design/schema
  • 逐渐固化大的业务框架 https://wener.me/notes/dev/design/erp
  • 逐步引入一些公共的业务逻辑
• 结果
  • 目前差不多的前后端部署了 3+ 套
  • 固化下来差不多的前后端框架
    • 前端 https://github.com/wenerme/wode/tree/main/packages/console
    • 后端 https://github.com/wenerme/wode/tree/main/packages/nestjs
  • 外部集成 https://github.com/wenerme/wode/tree/main/packages/client
• 接下来
  • 抽取更多公共业务逻辑
  • 引入更多业务域
  • 文件处理 - 类似网盘
  • 更多外部服务集成

不同的是，后者会倾注更多的时间、精力去完成作品。而要完成这样的作品又必须要有足够的阅历，知识经验积累，时间的沉淀。

• 生活
  • 封控期间重看了所有 MCU 电影
  • 看了部分 MCU TV - 惩罚者、夜魔侠
  • 通关 路易吉鬼屋、马里奥与疯兔
  • 天空剑 - 15h
  • 抢菜
    • 因为生活是夜猫子作息，大多能抢到 6 点那波 叮咚。
    • 通过设置 iOS 自动点，省力
      • 设置-通用-辅助功能-切换控制
      • 先录入要点的位置，然后连按 3 次 电源键 启用
      • 类似 宏
  • 咖啡戒断
    • 尝试不喝咖啡，3天后发生戒断反应，欲仙欲死
• 代码
  • 种子索引项目 wenerme/torrenti
    • 衍生代理项目 wenerme/proxc
  • 企业官网 - Strapi+NextJS
    • 衍生 Tiptap 编辑器 - 仿 Google Doc
  • Web3 DAO 前端项目
    • 学习 Web3 相关
    • 玩币 - 损失 500+

1. 文章编辑
2. 用户联系表单提交
3. 静态 - 利于 SEO

考虑

1. 是否需要自有域名
   • 没有自有域名可用平台提供的
   • 域名是必须的
2. 是否需要 HTTPS 证书
   • 可提供免费证书 - 涉及运维
   • 可买 - 云平台购买，需要定期更新维护
3. 是否需要备案
   • 未备案微信无法直接打开
   • 最简单的备案需要挂云服务商 - 服务器
   • 使用平台提供的域名可避免备案
4. 托管或自行提供服务器
   • 托管 - 平台提供服务器资源 - 使用平台带宽
   • 自行提供服务器 - 需要维护、定时付费
     • 一般免费 1mb 带宽（图片多会非常慢）

服从性实验，不停的挑战你的底线，或许拿准了这群人骨子里都是想着“顺着它们就好了”，这个底线越来越低。

谁都可以指着你的脸来教育你，只要它认为它是“对的”，规则都在嘴上，权利在无限放大，没有人觉得这有什么不对。 或许有人觉得不对，可是他们不被允许“发声”，我也不被允许“发声”。

简单的随声附和还不足以满足它们的“指导”欲望，它们希望你觉得意识到自己的错误，虽然你知道事实上并不是一个错误，但还是错了。 错在身在这个环境。

长辈觉得接受它们的“教育”、“指导”没有失去什么，但这本身就在一直失去，并且失去的越来越多。

当作为一个底层人/普通人，早已认识到自己无法改变任何事情，无法获取到更多，那么无论做或者不做什么都是在失去，失去自己，失去亲人，失去孩子的未来，就没那么想要继续去附和。 早一点解脱也算是一种逃避，需要勇气。放弃了对任何人负责，一点点的失去耐心，一点点的积累仇恨。

Tring to look the bright side, but in the dark room, there is no light.

A 同步到 B

DBA -> A -> B -> DBB

Extract -> Load

Extract -Transform-> Load

场景​

A,B,DBA,DBB 互通性

• 🟢 - 有可能 - A <-> B
• 🟡 - 也许可能 - 提供公有云数据库作为同步目标
• 🟠 - 不太可能
  • 如果是内部服务是可能的

模式​

• Push - 推 - A -> B
• Pull - 拉 - A <- B
• Reactive - A <-> B
• 第三方 - A -> X -> B

方式​

• 全量
• 增量
  • 基于增量游标
  • 基于 CDC 事件
• Schema+Data

实现方案​

• DBA -> A -> B -> DBB
  • B 暴露 API，A 请求 B - Push/Hook
  • 例如: WebHook
• DBA -> A <- B -> DBB
  • A 暴露 API，B 请求 A - Pull/Query
  • 例如: WebHook
• DBA -> A -> DBB
  • 例如: 配置同步目标给 A, A 直接写入
• DBA -> B -> DBB
  • 例如: RLS 暴露给 B 访问
• DBA <-> DBB
  • 例如: DB Link, Replication
• DBA -> A -> Queue -> B -> DBB
  • A,B 通过 Queue 交互 - A,B 都没有暴露接口
  • 被动
  • Queue 定位
    • 数据存储 - Kafka
    • 信息传输 - Redis, Nats - 例如 RPC over Redis Stream
• DBA -> X -> DBB
• DBA -> A -> X -> B -> DBB
  • 借助第三方服务 - 例如: AirByte, PgLoader
  • X 服务作为 中间服务 与 A,B 交互
    • 替代 Queue 角色
    • 主动
  • X 具有适配能力

Transform 考虑​

• 数据 Schema 适配
• 数据类型适配
• 过滤、转换、计算
• 通常包含逻辑
  • 逻辑 ~= Script
    • Lua, Python, JS
  • gRPC - 外部调用
• Transform 的复杂度决定了是 ETL 还是流处理
  • ETL - 简单适配、调整、元数据
  • 流处理 - 包含状态、依赖前后消息/Window、包含聚合
• 例如: Flink, SparkSQL, Storm、KafkaSQL

数据编码 考虑​

• 文本编码 - CSV,JSON,JSONL - 基础，丢失类型信息
• 二进制编码 - Avro, Parqute, Protobuf
• CBOR - Concise Binary Object Representation
  • 对比 JSON 能更好的保留类型信息
• Schema+Data - 数据更紧凑

物料​

• HP MicroServer 全新微塔 - 参考价格: ¥4000 , 功耗 60W
  • HP MicroServer Gen 10
    • 全新 AMD x3216 8G ¥2300
    • 最多 4 个硬盘
  • SAS 6T×4 - ¥1600
  • SAS 卡 - ¥100
• 二手塔式 - 参考价格: ¥4700 , 功耗 120W
  • DDR4 服务器 - ~¥2000
    • 1U 4×3.5 寸盘位
    • 2U 8×3.5 寸盘位
  • CPU XeonE5v4×2 ~¥1000 - 32 核 64 线程
  • 内存 DDR4 ECC REG 16G×4 - 64G ~¥1000
  • SAS 6T×4 - ¥1600
  • SAS 卡 - ¥100
• 星际蜗牛 J1900 - 参考价格: ¥2500 , 功耗 30W
  • 星际蜗牛 DDR3 J1900 8G ~ ¥800
  • SAS 6T×4 - ¥1600
  • SAS 卡 - ¥100
  • 非常入门款，没什么上升空间，没什么折腾的意义

部件参考价格​

主机选择​

• 机型选择
  • 微塔 - 噪音小，功耗一般 ~60w
    • 二手少 - 大多买新的，价格高
    • 体积小
    • 一般主板不支持 ECC REG 内存
  • 服务器 - 噪音大，功耗一般 ~120w
    • 二手多 - 便宜
    • 体积大 - 一般 1U
    • 扩展能力强 - 通常支持 一个半高+一个全高 PCI - 因此可以配 GPU
    • 如果没有书房、库房或隐瞒角落不推荐
    • 部分服务器噪音也不是特别大
• 平台选择
  • 通常二手都是落后好几个世代，但建议至少选择 DDR4
  • DDR3 价格是 DDR4 的一半 - 如果预算有限，那也是可以的
    • 选择 DDR3 CPU 也会便宜一半以上 - 是再上一个世代的平台
• 配置选择
  • 全新整套主机 - 包含 CPU+内存
    • 性价比不高，但省事
  • 二手服务器
    • 性价比最高，省事
    • 可选性不多
  • 自己配主机 - 主板+机箱+电源+CPU+内存
    • 事情最多，如果不是喜欢搞这个，建议不要
• 服务器选择
  • 架式
    • 二手市场最多，占地面积大
    • 1U
      • 8 个 2.5 寸盘位
      • 4 个 3.5 寸盘位
  • 塔式
    • 二手市场不多，占地面积大
    • 和普通台式电脑差不多
    • 服务器主板
  • 刀片
    • 二手市场很少
  • 模块
    • 二手市场不太多，占地面积很小
    • 魔改后的非常安静
• 成品 NAS 服务器
  • 群晖 - 不再这里的讨论范围内

配置目标​

通常配置个最低，后期能够调整组件即可

全新整套主机​

• hp microserver gen 10
  • AMD x3216 8G ¥2300
  • https://item.taobao.com/item.htm?id=564308249868#detail
• hp microserver gen 10 plus
  • 非常小巧
  • 需要海淘
  • ¥5000
• mineNAS 至强 微塔
  • Core 系列 CPU https://item.taobao.com/item.htm?id=546747046542
    • ¥3600
  • Xeon 系列 CPU https://item.taobao.com/item.htm?id=523041473305
    • ¥7500+

二手服务器​

• 架式
  • HP DL160G9 https://item.taobao.com/item.htm?id=564082577179
    • 准系统 ¥750
    • E5-4650V3*2 24 核 48 线 + 64G + Intel 800G SSD ¥3290
    • 8×2.5 寸盘位
  • DELL R430 X99 https://item.taobao.com/item.htm?id=567440742661
    • 准系统 ¥2200
    • 4×3.5 寸盘位
  • DELL R630 https://item.taobao.com/item.htm?id=557304169457
    • 准系统 ¥1449
    • 8×2.5 寸盘位
  • DELL R730 - https://item.taobao.com/item.htm?id=604846119404
    • 2U
    • 8-12 3.5 寸盘位, 8-24 2.5 寸盘位,
• 模块服务器
  • 广达 单模块即可
  • 改装后的非常安静
  • 价格 ~¥500
  • 注意 硬盘可能不太好放

装机​

• 主板
  • https://www.asrockrack.com/
    • 选择好后可淘二手
• 机箱
  • 确定好主板类型后决定
  • 小的情况可定制 亚克力 机箱
• 电源
  • 功耗 < 120W 时可考虑外置
  • 服务器功耗最好买 二手 服务器电源模块

系统​

1. 黑群晖

• 安装使用容易
• 现成的应用
• 适用于新手或不愿意折腾的玩家
• 相对封闭 - 不建议用服务器运行，可以考虑开虚拟机

2. Linux

Linux​

• AlpineLinux
• zfs
  • 看情况使用 raidz1,raidz2,draid
    • raidz1=raid5 - 4 盘时
    • raidz2=raid6 - 6 盘时
    • draid - >= 12 盘时
  • SSD 缓存 - 如果有预算
• 应用场景
  • 多媒体 - Jeylyfin, Plex, 照片, 音乐
  • 下载器 - aria2, qtorrent, transimision
  • 家庭 - Nextcloud
  • 共享 - samba, afp
  • 备份 - afp/TimeMachine
  • 常用应用 - vaultwarden
  • 服务器
    • Kubernetes/k3s - 推荐
    • Docker
    • 虚拟机

常见问题

如何选择硬盘缓存​

• 如果使用 ZFS+SSD 作为缓存，那硬盘的缓存影响不大
• 如果使用 硬件 RAID，那硬盘的缓存能提效

为什么选择 SAS 硬盘​

• SAS 为企业级硬盘 - 二手质量高
• 二手市场多
• 支持热插拔 - 更换容易
• 但 通常需要额外的 SAS 卡 - 一般选择半高 PCI
• SAS 还需要注意区分 2.5 和 3.5
  • 3.5 - 容量 300G-5T, 转速 7200+
  • 2.5 - 容量 120G-1T, 转速 10000-15000

如何选择 CPU​

• 志强 Xeon
  • 优点
    • 二手市场多
    • 价格便宜
    • 性能非常好 - 核心多
  • 缺点
    • 功耗高 - 120W
    • 需要主板支持
    • 一般媒体能力普通
    • 全新非常贵
• 志强 Xeon L
  • 优点
    • 功耗低 - 25W
  • 缺点
    • ECC NOREG
    • 通常内存只支持 2 通道 - 一般家用 NAS 足矣
• 酷睿 Core
  • 优点
    • 单核频率高
    • 媒体处理能力强
    • 功耗一般 - 60W
  • 缺点
    • 贵
    • 核心数少 - 作为服务器核心数比单核频率更重要
• 凌动 Celeron
  • 优点
    • 功耗非常低 - 10W
  • 缺点
    • 能力有限

服务器 和 PC/HTPC 的区别​

• 服务器通常支持管理模块
  • 启动慢
  • 支持远程远离 - 开机，停机，健康检查，KVM
  • 固件升级
• PC/HTPC 一般直接启动即可

It's HARD, but progressing.

Long way to go.

学习去学习，是这次学习开始老师讲的主题，因此也产生了自己的一些思考。 学习去学习，我认为是 meta-learning。学习，应该从未停止过，当我们从猴子开始，我们就在学习去熟悉、了解、掌握新的工具、环境、事物。

不需要学习的思考，是潜意识的提升。对学习过程进行思考归纳总结是，得到的是过程改进方式，因此两个人学习一天的结果会有所不同。

让给我联想到英语的两个单词，study & learn。study 强调的只是过程，learn 强调的是结果内容，应该思考平时学习是 study 还是 learn。

带思考的学习更容易获取一项技能知识。

管理​

管理，对我来说是一个 “全新” 的领域，作为技术研发，从未从管理学的概念去思考过问题。 但之所以是“全新”，是因为，生活无处不是管理，家庭纠纷、生活规划、日常工作。

我理解的管理，是控制。

控制理论的 反馈循环（feedbak loop） 图。

精益生产的 PDCA 循坏图。

项目管理 5 大过程组。

虽然是不同领域里的主题，但表达的却是相同的内容。

控制，减少变量，提升可预测性。

控制，是为了 提升/改进 现有过程。

What happened is happened,but what we can learn from the past ?

学习​

为了更好理解和管理自己的学习，我梳理了我的学习过程，希望能从无意识变成有意识的学习。

我的学习过程

• Repeat - 重复 - 抄写重复最为浅显的内容
• Refactor - 重构 - 按照自己的理解从新组织内容语言
• Realize - 从新意识 - 对照生活、工作、现实、跳出固化场景
• Regain - 从新获取 - 掌握

We learn from teacher.

Teacher teached us.

Whatever teaches us is our teacher.

老师、书本、文章、源码、事件都可能触发我们的“提升”。

Repeat

这时候我会进行简单的记录，好记性不如烂笔头。

在 https://github.com/wenerme/wener 这里我记录了感兴趣的很多内容，有的可能是工作相关的，例如：技术；可能是工作无关的，例如：医学。

• 浅显 - You get what you see
• 离散
• 精简 - 知识索引

Refactor

有时候，我们会重复遇到相同的问题，抱有相同的疑问，需要参考相同的话题。

此时参考简单记录的内容已经不足以回答或解决问题，因此，会对内容进行重新重构。

重构意味着重新梳理内容知识，从新调整“索引”内容，按照自己的“脑回路”对问题域进行理解分析。

使用 git 进行笔记的好处是它能记录你的“过程”。

Realize

意识阶段有两个方式：

1. 自身
2. 跨域

自身，我们通常讲从失败学习，更多的是意识到了问题点，问题点在不经历的时候是不会发现的，而当遇到问题，解决问题这个循环进行多次后，会基于基本的理论知识抽取出属于自己的经验结论。

跨域，学习和成长不可能是一条路走到头的，有所成就的人绝不可能只会精通一门学科，理解不同领域事物的相关性是意识提升的关键。

Regain

之所以叫 regain，是因为已经经历过早期的 gain 过程，regain 时，才是我们真正的有所掌握，学以致用。

这时候我愿称之为： 专家/Master。

思维模式​

通常学习分为两种场景：

1. 工具技术学习 - 实
2. 思想方法论学习 - 虚

因为我的主要职责是软件开发，管理对我来说是个“虚”技能，因为并不能直接指导工作。但对于项目经理来说，管理是个“实”技能，而计算机理论则是“虚”技能。

学习项目管理，是更多是为了去了解项目管理的思维模式。

项目管理思维模式 和 软件设计模式 非常相似，是当我们解决问题时的参照。

但当你没有这个参照，没有这把锤子时，就会陷入困境，不断重复错误。

学习主题​

学习是一个动作，必然会有目标，学习的主题可以是大而广的，也可以是小而精的。不如说，我们都需要把自己的知识储备磨练成 T 型结构。

不同的角度、观点都会让学习更加容易。

学习过程​

学习是持续的不是一次性的，没有时间限制，没有领域限制，没有思维限制。

学习的驱动却肯定是有根因的，每个人都有所不同。

We are who we are.

学习的参考不应该是别人，而是自己。今天的自己期望明天的自己对比昨天的自己能有所提升，而达成这样提升的就是学习。

现状​

使用 SanDisk CZ430 作为 系统盘/Root 分区

lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    1 114.6G  0 disk
├─sda1   8:1    1   128M  0 part /boot
└─sda2   8:2    1 114.4G  0 part /

df -h /

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       113G  2.2G  106G   2% /

在使用一段时间后， U 盘 异常，系统被重新挂载为只读。

touch ~/test

touch: cannot touch '/home/admin/test': Read-only file system

dmesg 可看到异常信息，几个月前已经出问题了，因为系统还能正常使用暂且没管。

[Tue Sep  7 16:48:16 2021] sd 2:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s
[Tue Sep  7 16:48:16 2021] sd 2:0:0:0: [sda] tag#0 Sense Key : 0x7 [current]
[Tue Sep  7 16:48:16 2021] sd 2:0:0:0: [sda] tag#0 ASC=0x27 ASCQ=0x0
[Tue Sep  7 16:48:16 2021] sd 2:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 00 00 04 16 90 00 00 08 00
[Tue Sep  7 16:48:16 2021] blk_update_request: critical target error, dev sda, sector 267920 op 0x1:(WRITE) flags 0x103000 phys_seg 1 prio class 0
[Tue Sep  7 16:48:16 2021] Buffer I/O error on dev sda2, logical block 466, lost async page write

备份恢复方案​

将现在数据完整备份到新的 U 盘，重启即可，但恢复备份有好几种方式。

1. 全盘 dd

• 速度慢
• 简单暴力
• 需要提供至少现在磁盘大小的存储

2. 重装 - 仅拷贝数据

• 麻烦

3. 恢复分区、恢复数据

• 高效
• 需要多一点操作
• 新磁盘只需要已用空间大小即可

恢复​

因为这是已经第三四次恢复了，之前都是 dd，但这次打算用更高效的方式，且这次的系统盘为 128G，但目前只有 64G 的空闲 U 盘，故选择方案 3。

恢复过程

0. 准备备份盘
1. 分区表备份 & 启动分区备份
2. root 分区 备份 & 修复
3. 验证
4. 关机
5. 取掉坏的 U 盘
6. 开机

准备备份盘​

• 备份盘 /dev/sdb 64G，同 SanDisk CZ430

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    1 114.6G  0 disk
├─sda1   8:1    1   128M  0 part /boot
└─sda2   8:2    1 114.4G  0 part /
sdb      8:16   1  57.3G  0 disk

分区表&启动分区备份​

# 确保使用 root 用户操作
sudo su
# 进入可写目录
cd /run

# 正常情况分区表的备份恢复
# sfdisk -d /dev/sda | sfdisk -f /dev/sdb

# 选择简单方式备份后再修改最后分区
# 这里 dd 130MB - 同时把 boot 分区备份了
dd if=/dev/sda of=/dev/sdb bs=1M count=130 status=progress

# 转储分区表
sfdisk -d /dev/sda > sda.partition.table.txt
# 删除第二个分区的大小
sed -r '$ s/size=\s*\d+,//' -i sda.partition.table.txt
# 重建分区
sfdisk -f /dev/sdb < sda.partition.table.txt
# 现在分区大小正常
fdisk -l /dev/sdb

# 分区变化重新扫描
mdev -s
partprobe
# 出现分区
ls /dev/sdb*

root 分区备份​

• root 分区一般较大，直接 dd 慢且伤 U 盘
• 直接 dd 需要目标相同大小，否则丢数据
• 这里使用 clone 数据方式

# ext4 数据拷贝 - 基于 ext4 block，只拷贝使用部分
# 也可以用于生成 img 备份镜像之后用
e2image -ra -p /dev/sda2 /dev/sdb2

因为 root 分区为 120G，但实际只用了 2.2G， 先镜像分区，缩小分区，然后恢复到新的分区。

索性内存有 4G，因此直接在 /dev/shm 操作，否则需要外置存储。

# 从新挂载为 3G - 默认 2G
mount -o remount,size=3G /dev/shm
# 制作镜像
e2image -rap /dev/sda2 sda2.raw

# 修复分区 - 一般 U盘 损坏都会导致 fs 异常
e2fsck -y sda2.raw
# 缩小分区
resize2fs sda2.raw 4G
# 恢复
e2image -rap sda2.raw /dev/sdb2
# 扩展分区
resize2fs /dev/sdb2

验证​

fsck /dev/sdb1
fsck /dev/sdb2

mount /dev/sdb2 /mnt
mount /dev/sdb1 /mnt/boot
# 不应该有变化
rsync -vna /boot/ /mnt/boot/

# 由于 fsck 修复，可能 root 分区大小不同
df / /mnt /boot /mnt/boot

如果装有 qemu，还可以直接启用 qemu 验证，目前就简单确认文件没问题即可。

# 准备关机重启
umount -R /mnt
eject /dev/sdb

poweroff

取掉 坏的 U 盘，启动。

一切恢复正常。🎉

总结​

系统盘恢复还是相当容易，但 CZ430 确实有点老了，在 2017 年左右上市，相同规格已经卖 4、5 年了，性能各方面有所欠缺，之后会尽量选择 Lexar S47。

• https://wener.me/notes/ops/admin/fio-out/
  • SanDisk CZ430, Lexar S47 性能对比

此外使用 U 盘 做系统盘的时候，一定注意修改 docker 之类的数据目录为其他存储，因为跑实际应用的时候 U 盘 性能是不足的，且数据库类型应用的小 BlockSize IO 不适合 U 盘。

索引选择问题​

假设结构如下

create table organizations(
  id bigserial primary key,
  jgmc text,
  clrq date
);

create index if not exists idx_organizations_clrq on ic.organizations (clrq);
create index if not exists idx_organizations_jgmc_fts on ic.organizations using pgroonga (jgmc);

查询通常基于 clrq 排序，但会 搜索 jgmc。

explain analyse verbose
select jgmc, clrq, id
from ic.organizations
where jgmc &@~ '百度'
  and clrq is not null
order by clrq desc
limit 30 offset 0
;

给出的执行计划和结果如下

Limit  (cost=0.43..33132.51 rows=30 width=1284) (actual time=4678.918..13104.109 rows=6 loops=1)
"  Output: jgmc, clrq, id"
  ->  Index Scan Backward using idx_organizations_clrq on ic.organizations  (cost=0.43..4069724.46 rows=3685 width=1284) (actual time=4678.916..13104.101 rows=6 loops=1)
"        Output: jgmc, clrq, id"
        Index Cond: (organizations.clrq IS NOT NULL)
        Filter: (organizations.jgmc &@~ '百度'::text)
        Rows Removed by Filter: 3685166
Planning Time: 0.826 ms
Execution Time: 13104.226 ms

实际执行了 13s，选择了 idx_organizations_clrq 索引。

但如果去掉 LIMIT：

explain analyse verbose
select jgmc, clrq, id
from ic.organizations
where jgmc &@~ '百度'
  and clrq is not null
order by clrq desc
-- limit 30 offset 0
;

给出的计划如下

Sort  (cost=40479.53..40488.74 rows=3685 width=1284) (actual time=19.771..19.774 rows=6 loops=1)
"  Output: jgmc, clrq, id"
  Sort Key: organizations.clrq DESC
  Sort Method: quicksort  Memory: 36kB
  ->  Index Scan using idx_organizations_jgmc_fts on ic.organizations  (cost=0.00..40261.24 rows=3685 width=1284) (actual time=19.716..19.737 rows=6 loops=1)
"        Output: jgmc, clrq, id"
        Index Cond: (organizations.jgmc &@~ '百度'::text)
        Filter: (organizations.clrq IS NOT NULL)
Planning Time: 0.706 ms
Execution Time: 21.824 ms

实际执行只需要 21ms，选择了 idx_organizations_jgmc_fts 索引。

PostgreSQL 在这样的场景下选择了错误的索引，导致查询时间相差 600 倍。

索引选择原因​

ORDER BY+LIMIT 让查询有 提前结束的可能。

例如 实际数据 10k,但 limit 10, 只需使用索引扫描 10 条数据便可以停止执行，而不需要先判断 其他 条件。

因此 PostgreSQL 的 optimizer 有让这种选择优先的逻辑 pathnode.c#L3633-L3753。

• create_limit_path 针对 LIMIT/OFFSET 创建执行计划
  • adjust_limit_rows_costs 调整此时的 rows costs

*total_cost = *startup_cost +
  (input_total_cost - input_startup_cost)
  * count_rows / input_rows;

在这个调整逻辑里会将现在的过程 cost input_total_cost - input_startup_cost 乘以 系数 count_rows / input_rows。 这个系数便会使得 ORDER BY+LIMIT 时优先选择索引。

因为两个计划的 rows 相同，优先了 排序索引则会选择排序索引方案。

解决问题​

1. 使用 noop function 避免索引

explain verbose
select clrq, jgmc, id
from ic.organizations
where jgmc &@~ '百度'
  and clrq is not null
order by coalesce(clrq) desc
limit 30 offset 0
;

2. 使用 expression 避免索引

explain verbose
select clrq, jgmc, id
from ic.organizations
where jgmc &@~ '百度'
  and clrq is not null
order by clrq+0 desc
limit 30 offset 0
;

3. 添加 nulls 顺序避免索引

• 因为 index 默认 asc nulls last 因此 asc 和 desc 选择不同 nulls 顺序
• where is not null
• desc nulls last
• asc nulls first

explain verbose
select clrq, jgmc, id
from ic.organizations
where jgmc &@~ '百度'
  and clrq is not null
order by clrq desc nulls last
limit 30 offset 0
;

4. 调整 STATISTICS

• 在两者统计 rows 不同的情况下 - 这里不适用
• SET STATISTICS
• CREATE STATISTICS

STATISTICS 场景​

STATISTICS 影响 n_distinct，n_distinct 影响 inputs_rows，多个计划相同，可增加 STATISTICS 避免错误选择索引。

SELECT attname,
       n_distinct,
       null_frac
FROM pg_stats
WHERE tablename = 'organizations'
  and attname in ('clrq', 'jgmc');

SELECT relname, reltuples, relpages
FROM pg_class
WHERE relname LIKE 'organizations';

参考​

• https://gocardless.com/blog/debugging-the-postgres-query-planner/
• https://dba.stackexchange.com/a/258986/234272