Vue3路由与Vite的base

虽然我不是一个专门搞前端的,但也会写点点 Vue。最近实验室项目写完后需要部署一下,这里我就使用了 Docker Compose 来部署。由于前端项目有前台用户端访问和后台管理端两个,而老师申请的服务器只开了 80 端口,因此我就打算使用 nginx 来反向代理: http://example.com 为前台 http://example.com/admin 为后台 ok,那我就用了一个 nginx 容器做网关,其 nginx.conf 如下: server { listen 80; listen [::]:80; server_name _; # 后台管理 location /admin/ { proxy_pass http://frontend-admin; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 后端接口 location /api { proxy_pass http://backend:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # minio location /images/ { proxy_pass http://minio:9000/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 前台用户 location / { proxy_pass http://frontend-user/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location = /admin { return 301 /admin/; } } docker compose up -d 后,用户端能访问并且接口没问题,但是一到管理端 http://xx.xx.xx.xx/admin,就会是白屏,我检查了一下,管理端页面的标签栏标题是正确的,也就是 nginx 反向代理没问题,获取的 index-xxx.js 和 index-yyy.css 也没问题,那就奇了个怪了。 ...

2025-10-16 · 1 min · 179 words · Kerolt

国内安装Docker CE

以下操作基于 Debian12 # 1. 添加阿里的 Docker 镜像仓库证书 curl -fsSL https://mirrors.aliyun.com/docker-ce/debian/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/aliyun-docker.gpg # 2. 添加仓库 echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/aliyun-docker.gpg] https://mirrors.aliyun.com/docker-ce/linux/debian \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 3. 安装 sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin 安装完成后,通常我们要将自己加入 docker 用户组: usermod -aG docker ${USER} 之后还需配置一下国内镜像(/etc/docker/daemon.json): { "registry-mirrors": [ "https://dockerproxy.net", "https://hub-mirror.c.163.com", "https://mirror.ccs.tencentyun.com", "https://mirrors.aliyun.com" ] }

2025-10-13 · 1 min · 67 words · Kerolt

股票问题II与状态机dp

本篇文章思路来源于 @bilibili/灵茶山艾府 题目描述:https://leetcode.cn/problems/best-time-to-buy-and-sell-stock-ii 相对于买卖股票的最佳时机 I,该问题可以多次买入和卖出股票以获取最大利益 ...

2025-09-24 · 2 min · 379 words · Kerolt

Windows Terminal分屏快捷键

左右分屏: 使用 Alt+Shift+= 或 Alt+Shift+- 快捷键。 上下分屏: 使用 Alt+Shift+= 或 Alt+Shift+- 快捷键。 取消分屏: 使用 Ctrl+Shift+w 快捷键。 关闭当前标签: 使用 Ctrl+Shift+w 快捷键。

2025-09-18 · 1 min · 20 words · Kerolt

Linux NAPI机制知识点总结

对 https://docs.kernel.org/networking/napi.html 的总结 NAPI (New API,但现已无特定含义) 是 Linux 内核中用于高效处理网络数据包的一种机制,旨在减少高负载下的中断开销。 其​目的​​是为了解决传统基于中断的包处理在高流量下的性能问题(“中断活锁”)。通过混合​​中断​​和​​轮询​​模式,在低负载时使用中断保证低延迟,在高负载时切换到轮询保证高吞吐量。 设备通过中断通知有新数据包 -> 内核调度对应的 NAPI 实例 -> 在软中断上下文(或内核线程)中轮询处理多个数据包 -> 处理完毕后再打开中断。 核心数据结构与 API ​​struct napi_struct​​: 核心数据结构,代表一个 NAPI 实例,保存其状态信息。 通常与一个中断或一个队列(RX/TX)相关联。 ​​控制 API (初始化和状态管理)​​: netif_napi_add() / netif_napi_del(): 向系统添加/删除一个 NAPI 实例(通常附加到网络设备上)。 napi_enable() / napi_disable(): 启用/禁用 NAPI 实例。禁用状态下实例不会被调度,poll 方法不会被调用。​​注意​​:API 非幂等,错误调用顺序可能导致死锁或竞态。 ​​数据路径 API (调度与处理)​​: napi_schedule(): ​​核心调度函数​​。通常在设备的中断处理程序中调用,通知内核有数据需要处理,并获取 NAPI 实例的所有权。 napi_schedule_irqoff(): napi_schedule() 的变体,用于已知在中断上下文中调用的情况,可优化中断屏蔽操作。 napi_complete_done(): ​​完成处理函数​​。当驱动程序的 poll 方法处理完所有事件后调用此函数,释放实例的所有权。​​警告​​:budget 为 0 时绝不能调用;若处理恰好用完 budget 且工作已完成,需谨慎返回 budget - 1 或等待下次调用。 驱动程序实现要点 ​​poll 方法​​: ...

