star7th

大风云 CDN 运营两年半的心得和体会

star7th — Mon, 24 Feb 2025 11:06:03 +0800

大风云 CDN 运营两年半的心得和体会

两年半前，我写过一篇文章《我是如何把网站图片 CDN 流量成本压到全网最低 (之一)》https://w2solo.com/topics/3546 ，在那篇文章中，我分享了自己基于需求自研 CDN 并将其开放为产品进行运营的经历。现在，我想谈谈这段时间以来的一些后续体会。

运营数据如何？

目前，我的客户大概有二十个，日均流量约为 3T。大部分客户都是像我一样的独立开发者，他们自己研发产品并进行运营，获得盈利。此外，还有一些小团队在使用我的服务。

流量的大头是客户端的安装包/更新包的下载，其次是图片文件。

我对客户的接入标准非常严格，基本上每个申请接入的产品我都会进行人工考察。对于一些可能存在内容审核风险的产品，比如图床类和海外加速类，我会拒绝接入。同时，我要求客户的产品域名经过备案，并确保服务器位于大陆境内。此外，客户的产品必须已经运营，并且月流量不低于 200G。我的想法是，客户的质量比数量更重要。

怎么做宣传的？

我的整体运营方式比较佛系，主要通过在网上发帖进行宣传。我并不依赖这个产品来谋生，只是把它当作零花钱。虽然零花钱越多越好，我还是会认真维护这个项目，因为我的其他盈利产品也在使用这个 CDN。

主要的客源渠道是独立开发者社区 w2sole、V2EX、learnku、以及知乎。虽然我尝试过其他渠道，但阅读量并不理想。

两年多里做了什么改进？

整体思路与之前的文章类似，依然是通过 302 跳转实现调度到不同地域节点。这两年间，我进行了断断续续的改进，主要包括：

优化节点监控机制
提升系统稳定性
将调度服务器和节点服务器实现 Docker 化
实现分布式同步 HTTPS 证书
节点服务器改用默认标准端口
支持客户申请开发票
重构官网和管理控制台 UI

踩过什么坑吗？

最大的坑是我不应该使用拨号服务器。拨号服务器是一种托管在机房但使用家宽拨号上网的机器（与 PCDN 不同，PCDN 是用户在家里部署的机器）。这种机器的网络性价比很高，所以我一开始使用了它作为调度节点之一。

然而，运营商在打击 PCDN 的同时，也对这种服务器的上网账号进行了限制，导致网络严格受限。我并不担心机器一开始就挂掉，因为调度服务器会自动切换到其他节点。但我比较担心的是，机器正常使用时却会无规律地限制带宽。

从客户的反馈来看，这会体现为，流量大时部分文件下载会变得很慢。一开始我很困惑，因为这是部分节点无规律出现的问题，难以找到规律。后来才发现是运营商的限制。因此，我也失去了几个大客户。去年，我开始全面放弃拨号服务器，转而使用正常机房带宽的服务器，现在整体稳定性已经提升，能够应对大流量的突发高峰。

目前已知的不支持的功能特性

绑定自定义域名
在运营过程中发现，实际上需要绑定域名的客户并不多。大部分客户都有一定的技术能力，能够自行进行容灾切换，域名并不是特别重要，修改代码切换到另一个 URL 也很容易。
大视频加速
大视频文件对服务器磁盘缓存空间的要求很高，服务器存储费用往往超过流量费用，这让我面临亏损。因此，我通常会友好地劝退这类客户。

最后，附上官网地址： https://www.dfyun.com.cn/ ，有需求的朋友可以支持下。

我是如何把网站图片 cdn 流量成本压到全网最低 (之一) 的

star7th — Mon, 05 Sep 2022 09:50:42 +0800

缘起

我经营的一些网站和产品的访问量越来越高，付出的 cdn 流量成本（主要是图片资源）也越来越大。抱着节省成本的想法，我尝试在网络上找下有没有便宜的 cdn 商家。像阿里云、腾讯云、七牛云，这些公有云 cdn 的价格都大同小异，我感觉即使从这一家换到另一家，也节省不了多少成本，同时还增加了迁移的麻烦。因此我把目光投向传统机房，预感可能越接近机器底层，能优化的空间越大。

