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

[Twwy]

现在我们的是从管控上地设定哪些节点需要对这个域名进行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服务网络提供的服务质量低于预期的时候，我们可以进行调整服务或者停止服务。