浅谈私有CDN(内容传递网络)布署

蜗牛vps教程2022-08-101090

  当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。

  本文地址:https://www.idcbest.com/idcnews/11000669.html免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:niceseo99@gmail.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

评论

有免费节点资源,我们会通知你!加入纸飞机订阅群

×
天气预报查看日历分享网页手机扫码留言评论电报频道链接