浅谈私有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 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 便宜(包括传输费用+存取次数)。

 

　　因此，S3+CloudFront 用于架设私有CDN 是相对划算的方案，只要依照实际使用量付费，若未来需求不断提高，也不会有需要升级频宽和储存空间的问题。

【免责声明】：部分内容、图片来源于互联网，如有侵权请联系删除，QQ：228866015