2025-09-17 · 2 min · 230 words · Kerolt

什么是云原生(自我解惑)

云原生​​是一套以​​微服务、容器、动态编排(如 Kubernetes)、DevOps​​为核心,旨在构建和运行​​弹性、可靠、敏捷​​的云化应用的最佳实践集合。 理解它的关键在于思维的转变:​​从把云当作一台更便宜的虚拟主机,转变为把云当作一个可无限扩展、按需取用的计算能力平台,并以此为前提来设计和构建应用。​ 什么是云原生? ​​云原生​​ 是一种构建和运行应用程序的全新方法论,它充分利用了云计算的优势。 简单来说,​​云原生 = 云 + 原生​​。 ​​云​​:指的是应用程序运行在云环境中,而不仅仅是托管在云服务器上。 ​​原生​​:意味着应用程序从设计、开发、部署到运维的整个生命周期,都是​​专门为云环境而设计和构建的​​,是“云上的原住民”。 它不是某一种具体的技术,而是一套​​技术体系、方法论和最佳实践的集合​​,其核心目标是构建和运行​​弹性扩展、韧性可靠、易于管理、可观测、松耦合的现代化应用​​。 如何通俗地理解云原生 我们可以用一个生动的比喻来理解: ​​传统应用 vs. 云原生应用​​ 想象一下,你要运送货物。 ​​传统应用(像“巨石应用”)​​:就像把所有的货物都塞进一个巨大的、不可分割的木箱里。这个木箱非常沉重,需要一辆巨大的卡车(一台强大的服务器)来运输。如果想扩大运力,你必须换一辆更大的卡车(升级服务器,​​纵向扩展​​),这个过程很慢,而且一旦卡车抛锚,所有货物都会受损。 ​​对应现实​​:一个庞大的、所有功能都紧密耦合在一起的传统软件(如一个庞大的 ERP 系统),部署和维护都非常笨重。 ​​云原生应用(像“乐高应用”)​​:就像把货物分装在许多标准化的小集装箱(​​微服务​​)里。每个集装箱都可以被单独搬运、检查、替换。你可以根据需要轻松地增加或减少集装箱的数量(​​弹性伸缩​​),并且用许多辆小卡车(廉价的普通服务器)组成车队来运输。即使有几辆小卡车坏掉,也只会影响部分货物,整个运输系统不会瘫痪。 ​​对应现实​​:一个应用被拆分成许多小的、独立的服务(如用户服务、订单服务、支付服务),它们可以独立开发、部署和扩展。 云原生的四大核心要素 要支撑上述的“乐高式”应用,需要一套强大的技术框架。云原生主要由以下四大核心技术要素构成: ​​微服务​​ ​​是什么​​:将大型单体应用拆分为一组小的、松耦合的、可独立部署和升级的服务。 ​​好处​​:每个服务可以由不同的团队用不同的技术栈开发,更新速度快,容错性高。 ​​容器化​​ ​​是什么​​:最代表性的技术是 ​​Docker​​。它将应用程序及其所有依赖项(库、环境配置等)打包成一个标准化的、轻量级的、可移植的“容器镜像”。这个容器在任何地方(开发、测试、生产环境)的运行效果都是一致的。 ​​好处​​:解决了“在我这运行得好好的,到你那就出问题”的环境一致性问题,是应用的标准交付件。 ​​动态编排​​ ​​是什么​​:最代表性的技术是 ​​Kubernetes​​。当你有成千上万个容器需要管理时,Kubernetes 就像一位​​超级调度员和管家​​。它负责自动部署容器、故障恢复(容器挂了自动重启)、弹性伸缩(流量大了自动增加容器数量)、负载均衡等。 ​​好处​​:实现了应用的自动化和智能化运维,是云原生的操作系统。 ​​DevOps 和持续交付​​ ​​是什么​​:​​DevOps​​ 是一种文化理念和实践,它打通了开发(Development)和运维(Operations)团队,通过高度自动化工具链(如 CI/CD),实现软件的频繁、可靠、快速的交付。 ​​好处​​:使得从代码提交到应用上线的过程可以完全自动化,极大地加快了迭代速度。 ​​简单总结一下四者的关系​​: 我们用 ​​DevOps​​ 的文化和 ​​CI/CD​​ 的工具,来自动化地开发、构建和测试​​微服务​​,并将其打包成​​容器​​,最后交给 ​​Kubernetes​​ 这个编排系统去动态地管理和运行。 为什么需要云原生?它的优势是什么? 采用云原生架构能带来巨大的商业和技术价值: ​​弹性与可扩展性​​:应用可以根据流量压力自动缩扩容,轻松应对“双十一”等高峰场景,同时节省空闲时的资源成本。 ​​高韧性与故障隔离​​:单个服务的故障不会导致整个系统崩溃,系统具备自愈能力。 ​​快速迭代与交付​​:微服务和 DevOps 使得新功能可以独立、频繁、安全地发布,大大加快了市场响应速度。 ​​资源利用率高​​:容器非常轻量,可以在同一台机器上密集部署,节省硬件成本。 ​​可移植性​​:容器化的应用可以运行在任何云平台(公有云、私有云、混合云)上,避免被单一云厂商锁定。 云环境和托管在云服务器上有什么区别 特性 托管在云服务器上(租用办公室) 构建在云环境上(打造智能企业) ​​核心思想​​ ​​“换地方”​​ ​​“换活法”​​ ​​比喻​​ 你租用了一间云厂商的​​办公室(云服务器)​​,然后把自家机房里的​​旧家具、旧电脑(传统应用)​​ 原封不动地搬了进去。运维方式完全没变。 你利用云厂商提供的​​全套智能办公解决方案(云服务)​​:按需使用的会议室(计算资源)、自动化的物流系统(CI/CD)、可随意拼拆的工位(容器)、智能调度系统(Kubernetes)来​​重新组建一个高效、灵活的现代化公司(云原生应用)​​。 ​​弹性伸缩​​ ​​手动、缓慢​​。需要更多资源时,需要人工干预去升级服务器配置(​​纵向扩展​​),这通常需要停机。 ​​自动、即时​​。应用可根据流量压力,自动增加或减少计算资源(​​横向扩展​​),过程无缝,按实际使用量计费。 ​​韧性/可靠性​​ ​​依赖单机​​。如果托管你应用的这台云服务器宕机,你的服务就中断了,直到你手动将其恢复或迁移到另一台服务器。 ​​内置高可用​​。应用被设计为分布式、多实例运行。即使底层一台或多台服务器宕机,编排系统会自动在健康的服务器上重启应用实例,用户无感知。 ​​资源管理​​ ​​以服务器为中心​​。你需要关心每台服务器的 CPU、内存、磁盘使用率,并进行运维。 ​​以应用为中心​​。你只需声明“我的应用需要 2 核 4G”,云平台会自动调度和分配资源,你不再需要关心应用具体跑在哪台物理机上。 ​​成本模式​​ ​​为资源预留付费​​。你租了一台云服务器,无论你是否满负荷使用它,你都需要为它整个月的配置付费。 ​​为资源消耗付费​​。你只为应用程序实际消耗的 CPU 秒、内存 MB、网络流量付费。利用率极高,成本显著优化。 ​​技术栈​​ 传统架构,如:​​单体应用​​ + ​​服务器​​ + ​​SSH 运维​​。 云原生架构,如:​​微服务​​ + ​​容器​​ + ​​Kubernetes​​ + ​​DevOps​​。 ​​与云的关系​​ ​​租赁关系​​。你只是租用它的基础空间和硬件。 ​​共生关系​​。你的应用深度使用了云提供的数据库、消息队列、AI、大数据等​​托管服务​​,与应用紧密集成。

