🧑‍💻 简介作为一个 Java 后端工程师，我相信你一定遇到过下面这些问题： 使用 IDEA 启动一个 Spring Boot 项目，第一行就出现红色告警：发现多个 slf4j 实现类，提示你要排除一个； 本地开发一切正常，一部署到测试环境却报错：找不到某个 class； 项目中的 pom.xml 有上百个依赖，不知道哪个服务哪个功能，谁也不敢轻易动； 多模块之间彼此依赖，模块 A 引用模块 B，模块 B 又反过来依赖模块 A，形成“依赖闭环”； …… 经历过大大小小的 Spring Boot 项目后我发现，不论是大厂还是小团队，很多项目对 Maven 的依赖管理都重视不足。 重复引入、版本冲突、依赖混乱、模块耦合这些问题，几乎是通病。 好一点的团队会搭建一个公司级的 parent 项目来统一依赖版本；大多数直接沿用 spring-boot-starter-parent；更差的，哪缺啥引啥，能跑就行，构建配置几乎没人管。 为什么要重新思考 Maven 项目的组织结构? 因为当项目开始变大：%% %% 依赖管理就成了地雷阵，一改就炸； 多人协作时，版本不一致、依赖冲突 ...

📖 简介在上一篇 🧪 Maven Profiles 的使用场景案例分享 我们通过 Profiles 的实际案例大致了解了它的使用方式, 并详细梳理了 Profiles 的优先级, 不过也挖了一个坑: 为啥我要将 settings.xml 和项目代码放在一起? 比如 arco-supreme 项目的代码结构为: 12345678910111213141516$ tree -a -I '.git|.idea'.├── .editorconfig├── .gitignore├── .mvn│   ├── jvm.config│   ├── maven.config│   ├── settings.xml│   └── wrapper│   ├── maven-wrapper.properties│   └── MavenWrapperDownloader.java├── LICENSE├── mvnw├── mvnw.cmd├── pom.xml└── README.md 可以看到 settings.xml 文件放在了 .mvn 目录下, 且 ...

📖 简介在上一篇 🚀 从注册到发布：Maven 中央仓库上传 jar 实践 中，我们成功将本地 jar 包上传到了 Maven 公共仓库。 那篇文章的配置比较基础，主要目的是跑通流程。而在实际开发中，为了更好地适配不同环境，还需要做一些必要的优化配置。就像写代码一样，第一步是跑通，再逐步打磨细节，这次我们就来看看如何通过 Maven Profiles 实现多环境切换。 所以这篇文档我将介绍 Maven 的 Profiles 配置, 目标是让 Zeka.Stack 相关的组件既能上传到 Maven 公共仓库, 也能让大家在进行二次开发后, 只上传到公司 Maven 私服. 当然这仅仅是 Maven 的 Profiles 的一个实际应用场景, 其他还比如 根据不同 Profile 引入或排除某些依赖; 针对多模块项目，通过 Profiles 控制是否构建某些子模块; 结合 resources 标签中的 <filtering>true</filtering>，实现配置文件模板化等等场景. 🔀 deploy 环境切换直接上配置: 1234567891011 ...

✨ 前言虽然 Zeka.Stack 是全开源的, 但是每个组件也可以单独使用, 为了避免需要克隆所有项目然后本地 install 才能使用, 所以最简单的方式就是将 Zeka.Stack 的组件上传到 Maven 公共仓库, 所有就有这篇水文. 为什么说是水文呢, 因为这类的文章网上也有很多了, 这里再写一遍其实没有啥价值, 不过为了完善我 Zeka.Stack 的知识体系, 所以还是决定写一写. 🧰 准备工作这里演示使用自己的域名来作为 groupId, 所以需要 DNS 验证, 其他方式比如 GItHub, GitLab 等验证相对来说更容易些. 个人觉得 GitHub 作为 groupId 太长了, 比如我如果使用 GitHub 验证的话 groupId 就是 io.github.dong4j, 而且为了打造自己的 IP, 所以选择使用一个二级域名, 正好前段时间在 Cloudflare 注册了 dong4j.dev 的域名, 这里就可以用上了. 如果要图方便的话, 可以直接使用 arco-supreme 这个项目来做测试. 📝 注册 Sonatype 账户自 20 ...

🧑‍💻 简介在日常开发中，写业务不难，难的是「工程一上来就乱」、「依赖一多就扯皮」、「构建一复杂就抓狂」。Zeka Stack 希望通过系统化的工程体系来解决上述问题. 它不是啥“重框架”，也不是为了造新轮子，而是一个工程提质提速的脚手架体系，用清晰的模块划分、统一的构建规范和灵活的生态扩展，让你在开写业务代码之前，项目骨架就已经整整齐齐、顺手好用。 一句话：让你团队少踩坑、构建不抓狂、协作有章法。 🧱 用 Zeka Stack 打造可维护的工程骨架大家肯定遇到过这样的问题: 某次新项目启动，一开始小组成员各自拉模块、加依赖、写配置，几天后就发现： 依赖重复、冲突，启动报错； 构建流程不一致，有人能打包，有人不能； 模块命名五花八门，新人根本无从下手; 尤其是多个团队协同开发微服务系统时，经常遇到的问题包括： 痛点 描述 项目结构混乱 每个团队按自己的理解组织模块，结果变成“大杂烩” 构建方式不统一 有人用 mvn，有人用 idea，有人手动打包，构建经常失败 重复造轮子 各业务组开发重复功能，没有统一组件库 依赖冲突频发 多模块之间版本不一 ...

