❌

普通视图

发现新文章，点击刷新页面。
昨天以前布鲁斯鱼的奇思乱想

SRE 冲浪记 - 5

✇布鲁斯鱼的奇思乱想
2024年4月15日 08:00
一只守在汉堡店周围的鸟，随时等待食客投喂汉堡
一只守在汉堡店周围的鸟，随时等待食客投喂汉堡
（放在草稿箱俩月了，想着与其吃灰，不如发出来，也许是冲浪记的最后一篇）

观点

核心业务逻辑，还是自己写吧

If it’s a core business function — do it yourself, no matter what.

远程工作就像是玩一款能给你工资的电子游戏

实践

CSS 2023年都加了啥？

 

如何构建一个在线合作文档

小憩

一个 Rust 编写的静态站点生成器

半夜刷手机，最低亮度还是觉得太亮？可以这么做

适用于播客的音频剪辑软件

免费的高清动植物3D模型

拜登：“一切非 Rust 项目均为非法”

在该报告中，拜登政府希望软件开发人员尽量使用 Rust 这样的内存安全编程语言，并放弃 C 和 C++ 等安全性薄弱的语言。另外，参议院还强调会努力为内存安全立法。
notion image

计算机魔法 Shader 赏析

纯 Shader + 数学实现一个风景视频
204 行一首现代水纹诗
 

SRE 冲浪记 - 4

✇布鲁斯鱼的奇思乱想
2023年12月7日 08:00
2021年拍摄于深圳小梅沙海滨栈道
2021年拍摄于深圳小梅沙海滨栈道

观点

Python 容易，Go 简单

语法本身没太多可以讨论的，主要是文章后半段的引申，用 Python 做早期的概念验证、原型开发的成本要显著低于其他语言，在新的领域，需求不明确，量级不清晰的时候，用 Python 构建一个可行能跑的工程是最快、最轻松的，等到需求稳定、量级递增后，改用 Go 或者 Rust 重写是一个很好的选择。

Python 是一门编译语言

作者通过 Python「有编译阶段」判断：Python 是编译语言（当然也是解释语言），它们并不是二分对立的，同时他认为“动态”和“静态”才是真正的区别。

管道胶带程序员

非常早的一篇文章，但是探讨了一个不过时的概念“管道胶带程序员”——能把代码问题解决，但是缺乏对细节和基本代码质量关注的程序员。
与之对应的是 “建筑宇航员”，过分关注代码架构和过于洁癖，而没有实际产出软件的程序员。在我看来，这两个极端当然都不可取：对于一个长期服务的软件而言，如何在更长的时间尺度上，保证软件交付时间是程序员都需要持续练习的平衡之术。
 
notion image

实践

HTMX： 轻量级后端的 Web 网页开发方案

主要的目的是将一些 JavaScript 的功能封装到 HTML 标签里，很适合后端开发拿来做一些简单的小项目。

Linux 观测实践

系统观测是近段时间很热的领域，但实际上技术和实践早在前几年就开始逐步积累了。这篇几年前的文章很好地给“为什么要做系统观测”、“系统观测有哪些应了解的知识”、“系统观测有哪些技巧” 这几个问题做了解答，值得一读。

Go 可读性代码规范

Uber 的 Go 大仓实践

一种避免指针 nil 的 Go 实践 - NilAway

静态扫描器，把项目中潜在的空指针问题在编译阶段解决的工具。

小憩

专业的 iOS 相机软件

苹果拍宣传片也不用自家相机 Ap
notion image

Today I Learned

今天我学到了什么？一种以短小知识点构成的个人学习仓库，适合记录一些片段式的学习笔记（就像我的冲浪记一样）
notion image

Emoji AI 生成器

Ascii 艺术画

适合放到各种 Terminal 里。

Django ORM：天使与魔鬼 II