经过几天的考察，发现很多非热门地区的机房都或多或少都有一些闲置的优惠产品，甚至其中也不乏优质带宽机器。特别是三四线机房，线路测试其实还不错。很明显这些闲置资源没有得到充分利用。一个点子在我脑海中酝酿了。

使用开源 or 自己原创？

假如我把各地的闲置机器组织起来，把它们当成一个个节点，组建起一个分布式网络，自动容灾切换，岂不就是一个廉价的自建 cdn 方案了？顺着这个思路，我去找一下开源的 cdn 软件，看看有没有现成的解决方案。

然而事情没有我想的那么简单。开源 cdn 并没有很好的容灾切换机制，无法实时避障。它核心原理里，用域名 cname 的方式指向某个节点 ip，当节点挂了的时候，由于域名 cname 解析变更有 10 分钟以上的缓存，所以必定会导致用户有一段时间的访问故障。我现在探索的是把各地机房集成到一起，其中机器节点的可靠性是参差不齐的。如果想做成一套 cdn，那么就必须要假设节点是不可靠的，随时可能故障的，然后为此设计一套完善的容灾解决方案。

既然找不到现成的开源解决方案，那就自己动手写代码实现吧。

基本逻辑

我边啃着玉米，边用笔在纸上画着逻辑交互图。经过一阵子的反复斟酌，基本逻辑已经成型。

1，这套程序主要有两个角色，调度服务器和节点服务器。调度服务器架设在阿里云 k8s 上，保障高可用。而节点服务器则是分布在各地机房，做好可能会故障、随时容灾切换的准备。

2，调度服务器的作用是导流和容灾，将用户流量以重定向的方式导向可用的节点，同时避开故障节点，做到实时无缝切换。

3，节点服务器的主要作用是拉取源文件到本地缓存，从而被用户访问。

4，节点服务器跟调度服务器之间要用某 tcp 协议实时连接监控，监控粒度细分到每个文件，方便调度服务器实时避开故障节点，这样才能保证故障时候，用户访问的每个链接都可以正常切换访问。这里实时性是非常重要的，也是容灾方案的核心。

小试牛刀

于是我花了一个多月的时间去写代码来实现这个逻辑。核心代码其实写得很快，但是为了保障稳定性，增加了非常多的异常容灾措施，要花时间不断测试不断重写。初期只放三个异地机房节点，把流量切进来看看。为了保险起见，先从小的做起。我一开始切日均 10G 流量过去，让它跑几天。几天后，没问题。试试日均 50G 流量？ 50G 跑了几天，ok。日均 300G ？依然正常运行。

开放商用

现在，已经完美运行了一个月，每天承受超过 1000G 流量，暂时没发现有故障现象。我以及一些朋友的很多产品都在用。我刻意关掉其中一个节点，调度服务器马上切流量到其他节点。我刻意关闭全部节点，流量也马上转到源站。整个过程中，只要调度服务器正常运作，那么，无论节点故障与否，用户都将继续无感知地正常访问图片。而调度服务器直接运行在阿里云 k8s 上，可靠性是非常高的。因此整套架构的可靠性很高。有了这个架构，如果需要承受更大流量，我只需要增加节点数即可。而全国范围内的机房机器多的是，我可以随时租机器来新增节点。当我意识到有规模化运作大流量的可能性后，我决定把 cdn 能力包装出去，商业化运作。于是注册并备案了大风云网，访问地址是 www.dfyun.com.cn

结语

大风云 www.dfyun.com.cn 严格来讲不是传统 cdn ，它是另一种内容分发机制，基于传统 cdn 以及传统机房机器，用软件技术实现资源整合，是应用层面的一种微创新，在图片访问，文件下载等这些场景下可以成倍地降低流量成本，成本低于 0.05G/元，降低到公有云 cdn 价格的四分之一以下（只对比平时价格，不考虑搞活动的临时特价），几乎是全网 cdn 流量成本最低之一了。

内网穿透【搞一下】

star7th — Wed, 10 Aug 2022 10:02:03 +0800

场景入门介绍

老板找到产品经理，说：“客户想看一下项目，你搞一下，把 demo 网站搭起来”

产品经理找到技术组长，说：“客户想看一下项目，你搞一下，让客户能访问 demo 网站”

技术组长找到程序员小 A，说：“客户想看一下项目，你搞一下,让他访问到你做的 demo 网站”

小 A: “我的 demo 在开发中，还在我的电脑本地，怎么搞？？？”

