<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Engineering Note on Nova Kwok's Awesome Blog</title><link>https://nova.moe/types/engineering-note/</link><description>Recent content in Engineering Note on Nova Kwok's Awesome Blog</description><generator>Hugo</generator><language>zh-cmn</language><copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright><lastBuildDate>Sat, 17 May 2025 15:12:49 +0800</lastBuildDate><atom:link href="https://nova.moe/types/engineering-note/index.xml" rel="self" type="application/rss+xml"/><item><title>A Quick Note on Setting Up a Qdrant Cluster on Hetzner with Docker and Migrating Data</title><link>https://nova.moe/qdrant-cluster-en/</link><pubDate>Sat, 17 May 2025 15:12:49 +0800</pubDate><guid>https://nova.moe/qdrant-cluster-en/</guid><description>&lt;p&gt;Anyone who has worked on RAG-related requirements would know that as your data volume grows, you not only need to address the issue of increasingly poor recall, but you&amp;rsquo;ll also notice that your vector database keeps expanding until it eventually hits your memory limit. At that point, a large-memory monolithic server is no longer sufficient to meet availability and performance needs (since a single machine will always have a memory ceiling, can&amp;rsquo;t perform smooth rolling upgrades of the cluster version, and high-memory machines are generally more expensive than multiple smaller ones). For example, there was a recent requirement to migrate a relatively large standalone Qdrant instance to a clustered deployment mode, which led to this brief note.&lt;/p&gt;</description></item><item><title>用 Docker 快速在 Hetzner 上搭建 Qdrant 集群并迁移数据小笔记</title><link>https://nova.moe/qdrant-cluster/</link><pubDate>Sat, 17 May 2025 10:00:00 +0800</pubDate><guid>https://nova.moe/qdrant-cluster/</guid><description>&lt;p&gt;做过 RAG 相关需求的同学肯定知道，当你数据量越来越大的时候，除了需要解决召回率变得稀烂的问题，还会发现你的向量数据库越来越大逐渐逼近你的内存极限，此时一个大内存的单体服务器就已经没法满足可用性和速度的需求了（因为单体机器内存总会有个上限，而且也不能平稳的滚动升级集群版本，此外普遍单大内存机器价格是高于多个小内存机器的），比如最近有一个需求需要将一个相对比较大的 Qdrant 单体迁移到 Qdrant 集群的部署模式中，所以有了这一篇小小的笔记。&lt;/p&gt;</description></item><item><title>带 GPT 辅助判定的快速大规模修文档 Typo——以 Kong 文档站的实践</title><link>https://nova.moe/fast-typo-fix/</link><pubDate>Sat, 27 Apr 2024 13:00:00 +0800</pubDate><guid>https://nova.moe/fast-typo-fix/</guid><description>&lt;blockquote&gt;
&lt;p&gt;This post is also available in English, at &lt;a href="https://nova.moe/fast-typo-fix-en/"&gt;Fast, Large-Scale Document Typo Correction with GPT-Assisted Judgement: A Case Study of Kong&amp;rsquo;s Documentation Site&lt;/a&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;曾经有人戏称——参与开源软件最快的方式就是给开源仓库修 Typo，这其实没问题。&lt;/p&gt;
&lt;p&gt;不过也有人看不起修 Typo 的人，认为只是为了刷工作量，代码中的 Typo 有的时候并不需要修，毕竟，代码在能跑的情况下有点 Typo 在代码/注释中其实也无伤大雅，毕竟，&lt;strong&gt;汉字的序顺并不定一能影阅响读&lt;/strong&gt;。&lt;/p&gt;</description></item><item><title>Fast, Large-Scale Document Typo Correction with GPT-Assisted Judgement: A Case Study of Kong's Documentation Site</title><link>https://nova.moe/fast-typo-fix-en/</link><pubDate>Sat, 27 Apr 2024 12:50:00 +0800</pubDate><guid>https://nova.moe/fast-typo-fix-en/</guid><description>&lt;blockquote&gt;
&lt;p&gt;这篇文章有简体中文版本，在 「&lt;a href="https://nova.moe/fast-typo-fix/"&gt;带 GPT 辅助判定的快速大规模修文档 Typo——以 Kong 文档站的实践&lt;/a&gt;」&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Once, someone jokingly said that the fastest way to participate in open source software is to fix typos in the repository, which is not wrong.&lt;/p&gt;
&lt;p&gt;However, some people look down on those who fix typos, thinking that they are just padding their workload. Sometimes typos in code do not need to be fixed. After all, a bit of typo in the code/comments is no harm if the code can run.&lt;/p&gt;</description></item><item><title>分布式部署 cloudflared 让访客就近回源，进一步提升访问速度</title><link>https://nova.moe/cloudflared-distributed/</link><pubDate>Thu, 18 May 2023 20:00:00 +0800</pubDate><guid>https://nova.moe/cloudflared-distributed/</guid><description>&lt;blockquote&gt;
&lt;p&gt;2023-11-27 更新：这种方法似乎只能保证有源站的国家(比如美国和日本,那只有美国和日本的访客)可以比较稳定就近回源，我在 Cloudflare Community 上发了帖子： &lt;a href="https://community.cloudflare.com/t/tunnel-cannot-route-to-geographically-closest/537965/8"&gt;https://community.cloudflare.com/t/tunnel-cannot-route-to-geographically-closest/537965/8&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;目前如果希望稳定就近回源，或者说可控的话，除了用 IPv6 Anycast 以外似乎还可以使用 Worker 回源，相关博客： &lt;a href="https://blog.webp.se/cloudflare-workers-geo-lb-zh/"&gt;使用 Cloudflare Workers 在边缘让服务就近回源——降低全球平均延迟&lt;/a&gt;&lt;/p&gt;</description></item><item><title>Web 应用想弹性扩缩容还必须用 AWS？在 Amazon Elastic Kubernetes Service (EKS) 上部署一个典型 Web App 的笔记</title><link>https://nova.moe/deploy-web-app-stack-on-eks/</link><pubDate>Mon, 05 Dec 2022 19:00:00 +0800</pubDate><guid>https://nova.moe/deploy-web-app-stack-on-eks/</guid><description>&lt;p&gt;本文是一篇笔记，方便后人踩坑，也方便自己在之后踩坑了之后回顾整个流程，阅读本文需要有以下预备知识/准备：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;一个没有欠费的 AWS 帐号&lt;/li&gt;
&lt;li&gt;已经可以容器化运行的应用程序，并且镜像已经推到了对应区域的 ECR 中或者为公开镜像&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;作为一个典型的 Web App，肯定是由 App Server ，Web Server 和 Database 构成，为了能做到比较可靠地弹性扩缩容，这里全部使用 AWS 平台，对应的就变成了 Container，Application Load Balancer 和 AWS RDS。&lt;/p&gt;</description></item><item><title>Halo 官方镜像源在 Serverless(Cloudflare Workers + R2) 上的实践</title><link>https://nova.moe/halo-mirror-serverless/</link><pubDate>Sun, 13 Nov 2022 20:33:33 +0800</pubDate><guid>https://nova.moe/halo-mirror-serverless/</guid><description>&lt;p&gt;一转眼两年过去了，在两年前的实践中，我利用 Cloudflare 的 Serverless 平台——Workers 做出了两个小玩具 「&lt;a href="https://github.com/knatnetwork/g2fs-serverless"&gt;knatnetwork/g2fs-serverless&lt;/a&gt;」和「&lt;a href="https://github.com/knatnetwork/g2ww-serverless"&gt;knatnetwork/g2ww-serverless&lt;/a&gt;」，分别可以将 Grafana 的报警信息推送到飞书和企业微信上，解决了当时在 PingCAP 内部使用对应聊天工具时没法很方便收到来自 Grafana 报警的问题。&lt;/p&gt;</description></item><item><title>用 Go Ethereum 在链上直接读取 ERC20 智能合约信息</title><link>https://nova.moe/read-smart-contract-info-from-chain/</link><pubDate>Sat, 11 Jun 2022 11:00:00 +0800</pubDate><guid>https://nova.moe/read-smart-contract-info-from-chain/</guid><description>&lt;blockquote&gt;
&lt;p&gt;我也不知道这个有什么用，只是感觉做起来比较好玩。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;在看 Görli Testnet 的 Etherscan 的时候，比如这个链接： &lt;a href="https://goerli.etherscan.io/token/0x3ffc03f05d1869f493c7dbf913e636c6280e0ff9#readContract"&gt;https://goerli.etherscan.io/token/0x3ffc03f05d1869f493c7dbf913e636c6280e0ff9#readContract&lt;/a&gt; ，可以直接看到一个合约的一些基本信息，比如 Decimals，Max Total Supply 之类的&lt;/p&gt;</description></item><item><title>使用 VPN + 静态路由构建一个稍好一些的家庭网络方案</title><link>https://nova.moe/a-better-vpned-home-network/</link><pubDate>Tue, 17 May 2022 00:00:00 +0800</pubDate><guid>https://nova.moe/a-better-vpned-home-network/</guid><description>&lt;blockquote&gt;
&lt;p&gt;这是一篇关于网络改造的记录，文章很简单，搞起来很开心。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;在 Tuki 的文章「&lt;a href="https://tuki.moe/use-raspberry-pi-as-gateway-for-global-internet-browsing/"&gt;利用树莓派做旁路网关实现家居全局透明科学上网实践&lt;/a&gt;」中，我们知道，可以通过 SS-Redir + Unbound + DNScrypt 的方式实现国内外分流并设置海外地址自动走代理，但是这个方案有一些弊端，比如：&lt;/p&gt;</description></item><item><title>在 GitHub Actions 上使用多 Job 并行构建，提升 Multi-Arch 镜像制作速度</title><link>https://nova.moe/accelerate-multi-arch-build-on-github-actions/</link><pubDate>Sun, 17 Apr 2022 20:00:00 +0800</pubDate><guid>https://nova.moe/accelerate-multi-arch-build-on-github-actions/</guid><description>&lt;p&gt;在土豆大佬的文章 「&lt;a href="https://dmesg.app/github-actions-docker-image.html"&gt;使用 GitHub Actions 构建 Multi-arch Docker image&lt;/a&gt;」 中我们知道，如果希望在 GitHub Actions 上构建一个 Multi-Arch 的镜像，其中关键的 Workflow 内容类似如下：&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;如果你不懂什么是 Multi-Arch 的话，你可以先看看上面的文章.&lt;/p&gt;</description></item></channel></rss>