浅谈私有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 ?或虚拟专用网)是个相对便宜的方法，但是一般的虚拟主机都有容量、频宽流量限制，以及不管有没有用到它，都需要付基本的月租费。
所以，本文介绍的方案，是采用Amazon S3(Simple Storage Service)及CloudFront。
Amazon S3 的主要优点，包括它是采「使用量付费」，计费内容包括储存空间、存取次数、传输量三项。因此若刚开始只需要放500MB ?的档案，就只需要为这有用到的储存空间及传输量付费，注册S3 服务并不需要设定容量，即使未来可能成长到几TB ?的容量，也不需要一开始就租赁旗舰级的方案，同时也不会有每月传输量限制的问题。
使用S3 建立CDN 的步骤很简单：
建立S3 Bucket(储存空间)，并将名称设为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 ?便宜(包括传输费用+存取次数)。
页:
[1]