组长扔来一个文档链接：“按这个说明去【搞一下】”。

内网穿透搞一下

【搞一下】（ www.gaoyixia.com ) ，是一个可以把本机和局域网网站映射到公网访问的内网穿透服务。使用非常简单，几乎无门槛——无须注册，无须付费，不限流量，不需繁琐的配置，支持 win/mac/linux 三大平台。下面是三个典型的使用场景：

1，可以使用本服务，映射本机 demo 给客户展示，而不用大费周折去搭建一个临时公网测试环境。

2，小程序开发，公众号开发，微信支付开发，支付宝回调等等，这些回调类的接口可以通过本服务，直接回调接口到本机，方便本机调试。省去了每次调试都更新服务器的麻烦。

3，家里有电脑/nas 的机器，可以映射 web 管理界面到公网去，方便出门在外时候用网络访问。

还有更多使用场景待挖掘。本服务提供的是一种能力，一种可以让本机和局域网能被公网访问的能力。

如何使用

window 用户

点击下载 gaoyixia-win.zip 。下载后，解压到任意目录。然后双击运行。根据提示，输入要映射的本机或者局域网地址端口即可。运行后会得到一个公网地址，复制到浏览器便可访问（不要直接 Crtl + C 复制，会退出程序,推荐鼠标选中复制）。

mac 用户

打开终端，执行以下命令

# 下载执行文件 
wget -c "https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=f9bde9f10b6d1fdb26ca353f49bf89c6" -O gaoyixia-macos

# 赋予执行权限
chmod +x gaoyixia-macos
# 运行
./gaoyixia-macos -h 127.0.0.1 - p 80
# 运行后会得到一个公网地址，复制到浏览器访问即可（不要直接Crtl + C 复制，会退出程序,推荐鼠标选中复制）。
# 上面命令中的-h 127.0.0.1 - p 80表示的是地址和端口。你也可以填写局域网地址。比如
./gaoyixia-macos -h local.oa.com -p 80

linux 用户

打开终端，执行以下命令

# 下载执行文件
wget -c "https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=e491f057ff8e77dedcdf1b3d7560eb4d" -O gaoyixia-linux

# 赋予执行权限
chmod +x gaoyixia-linux
# 运行
./gaoyixia-linux -h 127.0.0.1 -p 80
# 运行后会得到一个公网地址，复制到浏览器访问即可（不要直接Crtl + C 复制，会退出程序,推荐鼠标选中复制）。
# 上面命令中的-h 127.0.0.1 - p 80表示的是地址和端口。你也可以填写局域网地址。比如
./gaoyixia-linux -h local.oa.com -p 80

帮助与支持

请联系 xing7th#gmail.com(把 # 改为 @ 就是邮箱地址),邮件标题请说明来自内网穿透【搞一下】这个产品。

我是如何把 github 开源项目做到 5300+ star 的

star7th — Mon, 13 Jan 2020 11:27:12 +0800

前言

我开发的开源文档工具在 github 上上升到了 5300+ 的 star ，受到了部分开发者的欢迎。于是便想写与大家分享一下我在整个创作过程中所用到的技术以及相关技能。

任务管理

无论是做自己规划的产品功能，还是做用户反馈过来的 bug，最终都需要把这些点细化成一个个单独的小任务，串联执行（毕竟自己是单个人力）。在这点上，我主要是利用团队看板来实现我的任务管理。团队看板工具有好多，搜索一下就好，我个人目前在用 tower.im

看板上我新建五个清单，分别是 “在做”、“要做 - 高优先级”、“要做 - 低优先级”、“待定”、“遗留问题”，我这样分类是有技巧的。首先，它有优先级划分，保证先做重要的事。其次，它有状态管理，方便我随时中断某个任务，过一段时间再回来继续任务。同时，它也能应对新任务——比如说新需求进来，我先放在 “待定”，等有空了再分配到其他清单去。最后，它还有 “遗留问题” 清单，可以让我不在某个 “疑难杂症” 上卡住太多时间，快速推进下一个任务。

本地开发