✇布鲁斯鱼的奇思乱想
2022年9月9日 08:00
最近重操 CRUD 旧业，又有一些新的发现，故增加一篇 Django ORM：天使与魔鬼 Part II。

利用 batch_size 控制数据库单次提交的大小

bulk_create 和 bulk_update 是我们常用的批量创建、更新的方法，但批量提速一时爽，提交过长会直接导致任务失败。
之前没有细致查阅文档，想当然 手写了批量提交分片的逻辑 ，虽然也完全实现了功能，但终究多了一份需要维护的逻辑，实际上直接用 Django 默认提供的 batch_size 即可。
from itertools import islice

batch_size = 100
objs = (Entry(headline='Test %s' % i) for i in range(1000))
while True:
    batch = list(islice(objs, batch_size))
    if not batch:
        break
    Entry.objects.bulk_create(batch, batch_size)

通过 Prefetch 控制预取的查询

N + 1 问题是非常常见的查询效率杀手。在 Django 中我们通常会使用 selected_related 或prefetch_related 来预取关联对象，来减少和 DB 之间的交互，但是在使用上也需要有一些注意的地方。
首先，预取需要精确控制到字段。
Django 默认的查询方式都是粗放的，例如普通查询不使用 values 或者 only 时都是 select * ，而预取也不例外，看看下面这个例子。
class Foo(models.Model):
	...

class Bar(models.Model):
	foo = models.ForeignKey(Foo)
	...

class Baz(models.Model):
  """A very large table"""
	foo = models.ForeignKey(Foo)
我们在查询 Foo 时，会尝试预取关联字段以加速后续数据读取，但如果我们在调用时不加任何参数：Foo.objects.all().prefetch_related() ，默认地 Django 会将所有关联字段都取出来，加入 Baz 表无比巨大，本来用作性能优化的 prefetch_related 就会摇身变成耗时怪兽。
此外，我们还会遇到级联预取的场景。
class Foo(models.Model):
	...

class Bar(models.Model):
	foo = models.ForeignKey(Foo, related_name="bars")
	...

class Baz(models.Model):
	bar = models.ForeignKey(Bar, related_name="bazs")
	large_config = models.JSONField()
	...
此时在后续的循环处理中，我们需要通过 Foo 对象查询到 Baz 的数据，为了避免 N + 1 我们也会多级预取:
Foo.objects.filter().select_related("bars").prefetch_related("bars__bazs")
此时二级预取也是默认获取全部字段，倘若 Baz 表中有一个需要额外耗时序列化的字段，同样会使优化适得其反。这时可以考虑引入 Prefetch 对象，做更细致的查询控制。
Foo.objects.filter().select_related("bars")
.prefetch_related(
	Prefetch("bars__bazs", queryset=Baz.objects.defer("large_config"))
)
 
是不是觉得 ORM 查询本身也挺繁杂的？用 SQL 有时会更直接清晰地多。所以也会有一些完全不使用 ORM 的观点。在我看来，ORM 能让 90% 的查询都变得结构化更清晰、更易维护、甚至更安全，但剩下的 10% 也许会耗费更多的精力，所以何时使用 ORM 是根据具体项目场景来定的，不能因噎废食。

小广告

是不是觉得 Part II 内容有点少？没关系，更多的内容我都放在了这里。
我和团队小伙伴整理了很多 Python\Django\DRF 的最佳实践经验，项目会持续更新，欢迎一起探讨维护，希望每一个 CRUD 男孩/女孩都能少踩坑。

ReDoS：正则也许会让你的系统更脆弱

✇布鲁斯鱼的奇思乱想
2022年3月1日 08:00

引

这里有一段看起来稀松平常、人畜无害的 Python 代码，你可以试着执行一下：
import re
import time


value = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaabs"
strange_regex = re.compile("(a+)+s")

start = time.time()
re.match(strange_regex, value)
end = time.time()

