这可能有一个高可用的渠道聚合方案？
- 内容介绍
- 文章标签
- 相关推荐
本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是
- 我的帖子已经打上 公益推广 标签： 是
- 我的项目属于个人项目，与公司或商业机构无关： 是
- 我的项目不存在QQ、TG等群组引流： 是
- 我的项目不存在非运营必要的网站引流： 是
- 我的项目不存在为他人推广、AFF： 是
- 我的项目无关联的商业项目： 是
- 我的站点存在登录，并已接入 LINUX DO Connect： 否
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
前言
如何提升多个公益站渠道聚合后的可用性？
感谢佬友们的推荐，在试过 axonhub、ccload、metapi 后，发现都没达到我的预期。这里首先感谢各位开源大佬，再说各家我体验下来的感受。
- ccload
最佳调度选手，首字超时 + 故障转移的设计让开发体验非常快乐。基于 ws 的实时日志刷新，能非常直观看到请求的变动。
缺点也很明显，“渠道” 的逻辑很简单，但也很简陋，就是模型 + 站点 + 请求方式的组合，这让配置的规模爆炸了，一个站点的一个模型要添加 4 次。这是因为没有协议转换，作者也不打算加入相关功能。能不能一个站点同时可以设置 cc 和 cx，现在要分开才行・Issue #17・caidaoli/ccLoad・GitHub - axonhub
模型和 “渠道” 的关联配置设计得很漂亮，可以通过正则表达式聚合多个模型，善用正则表达式是好文明。
缺点是没有故障转移（特指首字超时的自动转移，理想情况下永远不会返回错误）。 - metapi
站点的管理做的很到位，“路由” 的概念很直观，站点与 “连接” 的独立设计很棒，可视化配置操作很友好，站点公告功能意外好用。
调度方面的能力比较一般，设计得较为理想，但实际体验是一个接口超时后需要重试三次才会切换，可用性比较差。作者最近也在推进首字超时，值得期待。[Question&Bug]: 首字超时单位是多少 & 失败时不尝试其他协议会重置・Issue #387・cita-777/metapi・GitHub
整体感受下来，ccload 的首字超时调度是最合我心意的，metapi 的站点账号维护也是我很需要的。
接着就发现两者是可以导入导出配置的，趁着临近下班赶紧 vibe 了一个转换器。
这个是 代码仓库 ，就是个小脚本，贴了个公益推广。
用了马某的生成器做了个在线可视化的站点，方便大家使用，点这里
在 ccload 侧导入时，建议先删除全部渠道。在 metapi 作者推出新功能前先就这样用着吧，体验还是不错的。如此，我的最佳实践就是用 metapi 维护各个公益站渠道，ccload 负责高可用部分，首字超时+故障转移+令牌管理+自动签到+可视化配置，都有了。
如果有更好的方案，希望佬友们分享分享。
最后还是感谢以上开源的作者们，最后最后祝佬友们编码愉快咯～
260407更新：优化了转换功能，支持别名映射，优化web体验
网友解答：--【壹】--：
如果用负载均衡之类的，确实ccload会好很多，体验很不错，特别是上面截图的那两个
--【贰】--：
octopus 的oai转换有点问题，经常炸了。搞得我切到axonhub 去了。最近看也没提到要优化的样子。
--【叁】--：
有个兜底的方法，你把这个仓库丢给 ai，把备份文件放在工作区，让 ai 帮你生成。本质上就是调用命令行工具。
500KB 其实不算特别大的呀，可能是 edgecase，你的配置有特殊操作吗？
--【肆】--：
体验了，octopus 故障转移确实不错，它的故障转移冷却是以渠道中模型计算的，不会影响渠道本身。感觉上就是更完整的 ccload，多了协议互转功能，更好用了。
就是没有针对冷却的可视化功能，有点遗憾，顺手提了个 issue。
感觉也可以做一个配置转换器，毕竟 metapi 的站点维护功能挺好用。
--【伍】--：
本质上也就是网关，揉了几个管理功能进去，让自己用着顺手点
--【陆】--： lafish:
冷却的可视化功能
请问一下佬友指的是这个吗
图片1920×586 157 KB
另外请问一下，octopus有这些实时的请求日志吗
图片1920×396 101 KB
--【柒】--：
我还在每天库库找公益站的时候，真正的大佬们已经捣鼓出我只能大呼不明觉厉的东西了
--【捌】--：
佬这项目挺有意思的，等我闲下来好好体验下。
--【玖】--：
强呀，大佬
--【拾】--：
该说不说，这个表达式完全可以用简单模式匹配到的呀
--【拾壹】--：
我在metapi上面把5.4聚合分组了。例如这样
--【拾贰】--：
是的，我指的冷却就是你图里这个倒计时。octopus 暂时没有。
--【拾叁】--：
佬，要不给我的 mos1128/ccg-gateway 提点意见？目前找不到优化的方向了
看了下需求，可以加个ws
--【拾肆】--： lafish:
在试过 axonhub、ccload、metapi 后
大佬，测试下bestruirui/octopus，我也试过axonhub，感觉octopus故障转移更好，其他的没测试，可以测试看看
--【拾伍】--：
原来如此，我用的都是简单模式的匹配，这表达式匹配确实没有适配到。
佬友可以用代码仓库地址+本地agent，先跑一个凑合用吧，ai会自动修补好的。
我这更新得明天了。
--【拾陆】--：
现在就是用的met 楼主这办法非常nice 谢谢分享！
--【拾柒】--：
这是把公益站再给聚合下么？真的需要这个东西啊。
--【拾捌】--：
佬，你的转化器卡死了，我上传配置以后，直接就白屏了，啥反应都没有，等好长时间了，都没有加载出来，我的配置大小有500多kb
--【拾玖】--：
不太实时，半实时吧，页面会自动刷新，但有在请求结束后才会出现。不像ccload在过程中都能看到。
本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是
- 我的帖子已经打上 公益推广 标签： 是
- 我的项目属于个人项目，与公司或商业机构无关： 是
- 我的项目不存在QQ、TG等群组引流： 是
- 我的项目不存在非运营必要的网站引流： 是
- 我的项目不存在为他人推广、AFF： 是
- 我的项目无关联的商业项目： 是
- 我的站点存在登录，并已接入 LINUX DO Connect： 否
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
前言
如何提升多个公益站渠道聚合后的可用性？
感谢佬友们的推荐，在试过 axonhub、ccload、metapi 后，发现都没达到我的预期。这里首先感谢各位开源大佬，再说各家我体验下来的感受。
- ccload
最佳调度选手，首字超时 + 故障转移的设计让开发体验非常快乐。基于 ws 的实时日志刷新，能非常直观看到请求的变动。
缺点也很明显，“渠道” 的逻辑很简单，但也很简陋，就是模型 + 站点 + 请求方式的组合，这让配置的规模爆炸了，一个站点的一个模型要添加 4 次。这是因为没有协议转换，作者也不打算加入相关功能。能不能一个站点同时可以设置 cc 和 cx，现在要分开才行・Issue #17・caidaoli/ccLoad・GitHub - axonhub
模型和 “渠道” 的关联配置设计得很漂亮，可以通过正则表达式聚合多个模型，善用正则表达式是好文明。
缺点是没有故障转移（特指首字超时的自动转移，理想情况下永远不会返回错误）。 - metapi
站点的管理做的很到位，“路由” 的概念很直观，站点与 “连接” 的独立设计很棒，可视化配置操作很友好，站点公告功能意外好用。
调度方面的能力比较一般，设计得较为理想，但实际体验是一个接口超时后需要重试三次才会切换，可用性比较差。作者最近也在推进首字超时，值得期待。[Question&Bug]: 首字超时单位是多少 & 失败时不尝试其他协议会重置・Issue #387・cita-777/metapi・GitHub
整体感受下来，ccload 的首字超时调度是最合我心意的，metapi 的站点账号维护也是我很需要的。
接着就发现两者是可以导入导出配置的，趁着临近下班赶紧 vibe 了一个转换器。
这个是 代码仓库 ，就是个小脚本，贴了个公益推广。
用了马某的生成器做了个在线可视化的站点，方便大家使用，点这里
在 ccload 侧导入时，建议先删除全部渠道。在 metapi 作者推出新功能前先就这样用着吧，体验还是不错的。如此，我的最佳实践就是用 metapi 维护各个公益站渠道，ccload 负责高可用部分，首字超时+故障转移+令牌管理+自动签到+可视化配置，都有了。
如果有更好的方案，希望佬友们分享分享。
最后还是感谢以上开源的作者们，最后最后祝佬友们编码愉快咯～
260407更新：优化了转换功能，支持别名映射，优化web体验
网友解答：--【壹】--：
如果用负载均衡之类的，确实ccload会好很多，体验很不错，特别是上面截图的那两个
--【贰】--：
octopus 的oai转换有点问题，经常炸了。搞得我切到axonhub 去了。最近看也没提到要优化的样子。
--【叁】--：
有个兜底的方法，你把这个仓库丢给 ai，把备份文件放在工作区，让 ai 帮你生成。本质上就是调用命令行工具。
500KB 其实不算特别大的呀，可能是 edgecase，你的配置有特殊操作吗？
--【肆】--：
体验了，octopus 故障转移确实不错，它的故障转移冷却是以渠道中模型计算的，不会影响渠道本身。感觉上就是更完整的 ccload，多了协议互转功能，更好用了。
就是没有针对冷却的可视化功能，有点遗憾，顺手提了个 issue。
感觉也可以做一个配置转换器，毕竟 metapi 的站点维护功能挺好用。
--【伍】--：
本质上也就是网关，揉了几个管理功能进去，让自己用着顺手点
--【陆】--： lafish:
冷却的可视化功能
请问一下佬友指的是这个吗
图片1920×586 157 KB
另外请问一下，octopus有这些实时的请求日志吗
图片1920×396 101 KB
--【柒】--：
我还在每天库库找公益站的时候，真正的大佬们已经捣鼓出我只能大呼不明觉厉的东西了
--【捌】--：
佬这项目挺有意思的，等我闲下来好好体验下。
--【玖】--：
强呀，大佬
--【拾】--：
该说不说，这个表达式完全可以用简单模式匹配到的呀
--【拾壹】--：
我在metapi上面把5.4聚合分组了。例如这样
--【拾贰】--：
是的，我指的冷却就是你图里这个倒计时。octopus 暂时没有。
--【拾叁】--：
佬，要不给我的 mos1128/ccg-gateway 提点意见？目前找不到优化的方向了
看了下需求，可以加个ws
--【拾肆】--： lafish:
在试过 axonhub、ccload、metapi 后
大佬，测试下bestruirui/octopus，我也试过axonhub，感觉octopus故障转移更好，其他的没测试，可以测试看看
--【拾伍】--：
原来如此，我用的都是简单模式的匹配，这表达式匹配确实没有适配到。
佬友可以用代码仓库地址+本地agent，先跑一个凑合用吧，ai会自动修补好的。
我这更新得明天了。
--【拾陆】--：
现在就是用的met 楼主这办法非常nice 谢谢分享！
--【拾柒】--：
这是把公益站再给聚合下么？真的需要这个东西啊。
--【拾捌】--：
佬，你的转化器卡死了，我上传配置以后，直接就白屏了，啥反应都没有，等好长时间了，都没有加载出来，我的配置大小有500多kb
--【拾玖】--：
不太实时，半实时吧，页面会自动刷新，但有在请求结束后才会出现。不像ccload在过程中都能看到。