用 Linux 或者 MAC 会非常方便开发、搭建测试环境等，对开发者的方便是毋庸置疑的。但是电脑有时候需要玩游戏，需要装一些专业大型软件。从兼容性和广泛性的角度来考虑，我个人还是使用 windows 系统。在 win 上，我使用的是 Vagrant + virtualbox 这个组合。Vagrant 是一套工具，帮助你快速在 win 系统上，利用 virtualbox 搭建起虚拟机，从而方便使用 linux 或者 MAC(比如上架苹果 app 的时候我需要 MAC 虚拟机)。关于这点，可以参考我几年前写的一篇教程：blog.star7th.com/2015/06/1538.html

代码管理

我用 git 作为代码版本管理工具，同时使用 tortoisegit 进行可视化操作。说一下我是怎么维护官网在线版 showdoc 和开源版 showdoc 的。我在自己的服务器安装一个私有版的 gogs 作为私有 git 管理平台。功能开发好了，我再推送到 github 上去。官网版和开源版一开始是同一个仓库里的不同分支。后面它们的差异（尤其是后端代码的差异）越来越大，所以我干脆把它们分成两个不同的仓库了。做开发的时候，我一般是现在官网版上做开发以及测试验证，然后再用 tortoisegit 的代码修改差异比较功能，把功能迁移到开源版去。

说一下分支管理策略。我至少建立两个分支——主分支和开发分支。新功能会在开发分支做，验证好了再合并到主分支来。用开发分支的时候也有技巧。比如说，一个大的功能可以基于开发分支再新开一个分支去做。例如我今天想做 A 功能，那就在 A 分支上操作。但是 A 功能遇到瓶颈了，这会儿我暂时没精力去找 bug，所以此时我可以再基于开发分支开启 B 分支，继续做 B 功能。这很重要，因为在人力有限的情况下，我做什么事情都是串联的，同一时刻只能做一件事。这样的策略有利于保证自己随时中断、随时上手任务，灵活地安排不同的时间去处理容易的或者棘手的问题。这个过程也需要配合上面说到的团队看板使用。中断前要记录好进度，方便自己随时恢复工作。

shell 自动化脚本

我为 showdo 写了三个 shell 自动化脚本。其作用分别是自动化部署 showdoc，自动生成 api 文档到 showdoc，自动生成数据字典到 showdoc。之所以选择 shell 而不是其他脚本语言（如 python），是因为 shell 基本可以运行在绝大部分 linux 上，部分运行到 win 上（需要安装工具），兼容性超好，依赖非常少。根据反馈，受到的好评比负面评论多得多。自动化脚本大大节省了使用者安装环境的麻烦，降低了 showdoc 的使用门槛。showdoc 大部分的用户不是 php 开发者，要他们安装 php 环境还是挺折腾的。有了一键脚本，他们用得方便，我也省心，不需要在解决新手反馈上花太多功夫。这个方法是具有普适性的，并且语言无关（因为一键脚本使用 docker 跑服务）。是可以大量应用到开源项目中，非常有利于开源项目的代码分发。

顺便强调一下，做 web 应用开发的人，尤其需要克服一下对 shell 脚本的疏远感。我以前以 web 开发为主的时候就会潜意识地疏远 shell。在腾讯的时候向另一个技术栈的同事请教了下，发现其实还是蛮简单的。只是因为自己过去心理上的疏远感导致自己没想过要去写 shell。跨过这个心理槛，就会扩展自身的能力边界，写起来跟其他语言没有太多区别，仅仅是需要多搜索查询下语法而已。

后端开发

可能是因为 showdoc 仅是一个小产品，涉及到的后台逻辑并不复杂，所以我在开发后端花的时间不多，基本上都是 CRUD，对数据库进行增删改查操作。需要多动点脑力的地方在于团队管理功能，新建多几张数据表联合实现精细化权限控制。

showdoc 后端主要采用的是国产框架 thinkPHP。这个框架有好也有不好。不好的地方在于它的框架约定、生态共享比较一般，好的地方在于它可以快速撸出一个东西来，而且兼容性还可以。这是四年前我刚开发 showdoc 时的决定，后来也懒得换框架重写了，所以沿用至今。技术是相对落后了一些，但是也胜在兼容性好，可以兼容老的 php 环境和一些老的服务器。这个还是挺重要的，因为 showdoc 是开发辅助性质的工具，协助写文档。兼容性越好就越容易被各种各样的群体接受。个人觉得这一点比用各种先进技术要更实用一些。当然了，如果是现在新开发其他项目，我应该会使用 laravel，或者 NodeJS 写的 eggjs。

前端开发和 UI