print(end - start)
不知道大家执行了多久，在我开发机上使用 Python 3.6+（包括 3.10.x）需要耗费20秒以上，即使 CPU ——Apple M1 Pro 的性能已经相当强悍了。
可以试想一下，如果在生产环境服务的关键请求链路中存在这样正则匹配，加上不可控的用户输入，很容易落入“性能陷阱”，轻则拖慢系统，重则直接让服务暴露在 ReDoS (Regual Expression Denial-of-Service) 的风险之下。
随手一搜，已经有不少相关的案例发生：CVE-2021-23343 、CVE-2021-41817。所以，它值得我们格外重视。

Evil Regex 大敌当前

先来看一些和上面例子类似的、典型的邪恶正则：
  • (a+)+
  • ([a-zA-Z]+)*
  • (a|aa)+
  • (a|a?)+
  • (a|a)+$
  • (.*a){x} for x \> 10
它们都有共同的一些特点：
  • 存在子表达重复——形如 ()+ 、 ()*
  • 在重复的子表达中：
    • 存在重复项—— (a+)+
    • 存在交替重复—— (a|aa)+
  • 在重复的子表达的末尾，存在一个子表达式无法匹配的内容，例如 (a|a)+$
那么为什么这些重复会导致匹配速度如此之慢呢？我们要看看正则的具体实现思路。

知己知彼，百战不殆

当前主流语言的正则实现机制都是构建非确定有限状态自动机(NFA) ，相较于确定有限状态自动机(DFA)，前者会使用回溯法(backtracking)，这也是导致邪恶正则存在的根因。

NFA vs DFA

（该章节中的图例均来自这篇文章，我在这里做了内容简化，建议有兴趣的同学阅读英文原文）
FA 有限自动机，又称 FSM 有限状态机，在当前的语境下，我们统一都是用 FA 来描述。这种计算模型比较常见，所以我们就着重关注 NFA 和 DFA 的对比。
首先，来看一个简单的正则表达式—— a(bb)+a ，它可以转换成以下两种表达：
DFA
DFA
NFA
NFA
上面两张图能够很清晰地表现出二者的不同：
  • DFA 中，每一个状态在接收到输入时，下一个状态都是确定的。
  • NFA 中，存在某些状态在接收到输入时，无法确定下一个状态：例如图中的 S2 接收到字符 b，S1 和 S3 都是可能的下一个状态。所以系统在分支选择时，需要进行猜测。
理论上，每一条正则表达式都可以等同转换成一个 NFA 状态机，那么如果使用 NFA 进行匹配，如何处理猜测分支就很重要了。下面我们来看一个简单遍历猜测的例子。
根据正则 abab|abbb 我们可以建立如下的 NFA：
notion image
模拟计算机匹配输入 abbb，可以有如下两种路径：
notion image
以 Step 0 开始的路径，在匹配到第三个字符时出错，此时不得不采用回溯，再次从一开始进行匹配，即 Step 4 → Step 8。
通过这个回溯方法，我们来思考正则表达式 与字符串 匹配：
如果每一次判断 是否存在时，都会尝试匹配“存在”的情况，再匹配不存在的情况，而整个字符串长度为 ，也就是时间复杂度为 。
当前主流的语言（Perl, PCRE, Python, Ruby等）采用了递归来实现深度优先回溯，相较于 Thompson NFA，最终实现的效果都是惊人的糟糕。
notion image
notion image

Thompson NFA 构造 vs DFA

为什么使用了 Thompson NFA 构造出的正则匹配会快这么多呢？主要的原因是：通过划分多个子表达式，合并相同的内容，从而减少了回溯次数。
可以转换成 Thompson 构造，图示：
notion image
稍微做一些解释：
  • q 是开始，f 是结束，白圈是状态，连线是流转
  • ε 代表着无输入
通过以上的结构，Thompson NFA 匹配的时间复杂度为 ，空间复杂度为。
 
