【架构师从入门到进阶】第五章：DNS&CDN&网关优化思路——第二节：CDN扩展-多地址直连
- 类注册中心
- 类规则中心
- 总结
本篇文章，我们来学习CDN的扩展。
我们在前面学过用CDN做静态内容的缓存比较好，它能离用户比较近，并且用户请求的时候如果缓存了静态的内容，它能把静态的内容直接响应给用户。这样的话，用户的响应时间会很低。
那么有一个问题，如果说我们要去获取动态内容呢？是不是也能参考像静态内容那样？假如我们的原站提供动态的内容，可不可以做成类似于CDN那样的，让客户端去请求到那个更合适的原站的服务器？
类注册中心
第一种情况，这一种情况是类似于注册中心，我们叫类注册中心。
首先，这有一个客户端client，然后有一个注册中心，然后后面是我们的server端。我们的客户端要去请求这个服务端呢，先去注册中心拿到服务的地址，然后再去请求服务端的内容拿到响应。
那么这里面涉及到两个问题：第一个是注册中心得知道服务吧，所以服务启动的时候需要向注册中心去注册一下；第二个是客户端怎么能拿到合适的server，肯定是有多个server的，有多个server都向注册中心注册了，那么客户端从注册中心拿到多个server的地址之后，需要做一次筛选。
比如，注册中心根据客户端要调的服务的名称，然后查到这个服务对应的多个IP地址，然后顺便查出来他们的负载情况，负载均衡有一个最小连接的负载均衡算法。我们这边的服务可以通过心跳，随着心跳就把自己的负载的情况告诉注册中心。
那么，客户端去注册中心拿到这些服务信息的时候，顺便把它的负载也拿到，然后客户端做一个计算，谁的负载最小我去调用谁。
我们要记住一个点啊，就是客户端最终调用的时候是客户端和服务端直接进行连接的。
类规则中心
针对服务器个数是确定的情况，比如说我们就部署三台，那么我们的负载均衡策略也给它写死了，那么这个时候注册中心这一块我们就把它叫做规则中心。我们去请求服务之前，我们先去规则中心去拿一下服务的规则，或者说把服务的地址也保存在规则中心里。然后我们去取的时候，规则中心它有这三个IP，就根据规则在三个IP中找出一个IP给我，我再去请求。所以说这个叫做类规则中心。
那么，我们刚才所说的这种规则，是人为设定的，在服务节点加入和退出的时候需要手动去修改。我们刚才所说的那个规则服务，因为规则服务里有三个IP，如果说少了一个服务，我们得把IP拿掉一个，同时规则得修改一下。
那么我们在实际生产中有没有人用这个呢？
比如说我们下载一个Center OS的镜像，下载的时候我们可以去选是去网易的镜像下载呢，还是去阿里云下载，还是去清华的那个镜像去下载。
我们的linux下有这个repo，就是在etc目录下的那个镜像源的地址，在/etc/yum.repos.d/目录下有好多好多.repo文件，那些文件干嘛呢？就是存储的我要下载安装包的源地址源。我们的客户端比如说要从a机器上去下载，我们把原料都放到a机器上，你下载时去这取，不行再切换源去取。
还有就是登录游戏的时候，为什么要选哪个服？因为比如说我在上海，我选上海的服务器，我在北京的时候我选北京的服务器。这样也相当于在我客户端在使用的时候，指定一个服务器的地址。
总结
我们总结一下，上面的这两种方式，基于注册中心和基于规则中心，他们都有一个共同的特点，就是客户端和服务器在真正获取数据的时候是直接连接的，注册中心和规则中心只是负责将用户的请求进行分流。在整个过程中，服务并不需要注册中心和规则中心的中转，只需要问他们我需要找谁，他们只是告诉一下我需要找谁，简单的地址解析请求或者给客户端提供一个IP地址即可。
那么客户端至于要拿什么数据，它是直接跟我们的源站连接的。所以呢，这种方案，也叫做多地址直连，就是CDN的扩展，CDN扩展也叫多地址直连。
举个例子，就像我们去租房子一样。我们要租的这个房子，就有好多个，但是我们又没有那么多时间去找哪个房子合适我，那么我需要一个中介。但是实际上住房的是我跟他的事，我跟中介没有关系，哪怕中介公司倒闭了，我这个房子我该怎么住还是怎么住，不影响我的业务逻辑。