🧠 初心：为什么要从零开发脚手架？在众多脚手架如 RuoYi、yudao 等百花齐放的当下，从零造个轮子听起来似乎有些“何苦为难自己”。但现实却是，用别人的轮子，不一定跑得更快。 当你频繁地遇到这些问题： 脚手架升级一动就“爆炸”，依赖冲突层出不穷； 每次新建项目都得 copy/paste 三五个模块，配置头都大； 项目结构越来越重，协作越来越难； 插件脚手架不好用，代码生成一团糟； 你就会明白：一个真正贴合团队/企业开发场景的脚手架，是生产力的倍增器，而不是负担的制造者。 这，就是 Zeka.Stack 诞生的背景。 💥 我们要解决哪些“开发痛点”？Zeka.Stack 不是为了炫技，而是为了解决我们真实踩过的坑。以下是我们希望彻底优化的问题： 1. 项目依赖管理地狱 多模块工程中依赖版本冲突频发，项目启动失败； 依赖升级时担心牵一发而动全身。 💡Zeka.Stack 的解决方案： 统一公司级 BOM 管理，所有项目继承同一套依赖版本； 通过多级父模块划分业务、技术、部署职责，升级只改一行版本号。 2. 重复配置太多，效率低下 新项目初始 ...

前言家里现在跑着一套 4 节点 PVE + Ceph 集群，硬件都是一些二手 NUC、小主机和软路由刷 PVE，主要承载 Homelab 的各种服务：NAS 备份、Drive、监控、Jellyfin、还有一堆实验性的 LXC。 集群跑起来之后，日常 80% 时间是不用管的，但剩下 20% 时间全都是各种奇奇怪怪的维护：OSD 飘了、日志塞满、某个 LXC 挂载不上 cephfs、偶发脑裂……每次遇到都要翻一遍搜索引擎，干脆把这些命令全部攒成一份自己的”运维速查手册”，平时直接往里面复制粘贴。 这篇文章就是这份手册本身。内容并不是按”教程”的顺序组织的，而是按我最常翻到的频率来排，越前面的越常用。如果你也是 PVE + Ceph Homelab 的玩家，应该都能在里面找到几段能直接抄走的命令。 ⚠️ 这些命令我自己的环境全都跑过，但不保证对你也 100% 安全 —— 尤其是 Ceph 和 corosync 相关的操作，动之前请务必确认集群状态是 HEALTH_OK，并且重要数据有备份。 集群日常一键换源PVE 的官方源在国内速度感人，企业源还要订阅，第一件事就是换国内镜像。 ...

前言“咔哒”一声，屋里一片黑。 家里一楼二楼总电闸在夏天经常跳，一开始只有一台 NAS 的时候无所谓，硬关机就硬关机，顶多 DSM 开机之后跑一次文件系统检查。但自从 Homelab 一点点堆起来、PVE 集群 + Ceph 上线之后，每次停电我都要紧张一阵子 —— 不是怕硬件坏，是怕突然断电的 Ceph OSD 可能不一致，或者某台 LXC 里的数据库日志写坏了。 修好电闸只是小事，事后收拾集群这些”副作用”才是真正烦。 所以我给家里上了两台 APC UPS，再花了个周末搭了一套 NUT + 自定义关机脚本，让家里的每台机器都能在停电时优雅下班。这篇把整个方案从硬件选择到脚本逐行解释写清楚，谁来抄都能用。 硬件：两台二手 APCUPS #1：APC BK650M2-CH（跟 DS923+）这台是最早的那台，很早以前给 DS923+ 配的。 容量：390W / 650VA 价格：闲鱼 200 出头 电池：自带，7Ah 铅酸，免维护几年基本没衰减 插上 DS923+ + 一个千兆交换机之后，650VA 的余量刚刚好够跑 NAS 撑 10~15 分钟，足够 DSM 做 ...

前言说实话，我被 UPS 电源监控搞得快烦死了。 自从给家里整了套 UPS 后，就面临一个很现实的问题：家里设备越来越多，怎么让所有设备都能知道 UPS 的状态？ 一开始我只是简单地把 NAS 接到 UPS 上，想着至少 NAS 能安全关机就行。但慢慢地问题就来了： NAS 确实能安全关机，但其他设备呢？ - 正在下载的服务器、正在编码的视频工作站… 无法提前预警 - UPS 快没电了，其他设备还在正常工作，突然断电就懵了 手动管理太麻烦 - 每台设备都要单独配置，而且不同的系统配置方法还不一样 最尴尬的是有一次，UPS 已经开始最后的关机倒计时了，我还在旁边悠闲地刷视频，结果”啪”一下，全屋断电… 这时候我意识到，我需要的是一个统一的 UPS 监控方案。 NUT 是什么？在网上查了一圈，发现了一个叫 NUT (Network UPS Tools) 的开源项目。说实话，这个名字一开始我还以为是坚果相关的工具，后来才发现是 Network UPS Tools 的缩写… NUT 的核心理念很简单：让 UPS 成为网络设备。 传统的 UPS 配置是： UPS → USB ...