而 DFA 更容易理解，因为它是典型的空间换时间。
NFA
NFA
DFA
DFA
可以看到每一个 DFA 的状态都等同于某一时刻 NFA 状态列表，所以 DFA 在最坏情况下，空间复杂度 ，也会在构建阶段消耗更多时间。同时没有了回溯，整个匹配时间就是字符串长度，复杂度为 。为了保证 DFA 的空间消耗，一般都会额外对构建出的 DFA 做简化，减少图的大小。

为什么主流编程语言这么慢？

说来有趣，Thompson NFA 构造法应该是编译原理的基础概念，DFA 方法从概念上也是比较简单，为什么当前的主流语言没有采用，反而采用了一个带有回溯的、效果远逊的版本？
经过一番冲浪搜索，简单概括我找到的结论：历史的局限。
While writing the text editor sam [6] in the early 1980s, Rob Pike wrote a new regular expression implementation, which Dave Presotto extracted into a library that appeared in the Eighth Edition. Pike's implementation incorporated submatch tracking into an efficient NFA simulation but, like the rest of the Eighth Edition source, was not widely distributed. Pike himself did not realize that his technique was anything new. Henry Spencer reimplemented the Eighth Edition library interface from scratch, but using backtracking, and released his implementation into the public domain. It became very widely used, eventually serving as the basis for the slow regular expression implementations mentioned earlier: Perl, PCRE, Python, and so on.
可以从上文得知，正则匹配的实现首先需要兼容原来的使用方式，而当时开发者并未了解 NFA 模拟方法，而是自己从零实现了一个回溯方法，并且被广泛地传播开了。即使这个实现很慢，但是由于已经被大规模采用，且能满足大多数的使用场景，各个主流语言也没有替换它。

正面对抗 Evil Regex

既然当前主流语言的实现肯定会存在性能陷阱，我们是否有办法检测邪恶正则呢？答案是肯定的。
在社区里有不少相关项目，例如：regexploit 、redos-detector 、vuln-regex-detector 等，它们都可以扫描出有风险的正则，就像这样：
$ echo "(a+)+s" | regexploit
Pattern: (a+)+s
---
Redos(starriness=11, prefix_sequence=SEQ{  }, redos_sequence=SEQ{ [a]{1+}{1+} [s] }, repeated_character=[a], killer=None)
Worst-case complexity: 11 ⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (exponential)
Repeated character: [a]
Example: 'a' * 3456
但是它们局限于静态的正则扫描，对于我们开发者而言，静态防御并不能完全清除风险。更好的思路是直接替换语言的默认实现。以 Python 举例，我们也找到了一些替换库：

pyre2

pip install pyre2
来自 Google re2 模块的 Python 封装 pyre2，使用了 DFA 的构造方式。可以替换原生 re 模块，大多数场景都可以得到速度的稳步提升，不存在性能陷阱。
但对于 DFA 模拟来说，都是自古华山一条道，比如 (?P=<name>) 这样的属于 backreference 的捕获组语法就无法支持了。

regex

pip install regex
regex 模块并未使用 DFA 构造，在完全兼容 re 模块的同时，支持了一些新特性。由于实现方案的不同，也没有很明确的文档阐述，尚不清楚它具体的算法（有待进一步从代码层面解读），但是从效果上，它的性能要略好于原生模块，仅从文中里例子测试看来，也规避了性能陷阱，可以谨慎采用。

总结

  • 和很多其他场景一样，程序需要时刻警惕用户的输入，任何不经过校验的内容都可能将程序拖垮。
  • 理论和实际存在各种各样的鸿沟，在面临现实场景时，理想的想法落地总是困难的。
  • 原生不代表就是最优秀的。有特殊需求时可以使用社区方案进行替换。
 
参考：
 

旧代码拾遗：如何在 Python 代码中修改 DNS 解析

✇布鲁斯鱼的奇思乱想
2022年2月18日 08:00

Why