2025-09-17 · 1 min · 110 words · Kerolt

【k8s】什么是Service

在 Kubernetes(K8s)中,Service(服务) 是一个非常核心、关键的抽象概念。它的主要作用是: ✅ 为一组 Pod 提供稳定的网络访问入口(IP + Port),实现服务发现和负载均衡。 为什么需要 Service? 在 Kubernetes 中: Pod 是临时的、动态的 —— 它们随时可能被调度、重启、扩缩容,IP 会变 如果其他应用或用户直接访问 Pod IP,一旦 Pod 重建,连接就会失败 我们需要一个稳定的访问端点(Service),无论后端 Pod 如何变化 Service 的核心功能为: 功能 说明 服务发现 通过 Service 名称(在集群内 DNS 可解析)访问后端应用 负载均衡 自动将请求分发到后端多个 Pod 实例 解耦访问与实现 用户访问 Service,无需关心后端是哪些 Pod、IP 是多少 支持多种暴露方式 可在集群内访问、节点上暴露、或对外暴露公网访问 Service 如何工作? 创建一个 Service,并指定“选择器(selector)”来匹配一组 Pod(如 app: my-app) Kubernetes 为 Service 分配一个集群内唯一的虚拟 IP(ClusterIP) kube-proxy 组件在每个节点上设置 iptables/IPVS 规则,实现流量转发和负载均衡 当请求发送到 Service 的 IP:Port,流量会被自动转发到后端健康的 Pod Service 的 4 种类型 1️⃣ ClusterIP(默认) 只在集群内部可访问 为 Service 分配一个集群内虚拟 IP 适用于微服务之间互相调用 spec: type: ClusterIP ports: - port: 80 targetPort: 8080 selector: app: my-app 2️⃣ NodePort 在每个节点上开放一个端口(默认 30000-32767) 外部用户可通过 http://<NodeIP>:<NodePort> 访问服务 适合开发、测试或没有 LoadBalancer 的环境 spec: type: NodePort ports: - port: 80 targetPort: 8080 nodePort: 30007 # 可选,不填则自动分配 selector: app: my-app 3️⃣ LoadBalancer 适用于云平台(AWS、GCP、Azure、阿里云等) 云平台会自动创建一个外部负载均衡器,并分配公网 IP 用户通过公网 IP 访问服务 最适合生产环境对外暴露服务 spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 selector: app: my-app 在 Minikube 或本地环境,可以使用 minikube service <service-name> 来模拟 LoadBalancer。 ...

