CDN：浅谈私有cdn（内容传递网络）布署

　　【温馨提醒】文章内容仅供参考,海外服务器租用\托管方案,请咨询YINGSOO客服,24小时免费电话400-630-3752

　　【热门主机】韩国云主机推荐吗？韩国云主机有哪些好处

CDN

　　当web Application(以下简称webApp)大量取代传统桌面应用程式，资讯服务类型的软体公司，需要解决的「重复与浪费」问题，就不只有软体架构本身;相信大家都清楚软体架构本身，需要模组化、元件化，让写好的功能(程式码)可以尽可能再利用，最好有很多plugins或modules，当有需要的时候就可以拿来使用或扩充。

　　资讯服务公司通常不会只有一或少数几项软体专案，而是会建立非常多系统。因此，重复造成的浪费问题就更加严重。

　　一般来说，经过编译的程式或者原始码本身，都不太会有体积的问题。例如封装成.dll或.jar之后，就可以再不同专案中引用。搭配好的自动化建置机制，通常我们不需要将外部共用的模组(或元件)，放到专案的版本控制系统，只有进行测试或最后发布时，才需要把这些档案暂时加进来。

　　但是webApp包含的内容并不只有程式，还有许多比较像是「资源」的东西。例如：

　　jQuery core + jQuery Ui + .... 一大票 jQuery plugins

　　ext Js + 一大票 widgets ...

　　icon library + ... 一大票图库

　　自行开发维护的Javascript、css、icon 共用libraries 等

　　如果没有好的解决办法，这些资源除了被重复发布到很多网站伺服器，造成储存空间及频宽的浪费，甚至也会被加到专案版本控制系统的repository。

　　举例来说，ext Js 4 的原始码ext-4.0.7-gpl 解压缩后体积高达166mb，为了某些情况除错方便，我们可能不会只保留必要及压缩最佳化的档案，而是需要完整的档案。除非使用的Framework 有良好的plugins 机制，可以引用ext Js 但不会实际被加到专案资料夹(只有在建置test 或production 阶段才会加入暂存的区域);否则，一般来说都是直接在webApp 的资料夹中，也保存一份完整的副本。

　　相信有很大一部份比例的专案，都是直接就把这些资源加到专案的repository，一起发布到版本控制系统;这是最简便的方式，可是也是最浪费资源。这么做会带来一些问题：

　　不属于专案的东西，却要纳入专案的版本控管。占空间(虽然现在硬碟很便宜，这问题显得不大)、维护麻烦。

　　专案的repository 变得十分肥大，真正属于专案的部份也许不到30mb，但整体却超过100mb。对于版本较旧的sVn 来说，执行速度可能随档案愈多愈复杂而变得愈慢。

　　不管是新加入的成员，或经历一次灾难后需要重新取出(checkout)完整的档案，浪费伺服器资源及网络频宽，最重要的宝贵时间也会因此白白浪费。

　　假设一家资讯服务公司有20 个系统，就造成资源20 倍浪费。

　　对于导入持续整合机制的专案来说，又造成更多的浪费。

　　像是gitHub 等专案托管服务，有档案容量的限制，占空间就是个需要考虑的问题。

　　即使在开发阶段，解决资源重复造成的浪费问题，例如可以不必将外部资源纳入版本控管;但是最终打包发布时，放到正式的伺服器运作，还是需要加入这些档案(可以透过最佳化让档案少一些、体积小一些)，最终，浪费的问题还是存在。

　　对于资讯服务公司来说，建置私有cdn 不仅可以得到很多好处，而且在云端服务价格低廉的时代，更是很难找到理由不这么做。

　　cdn(内容传递网路，content delivery network)的概念，是指一种透过网际网路互相连接的电脑网路系统，提供高效能、可扩展性、及低成本的网路将内容传递给使用者。

　　简单地说，我们可以建置远端的档案服务伺服器，将webApp 专案常需要用到的静态资源，都放到这些伺服器，让这些伺服器维持高可用性、扩展性，提供足够的负载量;如此一来，所有的专案共用的webApp 资源，就可以布署到这些服务器。

　　建立cdn 的优点很多，包括开发人员可以快速利用(不必每次都要重新下载、建立library)，减少远端布署需要的时间，让不同专案之间可以共用资源，降低正式伺服器的存取及频宽消耗，帮助需要高负载的webApp 减轻负担，...

　　事实上，google就建立了自己的cdn，提供包含jQuery、jQuery Ui、prototype等网站常用到的资源，并且也把这个cdn免费开放给所有开发者使用。

　　不过，免费的cdn 通常不会刚好有你需要的所有东西;以ext Js 来说，google 仅提供核心部份ext core，而sencha 虽然也有为ext Js gpL 架设cdn，但实测后发现经常有找不到档案的情况。

　　对资讯服务公司来说，用其他人提供的cdn 并^{[菲律宾服务器]}不是个好办法，因为哪天该cdn 结束运作，或者已经不提供某个版本的资源，就会造成一些系统因此受连累而挂点。所以，建置私有cdn 是比较好的方案。

　　一般来说，自己租用专线架设伺服器来做cdn 并不划算，光是要达到资料及网路的备援，以及高可用性(要预防断电断网路天灾人祸等问题)，要付出的成本实在太高。

　　使用虚拟主机(Virtual Host 或Vpn)是个相对便宜的方法，但是一般的虚拟主机都有容量、频宽流量限制，以及不管有没有用到它，都需要付基本的月租费。

　　所以，本文介绍的方案，是采用Amazon s3(simple storage service)及cloudFront。

　　Amazon s3 的主要优点，包括它是采「使用量付费」，计费内容包括储存空间、存取次数、传输量三项。因此若刚开始只需要放500mb 的档案，就只需要为这有用到的储存空间及传输量付费，注册s3 服务并不需要设定容量，即使未来可能成长到几tb 的容量，也不需要一开始就租赁旗舰级的方案，同时也不会有每月传输量限制的问题。

　　使用s3 建立cdn 的步骤很简单：

　　建立s3 bucke^{[台湾大带宽服务器]}t(储存空间)，并将名称设为cdn 网址(如：cdn.yourname.com)

　　修改dns 设定，将网址透过cnAme 指向bucket 的end point 网址

　　设定bucket 的web site 为enabled

　　将要放到cdn 的档案如ext Js 等，上传至bucket，并设为public

　　对于mac及Linux的使用者来说，可以用s3cmd工具来管理档案，这个软体可以在command line下轻松将本地档案，上传或同步到指定的s3位址。

　　除了在建立cdn 时可以用s3cmd，如果遇到客户因预算或速度考量，需要把专案整个搬迁到企业内部网络可以直接存取的服务器，也可以利用s3cmd 做一份mirror，维持专案使用到的资源有一致的存取配置。

　　如果开发的webApp 是需要提供给大众使用，甚至有来自世界各地的使用者，使用s3 可以方便地搭配cloudFront 建置全球化的cdn。

　　cloudFront 不能储存档案，它是用来「传递」s3 或其他来源的档案，透过分散在世界各地的资料中心(s3 的bucket)，减少网路传递路径的延迟。简单地说，cloudFront 可以让s3 的档案下载速度更快，而且传输费用也比s3 便宜(包括传输费用+存取次数)。