firefoxbug/opencdn

OpenCDN是一套快速部署CDN加速的工具。

opencdn's Issues

关于虚拟节点的思考

由于网络的不稳定性，导致任务的相对高失败率，使得重试在这个面前如同螳臂挡车。
我思考能否将我们的稳定的部分构成一个任务闭环，然后不稳定的部分又变成另外一个闭环。
(中心->任务调度->虚拟节点) -> 构成管控调度系统
(虚拟节点 -> 实体节点 -> DNS) -> 构成管控通信系统

一个用户添加一个域名之后，通过任务的调度实现虚拟节点的配置文件更新(这个可以保证100%)的成功率。

虚拟节点 -> 实体节点 的一致性问题由节点健康检查守护来解决，他负责把节点之间保持一致性，同时把控制DNS的权限也交给节点来管理，节点上的某个配置文件生效之后，他就有权生效DNS记录，节点的某个配置文件失效，他也有权删除DNS记录。

也就是说，管控调度系统不再负责DNS的管理，这个让节点守护来管理打向他的这个节点流量能够由几个域名组成。管控调度只控制由这个域名由哪几个节点来负载。至于什么时候开始负载，什么时候不负载，这个都由节点的自身的健康状态来决定。

反向代理检测部分可以优化

反代检测会导致回源。
回源会导致检测速度大大下降。

我有个思路就是像每个git的版本一样记录用户对配置文件的每次变化，出一个版本号(也可以用随机的md5来做)。
然后为http://xxx.com/ocdn_version配置版本号，如果这边检测到他的配置文件的版本号和我们这边的一致，那么说明配置文件已经推送完成，也不用去进行反代检测了。

之前我们其实已经用了类似的方式，只是没有把版本号这个东西放进去。只知道这个节点能够反代这个域名，但是并不知道反代域名的配置更新情况。

整个模块可以变成一个配置检测模块，用来替代反代检测。

我已經強行修復到可以安裝了，但是我遇到一個控制面板上的問題

登入的login.js有問題不知可以解救我一下嗎??

网站被黑?

OpenCDN上的架构(client)的新思考

现在我们的是从管控上地设定哪些节点需要对这个域名进行CDN服务。如果反着来想，能否这样去做？
一.让节点来选择服务哪些CDN域名？
二.以及让节点来选择是直接回源还是通过其他的节点(链路加速)来回源。

问题一的设计** (节点 -> 源站的选路优化)

1. 以a.com为例，先在管控上生成a.com的配置文件，但是不进行下发（或者说我们根本不知道下发哪个）。
2. 发送一堆通知(a.com)对各个CDN节点进行预热。
3. 节点在收到通知之后对从本节点回源的链路进行评估，然后通过callback_url来通知管控他的决定(是/否)，然后管控也可以对这个决定进行干预，如果节点的决定是OK，但是管控的回复是否，那么就不能对这个域名进行负载
4. 节点通过callback收到管控的确认之后，从管控拉去a.com的配置文件。
5. 通过收集callback我们可以知道这个域名最终在哪些节点生效了。

问题二的设计** (CDN网络内部的链路优化)

1. 在问题一的流程已经走完之后，我们可以再发通知(a.com)进行预热，这个时候就不单是对于回源链路进行评估了，这个时候会把问题一的时候已经生效的节点也放进源站列表。
2. 节点在收到通知之后对于这些源站(含已生效节点)进行评估，然后用callback通知管控，这个过程可以理解为时CDN网络节点的再一次迭代。

整个**我觉得大致可以这样概括：

1. 确定回源节点组合
2. 在回源节点组合上确定链路优化节点组合
3. 管控通过callback信息确定该组合是否满足预期，如果不满足再进行1->2的组合迭代，最终节点组合会趋于稳定和收敛。(没有验证，我猜测的)

采用这种方式我们可以对一个CDN服务质量进行干预，当CDN服务网络提供的服务质量低于预期的时候，我们可以进行调整服务或者停止服务。

关于CDN服务标准化的思考

所有的CDN的服务节点和中心之间，需要有一个统一的接口，我称带有这个接口的cache为CDN容器。

这个统一的接口不一定需要像之前一样用lua写插件，他只要满足我们定的接口的标准就可以了。

接口实质就是一个http应用，携带了配置文件生成器。

没错，我希望把配置文件的生成在节点上完成，理由如下：

• cache软件会不断地升级，而如果通过中心来生成配置文件，虽然一开始看起来轻松，但是后面会加重中心的负担。
• 每个cache软件的升级都会伴随着http接口的升级，而中心是不会感知到的。中心只需要知道你这个cache支持哪些标准接口就OK了。

OpenCDN需求确定

1.便捷的CDN管理平台(包含WEB/CTL/API)
2.CDN域名和节点流量数据展示和控制
3.降低复杂的互联网环境所带来的CDN运维成本
4.降低cdn系统的逻辑复杂性

现在不更新了么

官网打不开，也没法看到安装文档

Not access your website

Hello,
I can not access your website (http://ocdn.me) to reading installation instructions.
Thank you

为什么不继续开发了呢

对于Task运行失败处理

假设一个job由很多个task组成，一个task又由很多个instance组成。

问题主要归结为：比如某个节点突然down了，那么对于这个节点的所有要运行的job都会失败。比如下面这个case，对于一个域名下有十个节点，现在要进行配置文件分发的Task，结果其中一个节点突然down了，那么最终结果是9个节点返回成功，1个节点返回失败，可以说是9个instance成功，1个instance失败，最终结果不能算这个Task是失败吧？因为标记为失败后，又得重新调度整个Task，所有的instance又得重新跑。

怎么解决？
方案一：把失败的instance重新组成一个task，丢到队列里面调度，并且设置最大调度次数，每次调度后就把count加1，直到超过最大调度次数后判断为失败，更新到数据库。
这个方案的缺点：一旦down的节点恢复之后，需要有一个守护去轮询数据库找到这个down的节点还有哪些任务要做，然后依次做完。这种在编程逻辑上是很复杂的，因为设计到要找到哪些任务要做，而且其实是很浪费资源的，因为明知道这个节点其实是down的，没必要（可能说可以根据网络响应的错误类型来判断是否要调度，但是这样的方法是最优的吗？），现在的版本就是这样的。

方案二：做一个任务的堆积，一旦某个节点down了，就把这个节点要做的task都堆积起来，这种堆积不应该是队列，而是保证最新的task就行，类似应该是K-V这种，保证每种task类型只有一个最新的task。这个方案不知道该怎么实现比较好？

总结下：需要解决一个问题，就是task执行失败的情况下(节点半死不活)，怎么把task更优雅的，并且不重复的保存到一个"failed_task_to_do"的结构中(不应该是队列，最好是磁盘)，等到节点ok了，把所有的该节点的tasks都执行了。

架构分层设计提议

1.展现层 php or python?
2.控制层(master) python or go?
3.通信层 zeroMQ or other?
4.执行层(agent) 插件?