ZDREAM - Thassarian 的个人博客
对抗变化的方法唯有拥抱变化。
目 录CONTENT
以下是
经验教程
相关的文章
-
-
解决MD文件图片资源失效问题的一种实践：PicGo + 阿里云OSS 背景Markdown（简称MD）是一种轻量级标记语言，凭借其简洁的语法和对纯文本的专注，在技术文档撰写、笔记记录等场景下得到了广泛应用。它允许我们将格式与内容分离，最终可以轻松转换为HTML、PDF等多种格式，极大提升了内容创作的效率。 然而，便利性的背后也存在一个常见问题。当我们在本地使用Markdown编辑器（如Typora）写作时，插入的图片通常是引用的本地路径。这意味着，如果我们将这个.md源文件单独发送给他人，或者发布到不支持本地上传的平台，对方打开时所有的图片都将无法显示。传统的解决方法，如将文档导出为不可编辑的PDF，或者将.md文件和图片文件夹一起打包发送，都显得不够优雅和高效。 要从根本上解决这个问题，就需要引入“图床”的概念。简单来说，图床就是一个专门用来存储图片的网络服务器。我们将图片上传到图床，它会返回一个公开的URL链接。在Markdown文档中，我们用这个URL替换本地图片路径，这样无论文档在哪里被打开，只要有网络连接，图片就能被正确加载。 其实最初是想折腾一下自建图床的，也研究了一些开源方案，比如功能强大的S3兼容对象存储 MinIO，或是专门的图床程序如 hevereto 等，可以通过 Docker 方便地部署在自己的服务器上，数据的完全私有化也很有吸引力。不过，考虑到很多文档和图片资源需要在一些重要场合使用（比如面向业主的汇报材料或是大型培训的讲义），长期使用的稳定性、图片的访问速度就成了必须优先考虑的因素。自建服务固然有掌控数据的乐趣，但也意味着要自己承担网络波动、硬件故障等潜在风险。恰好当时阿里云在做活动，“OSS标准存储包”40GB一年的费用仅为9元，综合考量下来，这个成本远低于自己维护一台服务器的精力开销。最终，还是选择了阿里云OSS作为更稳妥的方案。注意！使用OSS时要注意防止流量盗刷。之前关注的某博主就因OSS存储桶（Bucket）的公网访问权限配置不当，被恶意程序在短时间内刷掉了巨额流量，据说是一周被刷掉了几万块。因此，在开通OSS后，务必第一时间在费用中心设置一个消费预算告警，例如每月消费超过10元就发送短信或邮件提醒，并设置封顶阈值，尽量规避风险。配置 有了存储图片的仓库，下一步就是如何让写作流程自动化，实现“图片即插即用、自动上传”的无缝体验。这里采用的组合是 Typora + PicGo。 PicGo是一个开源的图床上传工具，它像一个中转站，可以接收来自剪贴板或本地文件的图片，然后根据配置好的插件，将其自动上传到指定的图床（如阿里云OSS、腾讯云COS等），并返回相应格式的链接。 配置过程很直接：安装PicGo：从其官网或GitHub仓库下载并安装客户端。配置PicGo的阿里云OSS插件：在PicGo的“插件设置”中搜索并安装aliyun-oss插件。在“图床设置”中找到“阿里云OSS”，并填写配置信息。这些信息都可以在阿里云的控制台找到：keyId 和 keySecret：访问控制（RAM）中创建的AccessKey，建议授予仅有OSS写入权限的子账户，以实现权限最小化。存储空间名 (Bucket)：你创建的OSS存储桶名称。存储区域 (Area)：例如oss-cn-hangzhou。指定存储路径：可以自定义一个文件夹路径，如img/，便于管理。集成Typora与PicGo：打开Typora的“偏好设置”，找到“图像”选项。在“上传服务设定”中，选择“PicGo(app)”。指定PicGo应用程序的路径。点击“验证图片上传选项”按钮，如果看到成功提示，则说明整个链路已经打通。 完成以上配置后，整个工作流就变得非常顺畅。当在Typora中粘贴或拖入一张本地图片时，PicGo会自动在后台接管，将其上传到阿里云OSS，然后将返回的URL链接替换掉文档中原始的本地路径。整个过程几乎是瞬时的，对于写作者来说完全无感。 至此，Markdown文档的图片引用问题得到了一个比较完善的解决。它确保了文档的独立性和可移植性，无论是在不同设备间同步，还是分享给他人，都能保证图文并茂的完整呈现。虽然前期需要一些简单的配置，但这种“一次配置，长久省心”的投入，对于维护一个清晰、可靠的个人知识库而言，是值得的。
-
混合部署：云服务器结合私有机房 云服务器结合私有机房的混合部署，可以规避家庭宽带没有固定IP的短板，也绕开了云服务器高性能配置的价格壁垒。它为个人开发者、极客和小型技术团队提供了一个兼具高性能、低成本和高度灵活性的服务部署选择。虽然配置过程比直接购买云服务或成品穿透服务要多几个步骤，但由此换来的自主权和性价比是值得的。一、 方案概述：一种非典型的“混合云”传统的混合云通常指企业利用专线或VPN将内部数据中心与公有云连接，实现资源的统一管理和调度。而对于个人开发者或小型团队而言，可以借鉴这种思路，构建一个轻量级的、更注重成本效益的混合架构。核心思路是将核心资源部署在本地的私有服务器上，而将公网IP、网络转发和安全接入等功能交由一台廉价的云服务器处理。具体构成如下：核心服务节点（内网）：一台位于家庭或办公室网络环境下的高性能服务器。它承担了应用、数据库、AI模型等所有计算密集型和存储密集型的任务。这台机器不直接暴露在公网上，甚至没有固定的公网IP。网络接入节点（云端）：一台配置较低、但拥有固定公网IP的云服务器（例如腾讯云的轻量应用服务器）。它的唯一职责是作为公网流量的入口和中转站，接收来自用户的请求，并通过安全的隧道转发给内网的核心服务节点。连接隧道：通过反向代理工具（如frp、NPS等）在云端和内网节点之间建立一条稳定的、加密的通信隧道。用户访问云服务器的特定端口，流量被无缝转发至内网服务器的对应端口。这种架构下，云服务器像一个“门卫”，负责接收访客并引路；而内网服务器则是真正的“功能区”，负责处理所有实际业务。二、 动机与必要性：成本与性能的平衡选择这样的架构，主要驱动力来自于对成本和性能的双重考量。1、公网IP成本家庭宽带：通常提供较高的下行带宽（如千兆），但上行带宽受限，且绝大多数不提供固定的公网IP地址。动态IP对于需要稳定访问的服务而言是不可接受的。企业专线：提供固定公网IP，但价格昂贵，对于小团队或个人项目来说，成本过高。2、商业穿透服务市面上存在一些商业化的内网穿透服务，例如“花生壳”。通过其价格表可以看出，即便是企业级套餐，其在带宽、并发连接数和功能上也存在诸多限制。例如，一个年费数千元的套餐可能只提供有限的带宽和映射数量，性价比不高，难以支撑稍有规模的应用。 3、云服务器直接在云端租用一台与自建服务器同等配置（如8核16G内存、1T固态硬盘）的服务器，每年的费用会非常可观。而作为“门卫”角色的低配云服务器则极为便宜。例如，一台2核2G或4核4G，带有3-5Mbps带宽的轻量云服务器，年费可能仅需几十到一百元。这笔开销远低于企业专线或功能完善的商业穿透服务。 4、自建硬件一次性投入。一台配置不错的服务器（例如8核16线程CPU、32G内存、1T SSD）的组装成本大约在3000元左右，但可以长期使用。性能与数据所有权。可以获得远超同价位云服务器的计算性能和存储空间，并且所有数据都保留在本地，拥有完全的控制权。综上，通过“云端转发+本地计算”的模式，可以用极低的年费（一台轻量云服务器+一个域名）撬动起本地强大的硬件资源，实现了成本和性能的最佳平衡。三、 实现细节：关键技术点记录要实现此架构，核心在于“动态域名解析”与“反向代理”的协同工作。云服务器像一个地址固定的“总机”，而DDNS则负责实时告诉“总机”我们内网这个“分机”的最新号码。域名与DDNS (Dynamic DNS)这是整个方案的基石。由于家庭宽带的公网IP会不定期变动，我们需要DDNS服务将一个固定的域名（例如 home.example.com）实时解析到我们家里的动态公网IP上。服务选择：市面上有许多DDNS服务商，一些域名注册商（如Cloudflare, GoDaddy）也自带免费的DDNS功能。客户端配置：需要在内网环境中运行一个DDNS客户端。许多现代路由器（如OpenWrt、梅林固件）都内置了DDNS客户端，只需填写域名和API密钥即可。也可以在内网的服务器或NAS上通过Docker等方式运行一个DDNS更新程序。最终效果：配置完成后，无论家里IP如何变化，访问 home.example.com 总能准确地找到我们的网络入口。内网路由器：端口转发DDNS解决了“找到家门”的问题，端口转发则解决了“进入哪个房间”的问题。云服务器的Nginx请求到达路由器后，路由器需要知道把这个请求交给内网的哪一台机器的哪个端口。在路由器管理界面中，设置端口转发规则。例如，将外部访问的 8080 端口，转发到内网服务器（如IP为192.168.1.100）的Web服务端口 80。云服务器：Nginx反向代理配置云服务器是用户访问的固定入口。我们在这里部署Nginx，让它充当反向代理，最主要是把非标端口转化成443。四、 总结与思考通过 DDNS + Nginx反向代理 的组合，实现了利用廉价云服务器作为公网固定入口，撬动内网高性能硬件资源的目标。这种方案的技术栈更为通用，对于熟悉Nginx的开发者而言几乎没有新的学习成本。同时，DDNS域名本身也具备了独立使用的价值。对于一些非Web服务，如远程桌面、NAS文件访问等，可以通过配置不同的端口转发，直接使用DDNS域名进行连接，无需经过云服务器中转，灵活性更高。当然，此方案的成立依赖于一个前提：拥有一个可用的公网IP，哪怕是动态的。
-
-
-
