2. Linux.do
  3. CPA-Manager-Plus 2.0 准备开工了，简单说一下这次准备怎么改

CPA-Manager-Plus 2.0 准备开工了，简单说一下这次准备怎么改

seakee 2026-08-17 10:48 1

前面其实在评论区提过几次 CPAMP 2.0，最近也一直在整理 2.0 的架构和后续方向，现在整体方案基本确定了，所以单独开个帖子和大家同步一下。


CPAMP 从最开始其实只是一个 CPA 的管理面板，后面慢慢加了请求监控、用量统计、账号巡检、Provider、凭证管理、额度管理等等东西。


功能越来越多以后，现在这种 CPA + CPAMP 两套服务独立部署、CPAMP 再通过 Management API 管理 CPA 的方式，很多地方已经开始限制后续功能继续往下做了。


所以 2.0 准备直接把这个问题解决掉。


2.0 最大的变化：CPA 会直接作为 CPAMP 的网关内核


目前使用 CPAMP 完整版，需要同时运行：




  • CPA




  • CPAMP




2.0 会把 CPA 直接作为网关内核集成进 CPAMP。


但是这里不是简单把两个项目代码揉到一起。


内部还是会拆成两个独立 runtime：




  • CPA Runtime：负责真正的 API 请求、Provider、账号调度这些网关能力




  • CPAMP Runtime：负责管理、监控、统计、配置、巡检这些能力




对于普通用户来说，最终就是一个 CPAMP，不需要再单独部署和维护两个容器。


CPA 还是 CPA，只是 CPAMP 可以直接管理自己的 CPA Runtime 了。


从 1.x 升级不会要求重新配置


这个也是我现在比较优先考虑的问题。


2.0 第一次启动会有一个迁移向导，现有 CPAMP 用户可以直接迁移原来的配置和数据。


目前计划会有两个选择：


1. 使用 CPAMP 内置 CPA Runtime


这个会是默认推荐的方式。


现有 CPA 配置迁移进来以后，以后 CPA 和 CPAMP 就作为一个整体维护。


2. 继续连接外部 CPA


如果现在有比较复杂的部署方式，或者暂时不想迁移，也可以继续使用原来的 CPA。


所以不会出现升级 2.0 以后必须重新折腾一遍部署的问题。


API 流量也会真正进入 CPAMP 的整体架构


现在 CPAMP 本质上还是 CPA 的旁路管理服务。


到了 2.0 以后，因为 CPA Runtime 已经属于 CPAMP 本身，很多之前不好做或者做起来比较别扭的事情就可以真正做了。


比如：




  • API Key 更完整的管理




  • 每个 Key 的 Token / 费用限制




  • 请求级别的安全控制




  • 自定义 API 前缀




  • 自定义管理面板前缀




  • 异常请求检测和拦截




  • 更完整的通知能力




  • Runtime 状态和故障诊断




还有之前很多佬提过的一些安全相关功能，也会在这个架构下面重新考虑。


这些目前都属于 2.0 的方向，不代表首个 2.0 版本会一次全部做完。


架构先搭好，功能后面慢慢补。


2.0 也会顺便把现在的一些历史债清掉


CPAMP 一路从一个 management.html 慢慢加到现在，代码里面其实已经积累不少历史包袱了 Image: ^-^


2.0 会趁这个机会重新整理：




  • 前后端彻底分离




  • Manager Server 模块重新拆分




  • CPA / CPAMP Runtime 边界




  • 配置和数据结构




  • 请求链路




  • 安全边界




  • management.html 这个大一体彻底退出主架构




这部分用户可能看不到特别明显的功能变化，但是对后面长期维护比较重要。


不然继续在现在架构上不停往上叠功能，我感觉迟早要把自己埋进去 Image: ^-^


还有一个边界提前说一下


CPAMP 2.0 不会往 New API / Sub2API 那种公共 API 分发平台方向发展。


CPAMP 最主要的定位还是：


个人使用 + 自托管 + 小团队有限共享。


可以做 API Key，可以限制额度，也可以给家里、朋友或者小团队使用。


但是不会去做复杂的多租户、充值、计费、套餐、代理商这些商业运营系统。


这些东西一旦做进去，项目的复杂度和长期维护成本会直接变成另外一个级别。


这个边界目前不会变。


1.x 不会马上停止维护


2.0 开发期间 1.x 还是当前稳定主线。


Bug、CPA 兼容、安全问题这些该修还是会继续修。


我也不会为了赶 2.0 把一个还不能正常迁移和使用的版本直接丢出来。


等 Runtime、迁移和基础链路稳定以后，才会开始让 1.x 用户正式迁移。



CPAMP 从最开始做到现在，很多功能其实都是 Linux Do 上面的佬提出来，然后一点一点加进去的。


有些需求最后做了，有些需求因为架构或者项目边界没有做，也有不少 PR 和 issue 帮我发现了之前根本没考虑到的问题。


所以 2.0 现在虽然大的方向已经确定了，但具体功能还是可以继续讨论。


大家有什么觉得 “如果 CPA 真正内置以后，这个功能就应该有了” 的，可以继续在下面提。


我再看看能不能给自己多挖几个坑 Image: ^-^


也再次感谢各位佬对 CPAMP 这么长时间的支持，以及优秀的建议与提议。


项目地址：