我们访问 K8S 的 ApiServer 服务，由于为了保证安全性，证书中签发的域名仅包括 kubernetes 和初始的有限 IP 列表，当 ApiServer 服务的 Master 节点需要被替换时，就无法使用新的节点 IP 访问了。解决的方案就是将 kubernetes 域名和新的 IP 临时绑定，骗过证书校验。

How？

废话不多说，直接看代码
# -*- coding: utf-8 -*-
import contextlib
import importlib
import threading
from typing import Callable, Dict, Optional

from urllib3.util import connection


class CustomLocalDnsResolver(threading.local):
    """支持线程级自定义 Dns 记录
    """

    def __init__(self, dns_map: Optional[dict]=None):
        # 线程保存各自 dns_map，但是访问入口均为 dns_map
        self.dns_map = dns_map or {}


def get_patch_create_connection_with_dns(dns_resolver) -> Callable:
    """simply get patched create_connection"""

    # 保留原方法
    _orig_create_connection = getattr(importlib.import_module('urllib3.util.connection'), 'create_connection')

    def patched_create_connection(address, *args, **kwargs):
        """在 urllib3's create_connection 流程前解析 address"""
        domain, port = address
        # 当 _local_dns.dns_map 为空，对正常流程无影响
        host = dns_resolver.dns_map.get(domain, domain)
        return _orig_create_connection((host, port), *args, **kwargs)

    return patched_create_connection


_local_dns = CustomLocalDnsResolver()
# patch 全局 create_connection
connection.create_connection = get_patch_create_connection_with_dns(_local_dns)


@contextlib.contextmanager
def update_local_dns_once(dns_map: Dict):
    """一次性修改线程 dns 解析"""
    _local_dns.dns_map = dns_map
    yield
    _local_dns.dns_map = {}


# 具体的使用场景
with update_local_dns_once({"kubernetes": "192.168.1.1"}):
    # 可以在该 context 中请求外部系统
 
 

小记：如何将 Logstash7 镜像替换为 KonaJDK

✇布鲁斯鱼的奇思乱想
2021年12月28日 08:00
 

Step 0 预备环境

Rake 是一个由 Ruby 实现的 Make-like 工具，可以用 Ruby 来编排项目任务流程，例如出二进制包、构建镜像等。在 GitHub Logstash 项目的 rakelib 里找到镜像构建逻辑。
构建之前，需要保证构建机包含以下工具：
  • Docker
  • GNU Make
  • Python 3.5+ with Virtualenv
  • JRuby 9.1+ （实际上 Mac 自带 Ruby 也是可行的）
然后将 Logstash 项目 clone 到本地，并切换到预期修改的版本：
git checkout v7.16.2

Step 1 精简构建步骤

构建步骤中，默认会包括 Windows\MacOS 以及 Arm 的构建，如果你并不需要这些平台，可以如下手动修改构建步骤，能够大大加快你的构建速度：
# create_archive_pack(license_details, "x86_64", "linux", "windows", "darwin")
create_archive_pack(license_details, "x86_64", "linux")
# create_archive_pack(license_details, "arm64", "linux")
artifacts.rake

Step 2 修改 Python 版本

如果你不想为了构建镜像额外下载其他 Python 版本，可以手动修改 Makefile
# PY_VERSION ?= 3.6.13
# =>
PY_VERSION ?= 3.6.7
Makefile
理论上保证 Python 版本大于 3.5 即可。
 

Step 3 指定 JDK 版本

如标题所示，我们的目标是将 Logstash 镜像里的 OpenJDK 替换成 KonaJDK。构建时手动指定 JDK 地址即可
JDK_URL=https://github.com/Tencent/TencentKona-11/releases/download/kona11.0.13-fiber/TencentKona-11.0.13.b1_jdk_fiber_linux-x86_64.tar.gz rake artifact:docker
 
等待构建，大功告成 xD
 
❌
❌