2025-09-07 · 2 min · 292 words · Kerolt

Windows11右键菜单关闭扩展

关闭右键扩展: reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve taskkill /f /im explorer.exe & start explorer.exe 如果想要恢复右键扩展: reg delete "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}" /f taskkill /f /im explorer.exe & start explorer.exe

2025-09-03 · 1 min · 25 words · Kerolt

【问题记录】ddns-go与IPv6网络配置

在完成 Rustdesk 自建服务器 的搭建后,我又想到:由于实验室服务器的公网 IPv6 地址 并非永久不变,直接使用 IP 进行远程连接(如 SSH 或 Rustdesk)并不现实,如何确保远程访问的稳定性和便利性呢。为了解决这一痛点,我决定利用 动态域名解析(DDNS) 技术,配合 ddns-go 和 阿里云 DNS 服务,将服务器的动态 IP 地址实时绑定到一个易于记忆的域名上。 本文将记录我在配置过程中遇到的四个主要问题及其解决方案。 问题 1:IPv6 临时地址导致域名解析不稳定 在启用 ddns-go 服务后,我发现尽管程序运行正常,但我的域名解析记录却频繁失效。经过排查,我意识到罪魁祸首是 IPv6 临时地址(Temporary Address)。这是一种为了增强用户隐私而设计的特性,系统会定期生成新的、临时的 IPv6 地址用于出站连接。当服务器的地址发生变化时,DDNS 服务来不及同步更新,就会导致域名无法解析到正确的 IP 地址。 解决方案:禁用 IPv6 临时地址 要解决这个问题,最直接的方法就是从系统层面禁用 IPv6 临时地址功能,强制使用稳定的、非临时的地址。 编辑 sysctl 配置文件: 使用 vim 或其他编辑器打开 sysctl.conf 文件,该文件用于在系统启动时配置内核参数。 sudo vim /etc/sysctl.conf 添加配置项: 在文件末尾添加以下两行,分别用于全局禁用和默认禁用所有网络接口的 IPv6 临时地址功能。 # 禁用 IPv6 临时地址 net.ipv6.conf.all.use_tempaddr = 0 net.ipv6.conf.enp4s0.use_tempaddr = 0 注意:如果只想针对特定网卡(例如 enp4s0)进行配置,可以添加 net.ipv6.conf.enp4s0.use_tempaddr = 0。你可以通过 ip a 命令查看你机器的网卡名称。 ...

2025-08-29 · 2 min · 332 words · Kerolt

Rustdesk自建服务器

对于现在常见的远程控制软件,例如 ToDesk、向日葵,其免费版本总有诸多限制(帧率低、分辨率低、控制时间有限制),而 RustDesk 的公共服务器现在在国内也不可用,因此我就想到了 RustDesk 的自建服务器。现在我们实验室有几台空闲的电脑,并且这些电脑都有 IPv6,这就省去了我购买云服务器的花费,可以实现零成本搭建远程服务😁 安装 RustDesk Server 我使用 https://github.com/sshpc/rustdesktool 这里的脚本来一键安装,安装完后,RustDesk Server 的默认安装目录为: /usr/local/rustdesk-sever 开放端口 我们需要放行防火墙 TCP & UDP 端口 21115-21119,其中 21115 是 hbbs 用作 NAT 类型测试 21116/UDP 是 hbbs 用作 ID 注册与心跳服务 21116/TCP 是 hbbs 用作 TCP 打洞与连接服务 21117 是 hbbr 用作中继服务 # 允许 TCP 端口 sudo ufw allow 21115:21119/tcp # 允许 UDP 端口 sudo ufw allow 21115:21119/udp sudo ufw enable 然后执行 sudo ufw status 如果有如下类似输出,表明端口已经放行并且防火墙正在运行。 状态:活动 至 动作 来自 -- -- -- 21115:21119/tcp ALLOW Anywhere 21115:21119/udp ALLOW Anywhere 21115:21119/tcp (v6) ALLOW Anywhere (v6) 21115:21119/udp (v6) ALLOW Anywhere (v6) 启动服务 在我们用脚本一键安装后,服务安装目录为: ...

2025-08-25 · 1 min · 136 words · Kerolt