最新回复 (19)
  • 忒 08-17 10:51
    1楼

    大佬真牛掰，2.0确实解决了几个痛点问题。期待早日发布

  • Starry4785 08-17 11:01
    2楼

    如果这样的话 那佬要怎么及时跟进最新的 cpa 版本是个比较大的问题 ^-^

  • seakee 楼主 08-17 11:03
    3楼

    CPAMP 可以管理内置 CPA 的整个生命周期，可以设置自动更新或者手动更新，CPAMP 本身也会使用现在的策略，及时的更新对 CPA 的适配，CPA 维护者也会第一时间告知我们版本变化的。

  • 2咚个隆咚锵2 08-17 11:03
    4楼

    如果我没记错的话，先是CPA把管理端拆出去了专注做转发，现在这是管理端要把CPA再绑回去，那你还能跟得上CPA的更新速度吗？有时候真是觉得世界是个草台班子。

  • xcafe 08-17 11:04
    5楼

    希望可以内置一些伪装header参数，现在有些站为了防止二次分发，只允许在codex、cc客户端使用，但是CPA只是个人使用，不想频繁切换配置文件，尤其是codex的配置文件，简直是灾难级别。cc的配置文件只需要改url和key，codex里面好多MCP之类的配置。

  • seakee 楼主 08-17 11:06
    6楼

    但是这里不是简单把两个项目代码揉到一起。


    内部还是会拆成两个独立 runtime：




    • CPA Runtime：负责真正的 API 请求、Provider、账号调度这些网关能力




    • CPAMP Runtime：负责管理、监控、统计、配置、巡检这些能力




    对于普通用户来说，最终就是一个 CPAMP，不需要再单独部署和维护两个容器。


    CPA 还是 CPA，只是 CPAMP 可以直接管理自己的 CPA Runtime 了。



    内置 CPA，然后管理 CPA 的生命周期，不是在 CPA 的基础上二开。这样为了解决分开部署产生的很多连接问题。

  • seakee 楼主 08-17 11:08
    7楼

    这个应该不需要吧，CPA 现在是会透传客户端信息的，只要使用 Codex，那么上游看到的就是 Codex 的请求

  • co1dsand 08-17 11:21
    8楼

    cy期待一手，cpamp一直在用，支持佬

  • VanDu 08-17 11:24
    9楼

    建议层主好好看看楼主的表述，我没看到哪里说要把 CPA 绑回去的设定了，边界很明确的，是为了解决部署的真实问题而做的一些调整

  • Aluozzz 08-17 11:31
    10楼

    一直在用CPAMP,感谢佬提供的轮子。期待2.0

  • CK 08-17 11:36
    11楼

    使用了佬的项目和强大啊，但是合并我认为还是要继续兼容外部连接CPA，因为CPA我看几乎是天天有更新呢 ^-^

  • seakee 楼主 08-17 11:40
    12楼

    2. 继续连接外部 CPA


    如果现在有比较复杂的部署方式，或者暂时不想迁移，也可以继续使用原来的 CPA。


    所以不会出现升级 2.0 以后必须重新折腾一遍部署的问题。



    肯定兼容的呀，使用内置 CPA 是一种方式，外置也是一种方式。当前设计是为了解决之前反馈好久的部署连接问题 ^-^


    在和 CPA 的维护者们讨论后，一直觉得提供内置 CPA 会很大程度上解决很多分开部署连接问题，但也不会放弃原先直接连接外部 CPA 的方式的。

  • testG 08-17 11:48
    13楼

    cpa的插件应该能够稳定使用，并且能够访问cpa内部的一些东西做到一些目前cpamp不能做到的事，我觉得做个插件放到cpa里面然后链接到cpamp也行？因为cpa更新太频繁了。我现在一直在用cpamp，做的确实很好，但是也希望增加一些cpa没有的管理功能，比如认证文件的分组，key的分组这些东西，佬继续加油，cpamp确实很好用，我喜欢 ^-^

  • alizoed 08-17 11:53
    14楼

    可以做 API Key，可以限制额度，也可以给家里、朋友或者小团队使用。



    主要还是希望能有一个简易的5h/7day的限额配置，这样分发给朋友用的时候会方便一点

  • undefined 08-17 12:00
    15楼

    挺期待的，现在cpamp还没用。


    cpa本身的插件api有点不够用，想自己弄插件都不咋好弄。

    比如我想弄个插件在某个渠道连续抽风时弹个系统提醒，

    但直接拿不到base-url，要实现就稍微有点折腾，

    比如要自己读配置，然后做对应之类的。。

    估计cpa那边是安全考虑。

  • seakee 楼主 08-17 12:02
    16楼

    5h/7d/1m 这些已经在详细的计划列表中了

  • seakee 楼主 08-17 12:05
    17楼

    插件这个我其实已经有类似的规划，不过定位会比较窄，主要是处理一些必须在 CPA 内部才能完成的能力，不会把 CPAMP 和 CPA 的主要通信都建立在插件上。


    CPA 更新快这个我觉得和插件关系不大，插件本身也一样需要做版本兼容。如果比较追求 CPA 最新版本，2.0 到时候可以直接把 CPA 更新策略设置成自动更新；比较在意稳定性的话就用经过适配的版本。


    认证文件分组、Key 分组这些我记下了，不过功能还是得看实际使用场景和优先级，不一定会单纯为了“分组”去做。如果后面和 Key 策略、路由、额度这些能力能结合起来，价值会更大一些。

  • watermelon 08-17 12:15
    18楼

    想询问一下佬有没有打算做上游路由控制相关功能，例如某只API key只能用[email protected]这只上游帐号(认证文件)，不能用[email protected]

  • leeiemeng 08-17 12:16
    19楼

    那这样就太好了，非常期待，目前一直用的cpam

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