我是怎么被 套牢的其实从年头上讲, 和我在这件事情上打交道的时间, 也算得是有了几年的历程了。最早的时候, 他们只是把它当作 CDN 和 DNS 托管来用——因为域名解析的速度很快, 而且是免费的, 还带有 DDoS 防护功能, 这对于小站长来说简直就像是凭空捡到便宜一样。后来新的平台或技术出来了, 人们发现可以在边缘服务器上运行代码, 于是就开始把一些轻量级的服务迁移到上面去。再后来, AI 功能对外开放, 免费使用的额度还给得很大方, 以至于连 AI 推理的任务都开始往上面跑了。用的次数多了, 注册的账户数量也就跟着增加。这背后有许多理由支撑, 包括实现业务层面的相互隔离、把免费使用额度用到最大以及对新功能进行小范围测试等等, 能找出的说法简直不一而足。就在这不知不觉之间, 手里竟然积累出了三个不同的账号。至于我是怎么清楚这一点的, 大家心知肚明, 这也是该平台常见的一种操作伎俩。说白了, 就是面对那些无需付费的服务内容, 用户往往会在使用的过程中慢慢产生难以割舍的依赖情结以至于最终陷入沉迷状态之中三个账户三套后台然后问题就出现了。官方 的功能确实是相当齐全的, 可是他们在进行设计规划的时候, 完全就把“一个人要去管理多个账户”这样一种实际存在的场景给忽略掉了, CLI 这个方面的能力确实是非常强劲的, 但是它更加适合那些通过编写代码来进行部署工作的环节, 而完全不不适合用来处理日常的那些运维工作啊, 比如说只是想要看一下自己的配额还有多少, 稍微修改一条规则或者清理一下缓存这样的简单操作, 你肯定是不愿意去打开那个终端然后用手指头去敲命令的。在现在的大众市场上, 确实也有一些通过第三方开发的实用工具处于活跃状态, 然而这些工具普遍存在功能单一的局限性, 它们其中的一些仅仅专注于对域名系统进行独立管理, 而另外的则专门负责其他特定环节的工作, 始终找不到一个能够真正将核心产品线各个部分有效地连接与整合在一起的产品。所以说, CF 就是在这种情况下存在的。它的目的可不是要去取代那个官方的平台产品, 而是想把在各个账户上面每天都要做上好多遍的那个高频率的操作工作, 全都集中汇聚到仅仅一个操作界面里面来, 让用户只需要看一眼屏幕就能够立马搞清楚所有那些账号的当前的状况如何, 然后只要执行了那么一次性的操作动作, 就能够在不同的账号之间实现这个操作的跨出界限一样的执行效果。从 DNS 开始一路长出来的功能树在最初的时候, 其实大家心里面仅仅只有一个想法, 那就是去制作一个专门用于管理 DNS 的面板工具。因为 DNS 是多账户场景里最烦人的——十几条记录散落在不同 Zone 里改个 CNAME 得先找到它在哪个账户再切过去操作。于是第一版只有一个功能多账户 Zone 汇总 DNS 记录 CRUD。可是做着做着就觉得没法停下来。你能看到相关的记录, 心里自然就想要去修改 Zone 设置既然决定了要改设置, 心里自然就会想着去把缓存给清楚掉已经清完缓存了, 心里自然又会想去暂停激活 Zone, 从而去看看实际的效果。于是关于 Zone 的批量创建与删除、SSL/TLS 模式的切换、缓存的清除处理, 以及功能的暂停和激活, 这些操作需求就顺理成章地让这组功能慢慢多了起来。随后, 我们加入了 Pages 管理模块。这个功能隶属于最核心的产品线范畴。跨账户批量部署是一个极具刚性的需求场景。因为大家肯定不愿意耗费精力去手动执行相同的脚本安装操作至三个不同的账户之中。这一点只要实际尝试过的人都非常清楚其中的痛点。在操作过程中, 你需要频繁地在三个浏览器标签页之间进行切换动作。当你忙着处理第二个页面时, 往往会忘记之前在第一个页面配好了哪些内容。鉴于此, 当前的部署流程得到了简化与优化。其具体步骤依次为: 首先选中多个需要操作的目标账户对象。接着填写所要使用的脚本名称。最后点击界面中的那个一键部署按钮即可完成提交工作。倘若某些特定的账户在执行该任务时遭遇了失败的情况。用户还可以对这些失败的独立个体发起单独的重试请求。环境变量、KV与D1和R2之间的绑定关系、路由规则以及自定义域名的设置, 这些配置内容都可以在控制面板里面直接进行修改, 根本用不着去打开所谓的 .toml 文件来动手操作。这里还有一个特别实用的细节情况需要告诉大家, 就是在执行重新部署这一动作的时候, 完全可以做到只更新配置信息这一点具体来说, 当你只是修改了一个环境变量的值之后, 后端系统只会调用相应的 API 接口来完成更新, 而不会再次传输代码文件, 这样做的好处是让速度变得快了许多。存储管理是配套的基础设施建设。你能够通过访问KV键值对的增加、删除、修改和查询功能, 使用D1直接利用SQL语句来更改表的数据库结构, 借助R2实现文件的上传、下载与预览查看。整个过程十分便捷, 你甚至根本不需要离开这个面板平台, 就可以轻松完成这些涉及存储层的日常操作流程。接下来还要涉及到对隧道的使用以及实现回源功能。这个功能本身是非常好的, 但是在进行配置规则编写的时候, 也就是要把域名映射到具体的服务上面去的时候, 需要在 JSON 这样的文件里面手动输入大量的符号和代码片段。这样做的话是很容易出现拼写错误的。为了解决这个问题, 我专门设计并开发了一个可视化的编辑界面。在这个界面上, 大家可以非常直观地进行操作, 包括拆分子域名、选择使用的协议、配置相应的端口等等, 所有这些都可以通过六列数据来进行直接的编辑管理。此外, 我还提供了一个非常方便的一键回源向导功能。通过这一个向导, 如果需要新建或者是想要复用原来的资源, 就可以自动帮助我们创建 DNS CNAME 记录, 并且完成相关的配置工作, 整个过程只需要经过三个简单的步骤就能全部搞定。规则引擎属于进阶功能, 虽然 API 的功能非常齐全, 但是上手起来的门槛也比较高, 因为涉及到回源、 URL 重写、请求头或者响应头转换、缓存、防火墙、限速以及重定向等等这八种不同的规则类型, 而且每一种规则类型的 API 格式都是完全不相同的, 所以我们设计了两个层级, 默认采用的是结构化的表单形式, 也就是小白模式, 用户只需要在下拉框里选择一个规则的 type, 然后再填写几个关键的参数就可以了, 在需要更加精细地进行控制的时候再去切换到高级模式, 这样就可以直接写出 JSON 数据了。它还内置了一个用来生成表达式的工具。只要你选好匹配类型, 再填上子域名和路径, 它就能自动把表达式给你生成好。这样就不用去翻那些文档去查相关的语法问题了。AI 和渲染最让我兴奋的两个模块前面所说的那些内容属于运维方面的一种必要需求, 而人工智能工作台以及浏览器渲染技术这部分, 才是真正具有趣味性且有趣的地方。AI 这个东西实际上是非常不错的, 因为它的免费额度给得很大方, 模型的覆盖范围也很广泛, 既包括对话功能, 也包括文字变成图片、语音合成以及翻译等等这些功能。但是因为官方那边并没有提供一个统一的用于调试的界面, 所以用户必须自己去搭建那个可以通过 API 进行调用的环境, 而如果想要实现多个账户之间的轮询操作的话, 还需要自己编写用于安排调度任务的逻辑代码。优采云 AI 把这些东西全部塞进一个界面里面, 它支持对话功能, 文生图或者图生图的功能, TTS 语音合成功能, 翻译这四个 Tab 标签页, 用户可以一键进行切换, 系统会自动对多账户进行调度, 哪个账户的额度充足就使用哪个账户来干活, 它还做了感知的神经元计费这一项工作, 缓存命中的 token 按照大约五分之一的价格来计算, 这个计费方式跟官方的计费逻辑是对齐的。每一张生成出来的图片还有每一段合成出来的语音, 它们都会显示出实际消耗掉的神经元数量, 这样你就可以对使用量这件事心里面清楚明白。更实用的一点是, 它对外面暴露出了那一套和API能兼容的东西, 比如/v1/chat/、/v1//、/v1/audio/、/v1/、/v1/这几个路径, 流式的那种和非流式的两种模式它都支持着。这种状况意味着什么?这意味着你能够把CF这个玩意儿当成是你本地那些工具链条里的AI后端来使唤一下, 像那个、、还有Aider这些个工具, 你给配上对应的 之后就可以直接拿着用了, 而且这一切的操作过程全都是走的 提供的哪一个免费的那个额度部分。这个接口的使用范围是内网本地调试, 它不是对外服务。浏览器渲染是另一个实用的模块, 你可以利用它来远程控制无头浏览器, 去完成截图操作、生成/pdf文档以及提取链接任务, 我这边封装了五种不同的模式, 分别是进行截图的工作、完成/html内容的提取动作、实现转换处理、执行/pdf生成步骤以及对链接进行提取, 该模块内置有令牌桶限流机制以及配额管理功能, 如果你拿它来做网页截图的事情, 或者将文章转换为/pdf格式的需求, 又或者是要做批量采集链接这类项目, 都会觉得十分方便。在安全领域, 该系统同样部署了针对SSRF的攻击防护措施, 以此来避免遭受利用以执行对内网进行扫描的操作。双后端架构两个场景一套代码CF支持两种部署方式, 一种是自建, 另一种是Pages零成本部署。这背后的意思, 是你得去搞清楚两件完全不一样的事情, 这两件事, 它们各自有一套完全不同的运行环境。具体来说, 那一种版本, 是使用版用加上那个符号来配置的, 它是在你的 VPS 上面跑的。还有一种是 Pages 版, 它是用 Hono 加上 D1 来配置的, 它是在边缘网络里面跑着的。但是呢, 这两个版本的前端部分, 使用的是同一套 Vue 代码, 而 API 接口的格式, 也是完全一致的。关键设计是共享数据层。那些被称作“唯一真实来源”的东西, 比如AI模型的定价信息, 会被放在共享目录里。然后会有脚本把它们自动同步到两端的系统里面去。这么做是为了保证数据的一致性问题得到解决并且能够保持数据的一致状态。当你切换使用的部署方式的时候, 你获得的体验是完全一样的状况发生在你身上的。在加密这个方面, 我们也遇到过一些困难。前端使用 Node.js 模块来进行 AES 加密, 这样进行操作是没有问题的, 但是小程序端或者是其他非 Node 环境并没有 Node.js运行环境, 所以必须更换成使用 noble/ 这套纯粹的 实现方案来解决问题。需要确保两侧使用的算法是完全一模一样的, 要不然会出现这样的情况, 那就是从这一端存入进去的密钥如果换到另一端的读取方式来操作的话, 可能是读不出来的。在多语言国际化这件琐事上, 也是来回折腾了一番。vue-i18n 这个东西本身用起来不难, 可是要负责提取、翻译以及维护那一千多个词条的工作量, 完全属于个体力活。面对有些专有名词, 像是 “Zone”、“”、“”, 在中文字幕场景下到底要不要进行翻译成中文的选择, 是让人纠结了好久。最后拍板决定保留那些英文术语不动, 而把界面上的文案全部换成中文, 这么做的主要目的就是为了避免因为强行翻译反而会导致用户理解的难度变得更大。请你设身处地想一想, 如果你把 “” 这个概念直接翻译为“入口”, 又把另一个空内容翻译成“规则集”, 那么用户看到这两个词时, 他们的第一个直觉反应绝对会是, “这到底是什么意思啊? ”。另外有一个通常被大家所忽视, 然而在实际操作中却非常重要的东西, 那就是网络出口管理。在多账户使用的场景之中, 让不同的账户去走各自不同的出口 IP 地址, 这样能够让访问的速度和稳定性变得更好。这个品牌支持全局范围的这种网络出口的配配方式, 也支持和账号级别相独立的配置方式。具体来说就是每个账号都可以绑定上不一样的出口 IP 地址。除此之外它还集成了 Resin 这个代理服务池子, 一旦完成了相应的配置之后, 它就能自动地为每一个账号都生成出 IP 地址, 从而实现一个账号对应一个稳定的出口 IP 的效果, 彼此之间完全不会互相产生干扰。优先级是这样安排的, 具体来说就是账户专属优先级别最高, 接着是Resin代理池, 然后是全局配置, 最后是直连。踩过的坑讲出几个给你留下印象比较深的人或者事来。