2026.9.20的随笔
时间过得好快,从去年9月15日到今天,我已经失业整整一年了。这一年,我真的感觉到了一股说不出的无力感。
第一次尝试我失业是因为抑郁症,整天头疼,心里堵得慌,只能在家什么都不想,先休息一段时间。但休息了一阵之后,一股因为资金链断裂带来的不安又席卷而来。我是一个安全感很低的人,也是一个自我感觉很缺爱、也很缺被爱的人,所以从资金链断开的那天起,我就一直在想,我的出路到底在哪?
了解我的人都知道,我是一个狂热的技术爱好者,可以为了一个技术、一段代码几乎偏执地去钻研。我从14岁开始接触计算机这个行业,这些年学了很多技术——网络安全、嵌入式、运维、全栈开发。也许如果不是因为热爱,没人会像我这样坚持学这么多东西,最后还是坚定地选择来做这一行。因为这一行实在是太苦了,不管是工作环境还是工作状态,都是身体和心理的双重折磨。但在我选择这个行业的那一刻,我就已经想明白了这一切,因为我愿意为我的热爱燃烧自己,哪怕这是不可持续的,甚至可以说是自尽式的。
也许,那也只是我年轻时候的想入非非吧。
失业后半年左右,我开始尝试让自己振作起来。因为以前在这个行业打拼了太久,也算是被折磨了太久,所以本能地开始对这个行业有了 ...
《来受甘露味》看佛的世界观
戒定真香,焚起冲天上。弟子虔诚,爇在金炉放。顷刻氤氲,即遍满十方。昔日耶输,免难消灾障。
南无香云盖菩萨摩诃萨(三称)
第一次听到《来受甘露味》,是在德云社的演出中。刘鹤春一袭道人装扮,念了一段偈颂,末了把其中一部分内容改掉,竟把捧哏演员“超度”了。于是我对这部偈文产生了很深的兴趣,也对《瑜伽焰口》和《来受甘露味》做了一些了解,这里展开探讨一下。
瑜伽焰口在佛的世界观中,一切众生都活在六道之中,即天道、人道、阿修罗道、畜生道、饿鬼道、地狱道,众生在这六道中如车轮旋转般轮回。众生的一切行为,都被三个字所驱动——贪、嗔、痴。芸芸众生随自身业力,在六道中受生流转,或堕入阿修罗道、畜生道、饿鬼道、地狱道。焰口施食正是以饿鬼道为主要对象,同时召请六道群灵,以佛法之力令其暂息饥苦、种下解脱之因。
焰口,是饿鬼道中鬼王的名字。这类饿鬼食量极大,但喉管细如针尖,饥饿之火从口中喷出,食物送到嘴边便被烧焦,无法下咽,受尽痛苦。瑜伽焰口仪轨即是对这些饿鬼进行布施,通过加持将食物变成甘露,让饿鬼熄灭口中火焰、打开喉咙,脱离无尽的饥饿。而施食的最终目的,不止于令其暂得饱足,更在于为其种下出离轮回的解脱之因。 ...
流程化运维方案研讨
一、引言1.1 背景介绍随着企业信息化建设的不断深入,运维系统的规模和复杂度呈指数级增长。传统的运维模式依赖人工操作和零散脚本,存在效率低下、容易出错、难以追溯等问题。在此背景下,流程化运维逐渐成为 SRE(站点可靠性工程)体系中的重要组成部分。
流程化运维的核心理念是将重复性高、逻辑清晰的运维操作抽象为可编排的工作流,通过自动化工具进行统一调度和管理。这种方式不仅能够显著降低人为失误的概率,还能提升运维工作的可观测性和可复用性。
1.2 Airflow 与 n8n 简介Apache Airflow 是由 Apache 软件基金会维护的开源工作流编排平台,最初由 Airbnb 开发并于 2016 年开源。Airflow 使用 Python 编写 DAG(Directed Acyclic Graph,有向无环图)来定义和调度工作流,凭借其强大的可扩展性和丰富的 Provider 生态,已成为数据工程和运维自动化领域的事实标准之一。
n8n 是一款基于节点式流程图的自动化集成工具,采用”代码自由”(code-free but code-aware)的设计理念。它内置了数百种服务连接器,支持 ...
高可用网关集群设计
一、引言在现代微服务架构中,API 网关是所有外部流量的入口,承担着路由转发、鉴权、限流、监控等核心职责。网关的单点故障或性能瓶颈会直接影响整个系统的可用性,因此网关的高可用设计是运维工程中的重中之重。
本文聚焦于分布式高可用架构与自动化建设两个核心方向,探讨如何构建一个能够在故障发生时自动恢复、持续提供服务的网关集群。
二、分布式高可用架构设计2.1 无状态网关节点高可用网关的首要设计原则是节点无状态化。网关本身不持久化任何会话数据或请求状态,所有状态外置到独立的存储系统中。这样做的优势在于:
任意节点可随时增减:不需要考虑数据迁移或状态同步;
故障恢复成本低:宕机节点重启后直接从配置中心拉取最新配置即可加入集群;
水平扩展灵活:通过增加节点即可线性提升吞吐量。
无状态设计并不意味着完全没有本地缓存。为了提高性能,网关节点通常会缓存热点配置(如路由规则、鉴权密钥),但这些缓存必须支持失效后快速重建,且不能作为唯一数据源。
2.2 集群及自动化设计针对于大型入口网关集群,主要有以下一些问题:
使用传统nginx方案代理,当新的路由发布时需要更新集群内所有节点(至少相关节点需要更新 ...
Gitlab Runner原理及运维
在生产项目中,所有可执行文件和项目源码包都不是由开发人员在本地手动构建的,其主要原因有以下几点:
本地构建的产物可能和线上环境不一致,可能会出现奇怪的问题。
针对于微服务来说,一次发版可能会涉及到多个服务,每个服务都需要手动构建,这会增加运维成本。
所以针对这一问题,Gitlab Pipeline 可以将项目构建以及其他一些流程化操作使用流水线的方式进行自动化。
Gitlab CI 原理老规矩,要了解一个产品的原理首先要从架构入手。我们先来看一下 Gitlab CI 的工作流。
横向理解从工作流的过程图可以看出,Gitlab Runner 的架构主要分为三部分:
Gitlab: 即为 Gitlab 的主站,负责管理项目的代码仓库、项目配置、构建触发等。
Runner:Gitlab Runner 的客户端工具,负责启动任务。
Executor:执行器,主要完成 Gitlab CI 脚本中定义的任务。
其简化的架构可以理解为:
1Gitlab ------> Runner(任务管理器) ------> Executor(任务执行器)
纵向理解初始化阶段Gitbal ...
高可用业务全链路监控方案
监控方案介绍在 SRE 工程中,服务可观测性是一个重要的服务可靠性治理手段,其中包括但不限于:
服务器资源用量监测
服务状态及可用性指标监测
服务全链路跟踪监测
服务日志监测
报警、issues 闭环管理和事件通知系统
下面将分模块对服务业务全链路监控做一下规划以及介绍。
服务器资源和服务状态监测工具在服务器资源和服务状态监测方面,我们经常使用 Zabbix、Prometheus、falcon 和夜莺等工具,但是在实际业务场景中更多的是使用 Prometheus,其原因有以下几点:
**Zabbix 不能很好的适用于云原生环境监控**。Zabbix 其优势在于有良好的 snmp、ipmi 和 jmx 等协议支持,但是对于云原生环境其扩展性和易用性相对较差(如在 k8s 环境中,其默认只能采集 node 的性能参数,对于 pod 性能参数以及业务指标等采集完全依赖于插件二次开发)。所以 zabbix 当今更多的是被用到监控网络设备等支持 snmp 和 ipmi 的设备场景。
**Falcon 和夜莺针对性过强**。Falcon 和夜莺都是云原生环境下的监控工具,但是这两种监控工具 ...
短链接系统设计
系统背景
本系统的开发目的源于一道经典的开发面试题——设计一个短链接系统。本文将从多维度、多角度对其进行剖析。
短链接系统几乎是每个互联网公司营销业务线必备的跳转平台,其核心优势在于能最大限度压缩链接长度,对于营销短信、邮件而言,不仅具备良好的匿名性,还能提升视觉友好度。例如以下这条短链接:
单从短信中的链接来看,其 URI 看似一段乱码,但仔细分析会发现,这段 URI 由 8 个字符组成。若按每个字符占 8bit 计算,整个 URI 的信息容量恰好为 64bit,这绝非巧合。
从现象反推原理访问上述短链接会发现,浏览器会执行一次跳转操作:
也就是说,当用户访问短链接时,短链接服务的后端会根据 URI 末尾那段看似乱码的字符串,查询对应的原始长链接,随后返回 302 状态码,引导浏览器跳转到目标地址。从表面上看,其原理与普通互联网项目并无太大差异,核心都是“查询数据库 → 返回结果”,但这段“乱码”真的是后端随机生成的吗?如何确保这个随机字符串的唯一性?
永不重复的 ID在 MySQL 等传统数据库中,通常会使用主键 ID 唯一标识一条数据,其核心优势如下:
ID 通常由数据库 ...
HuckOps的2025年度总结
emmm,2025年又这么过去了。第一次写年度总结,好像应该写得正式一点,但又不知道从哪开始。随便写写吧,反正也没人看,就当是对自己这一年的碎碎念。
感情的一波三折和她认识到现在已经两年多了,分手也已经一年多了。分手后的这一年,我过得真有点不人不鬼。其实到现在我也没搞明白,自己为什么会变成现在这个样子。有时候连我自己都讨厌自己,一直想着改变,却又好像被捆住手脚一样,浑身无力。
今年年初开始,每天眼睛一睁,脑子里就忍不住想:我还能不能把她找回来?她还会不会接受我?直到后来我真的试着去联系她、挽回她,才发现我们之间的感情好像已经变了味——不再像互相喜欢,反而更像一种建立在金钱或物质上的关系。所以我一直在想,到底是什么导致了这样的变化?如果那些事没发生,我们是不是永远不会变成这样?还是一直维持着这段畸形的关系?如果没有那些事,我现在是不是已经结婚了?
了解我的人都知道,我是个十足的I人,很多事都喜欢放在心里反复琢磨。不知不觉,这些念头完全占据了我的大脑,到最后甚至影响了我的工作和生活。我总觉得自己做什么都不如以前有干劲了,就算这份工作是我喜欢的,也提不起一点动力去认真对待。再后来,我越来越难 ...
解读Cloudflare 20251118全球故障报告
Cloudflare 是什么对于运维同学来说,cloudflare 并不是一个陌生的名词,我们会经常把 cloudflare 称为赛博活佛(因为它提供了免费的全球代理等功能,在其他云上那边都要只能上全球 CDN,收费还不便宜,但是 cloudflare 只需要把域名托管到 cloudflare 平台上就可以免费使用全球加速了)。正如最近网上盛传的一个梗图
cloudflare 已经算是互联网的最根本的基石了,可以说 cloudflare 撑起了一整个互联网。cloudflare 在海外提供了多种云服务,比如权威 DNS(one.one.one.one)、全球 CDN、DDoS 防护、SSL/TLS 加密等,可以说只要目前咱们叫得上名字的大部分海外大厂都在用他们家的服务,比如 Netflix、Spotify、Twitter 等,可以说 cloudflare 在海外已经是举足轻重的地位了。但是因为一些合规原因,cloudflare 在国内业务是代理给国内一家叫科赋锐的公司(名字这么像,估计是为了合规在国内搞的全资子公司),而且经过代理之后,海外 cloudflare 有的优势以及特性在国 ...
从ERC20 USDT分析区块链合约原理
加密货币和稳定币加密货币(Cryptocurrency)又经常被称为加密资产(Crypto Asset),是指在区块链技术上运行的数字资产,如比特币(Bitcoin)、以太坊(Ethereum)等,同时也衍生出其他类型的加密资产,如 NFT(非同质化代币)等。此类货币相对于现实世界无固定的锚点,其价值由市场供需决定,且由于区块出块难度调整、市场流动性等因素,价格会有较大波动。为了解决这一问题,市场衍生出了稳定币(Stablecoin)。
稳定币(Stablecoin)是指通过特定机制保持价值相对稳定的加密货币,通常与法定货币(如美元、欧元)挂钩。目前市场上常见的稳定币包括 USDT(Tether)、USDC(USD Coin)等。根据发行机制不同,稳定币主要可分为三类:法币抵押型、加密资产抵押型和算法稳定币。以 USDT 为例,它属于法币抵押型稳定币,由 Tether 公司发行,理论上每发行 1 枚 USDT,Tether 应持有价值 1 美元的储备资产(包括现金、债券等),形成 1:1 的锚定关系,用户理论上可以随时用 1 USDT 兑换 1 美元。
多链问题解决了解区块链的玩家都知 ...