我在前端开发上花费的时间比后端开发时间多很多。可能是因为这是个体验型产品，需要把前端体验做好。起步一个产品的前端页面时候，我建议一定要选好一个 UI 框架。比如我选择的是 ElementUI 做 showdoc，而 runapi 则使用 museUI（runapi 是辅助 showdoc 用的一个在线 api 测试工具）。

showdoc 用的编辑器是 editor.md，是几年前的产品。虽然说它代码组织方式可能有点落后，且原作者似乎有放弃维护的趋势。但我觉得它功能强大且简洁美观，所以我花了时间将它封装成了 vue 组件，并且修改其源码增加了安全性。

项目拖拽和页面排序我用的是 vue 组件 vuedraggable，还蛮好用的。以后有拖拽的需求我估计还是用它。

图标设计方面，可以使用 UI 框架内置的字体图标，也可以用阿里妈妈的矢量图标库。或者自己使用 Iconion 进行图标设计。这里我强调一下 Iconion。这个工具可以非常简单快捷地使用一些预定的图案和背景，组合成一个快速可用的产品图标。showdc 的产品图标就是这样制作的，快速省时地做到媲美专业的效果。如果以后把产品做大了，可以考虑请设计师设计。但在项目前期，用 Iconion 就够了。

在这里要提一下前端技能的重要性。虽然说 UI 框架以及相应的工具能够帮助你节省很多时间。但如果想做好一个产品的体验，那么其涉及到的 UI 和交互可能超出框架自带的范围。因此自己必须学会使用原生 css，会 js 交互，会封装组件。而且，前端技能跟下面要说的 app 多端开发也有帮助。

app 多端开发

关于移动 app 产品原型设计，我很建议使用 “墨刀” 来做简单的原型规划。有了一个可视化的原型，真的能节省很多大脑时间，让你在开发阶段的时候可以专注代码，而不需要写一下代码，又回头思考下一步做什么功能，这样的来回切换相当耽误效率。

app 开发我用的是 uniapp，使用 html5 等前端技术把代码封装成手机本地 app，包括安卓 app、苹果 app，甚至小程序。这种技术几年前就有了，但是性能一直不温不火。2019 年的时候我看到了这块发展得还是可以的。所以就产生了做 showdoc app 端的想法。不过由于 showdoc 重在 pc web 端，手机只是起到辅助作用，所以我没有很精心去做。大概把 web 版简化一下，复用一些组件，重写下前端，然后就上线了。顺便说一下，我做得比较精细化的 app 是时光树洞（blog.star7th.com/2019/09/2380.html) ，这款 app 的 UI 就花了点心思。

如果要让我评价这种混合型 app 和原生 app，我会说，肯定原生 app 最好。只是出于成本和人力的考虑，对一些展示型的、交互体验要求不那么高的产品，可以采用这种 h5 技术处理。大家如果在验证市场阶段，可以采用类似技术快速做一个可用产品出来。

此外说一下苹果 app 上架的问题。我是利用虚拟机安装了一个黑苹果系统，然后装相应工具，把 app 上传到苹果商店去。关于如何开通苹果开发者账号，如何在虚拟机安装苹果系统，这个你可以自行搜索。

用户反馈和社区运营

一开始，用户反馈消耗了我不少精力。敢情自己成为一个客服了。后来我开始做了一些改变，基本把自己从这些反馈中抽身出来了。

首先我分开了官网在线版和开源版的反馈，开源版的反馈统一到 github（gitbug 的使用门槛能过滤掉一些非常新的新手，避免新手问题），在线版的反馈统一发邮箱。有功能或者 bug 要改，我先记在团队看板。而对于一些常见问题，我整理好了文档，和一些固定的回复术语。另外我也开了三个 qq 群，供 showdoc 使用者自身交流。不过我要提的一点是，千万别试图回答 qq 群里提的每一个问题，会把人逼疯的。所以我更改了群公告，改写了群定位，将 qq 群定位为用户自行交流的地方。让热心用户去回答新手在使用 showdoc 时遇到的问题。而我则只需要很偶尔看一下。需要官方的支持还是让用户走 github 或者邮件通道。

不过值得一提的是，我这种运营思路是不适合所有团队的。我是人力有限，效率优先，所以过滤了很多不太必要的反馈。假如说有很足够的人力，我倒建议可以多花时间帮助用户解决问题，既扩大用户量，又提高产品口碑。