前言DS218+ 是我用得最久的那台群晖，2 盘位、J3355、4G 内存（后来偷偷加到 10G），常年跑 Drive、Photos、几个轻量 Docker。用下来最大的槽点只有一个：磁盘太慢了。 这货用的是两块 4T HDD 组 SHR，日常浏览照片、翻 Drive 里的老文档，机械盘寻道声噼啪响，Photos 的缩略图滚动起来一顿一顿的。我本来想加块 SSD 做读缓存，结果发现： DS218+ 在 DSM 里根本没有 SSD 缓存选项。 官方给的理由是只有 2 个盘位，”塞 SSD 就等于少一个数据盘”，所以直接把这个功能砍了。但我又不想换 920+ / 923+（那时候价格还没跳水）—— 总觉得这台机器其实硬件是够的，只是被官方软件故意阉割掉了。 然后我盯上了它屁股后面那个从来没用过的 eSATA 接口。 思路很简单：如果能把 eSATA 这个接口在系统里”改名”成一个内置 SATA 盘位，那 DSM 就会认为这台 NAS 有 3 个内置盘位，SSD 缓存选项理论上就会亮起来。 折腾了一晚上，方案跑通了。这篇把整个原理和具体参数都记一下，后面谁要是也想干同样 ...

简介本文汇总了我在三台联想 M920x 上搭建和使用 PVE（Proxmox Virtual Environment）过程中的心得与遇到的问题。 在选择虚拟化平台时，我倾向于 PVE 而非 ESXi（vSphere Hypervisor）。 这一选择基于 PVE 的开源性及其基于 Debian 的架构，这为它带来了相比 ESXi 更多的可玩性和折腾空间。 选择 PVE 或 ESXi 并不在于哪个更优秀，而在于哪个更能满足个人的特定需求。 安装完成后 IP 不对启动后出现了一张 vmbr0 网卡, 这个是桥接网卡, 可以查看绑定的物理网卡: 1ip link show master vmbr0 修改一下 3 个文件: 12345678910111213141516171819202122232425# /etc/network/interfacesauto loiface lo inet loopbackiface enp92s0 inet manualauto vmbr0iface vmbr0 inet static address 192.168.100.100/24 ...

简介家中的服务器有 3 台全部安装的是 Ubuntu, 有时候需要折腾一下. 所以想用一个文档来记录 Ubuntu 上遇到过的问题, 另外就是做一个备忘录, 将已操作过的记录保存下来, 以便在其他服务器上重现, 避免重复查询资料. 优化建议启用 Ubuntu ProUbuntu Pro 是 Canonical 提供的企业级专业支持服务，个人用户和小团队可免费使用（最多 5 台设备，超过需付费）。它提供了长达 10 年的安全更新支持。 1 打开「软件和更新」，切换到「Ubuntu Pro」选项卡。 2 点击「启用 Ubuntu Pro」。 3 访问 Ubuntu Pro Dashboard 拿到分配给你的Token，填入「手动添加令牌」中，然后点击「确定」。 参考 新手必备：安装 Ubuntu 24.04 LTS 后的 10 项基本建议 Landscape Server参考: Landscape 安装配置速记 系统克隆原来的系统安装在一块 PCIe Gen3 x4 的 M.2 固态上, 查阅资料得知这个插槽支持 PCIe Gen4 x4, 为了不浪费资源, 所以需要使 ...

前言上一篇 使用 Cloudflare 增强公网服务安全性的实践 里，我只是拿 NAS 当例子跑了一遍 Cloudflare 的代理流程，证明”这条路是通的”。 真正用了一段时间之后，我发现一个尴尬的事实：家里暴露在公网的服务不止 NAS 一个，博客、图床、私有 Git、各种管理面板加起来十来个子域名，每个都”单独配一套”的话，免费账户的规则数量根本不够用 —— Origin Rules 免费版只有 10 条。 更重要的是，只要还有一个服务没走 Cloudflare，别人用 dig 或者挨个域名试一下就能挖出我真实的公网 IP，那前面那点安全努力基本等于白做。 所以这次干脆一次到位：把 *.dong4j.dev 全部塞进 Cloudflare CDN，入口只留一个，规则也只留一条。 顺便还踩了两个跨域的小坑，一起记一下。 目标和思路先说下我想达成的效果： 家里所有对外暴露的服务都走 *.dong4j.dev 这一套子域名； 所有子域名全部经过 Cloudflare CDN 代理（小云朵是橙色的）； 用户用浏览器直接访问 https://blog.dong4j.dev、htt ...