Sign in Subscribe
Admirable 技术博客

Software Engineering & Hacks

基于事件溯源（event sourcing）的业务架构范式
软件工程

基于事件溯源（event sourcing）的业务架构范式

问题描述 📔 Data change VS business event 在笔者就职的部门的现有系统中，一个常见的模式是让下游直接消费“解析后的MySQL 表的 binlog”——也就是数据库行级变更的 before / after 镜像——并把它当成“业务消息”来使用。 这种做法在原型阶段确实省事：binlog 已经包含了字段差异，无需额外开发，任何一次 UPDATE、DELETE 都能自动生成“事件”。 然而，把数据变更（Data change）当成业务事件（Business event）来驱动整个链路，本质上是用“存储层实现细节”替代“业务流程核心语义”，不仅丢失了上下文信息（从而影响业务决策），也使得上下游之间存在了更强的耦合。从架构设计的角度看，是一种反模式，它存在语义缺失的问题，并在长期看增大了系统模块间的耦合程度，容易造成隐患。通过下表，我们可以对比数据变更和业务事件的区别： 维度
34 min read
UBNT路由器+WireGuard+Surge配置远程访问家中网络
网络

UBNT路由器+WireGuard+Surge配置远程访问家中网络

最近把家里的全套网络设备换成了Ubnt（Ubiquiti）家的，由于Ubnt的路由器自带WireGuard服务端，因此想要利用一下，直接在路由器上配置WireGuard服务端，来避免在额外设备上运行WireGuard，导致复杂的网络拓扑。 在Unifi控制台配置WireGuard非常简单，直接通过UI进行配置并添加客户端即可（每次添加完客户端记得点击下面的保存按钮，不然不会生效）： 比较特殊的点在于，我的NAS将软路由的IP手动设置为了网关，没有采用默认的网关地址。这就导致了遇到来自WireGuard的网段的请求时，NAS无法正确应答。 这需要我们手动在Unifi控制台添加一条NAT记录，使得来自WireGuard客户端的流量进局域网之后被识别为局域网内的流量，而不是WireGuard网段的流量。这样，在NAS看来，流量就来自UBNT路由器的IP，而不是外部的IP： 在这一步之后，就已经完整的在Unifi控制台上配置好了WireGuard服务器。由于我的设备都是Apple的设备，并且统一使用Surge，因此下面需要在Surge中配置客户端。这里主要难点是通过module隔离不同
3 min read
使用 WireGuard 搭建 VPN 访问家庭内网
网络

使用 WireGuard 搭建 VPN 访问家庭内网

不知道从什么时候开始，B 站博主和什么值得买的值友都开始纷纷带货 NAS 了。看了很多人推荐，于是自己也买了一台群晖 NAS 来玩玩。由于 NAS 部署在家中，出门的时候要访问文件就非常不方便。传统的做法是使用群晖的 QuickConnect 或者 DDNS。然而，前者（据说）速度很慢，后者将设备暴露在公网上，安全性又存在一些疑虑。因此我决定试一试组网工具 WireGuard。
9 min read
搭建代理防止 Google Analytics 代码被客户端屏蔽
Web 开发

搭建代理防止 Google Analytics 代码被客户端屏蔽

每课（我创立的开源项目）前端一直使用的是 CNZZ 的网站统计服务（现在叫友盟了），前段时间因为做表单验证的需要开始使用谷歌的 ReCaptcha，突然想到谷歌的 Analytics 是不是也可以在国内正常使用呢？毕竟广告是谷歌的发动机，在网站统计、用户画像这方面谷歌应该还是非常专业的。于是决定开始尝试使用 Google Analytics。
4 min read
Python Web 内存调优，以及 Python 中的 Copy-on-Write
Python

Python Web 内存调优，以及 Python 中的 Copy-on-Write

最近把所有服务迁移到 Kubernetes 之后，终于可以直观地通过可视化面板观察容器的资源使用情况了。在看的时候发现自己写的 Python Web 项目一启动就要占用 250MB 左右内存，感觉有点偏高，于是尝试优化。这篇文章牵涉到 Linux 的 CoW 在 Python 中的处理方式，目前中文互联网上没有什么资料，于是我顺便填补一下这个空白。
5 min read