记一次独立网站的架构调整
连日来一家花都外贸企业的一台服务器受到不好程度的DDOS攻击，里面的几个独立网站和商城均受到严重影响，访问页面响应缓慢，或者打不开，甚至连主页都被篡改成其他内容了，实时connections将近4K，整台服务器速度已慢于蜗牛了。
此前并没有对其站源进行过多的优化，站源系统还是windows 2008+apache，版本都是比较老旧，漏洞也比较多。导致近段时间经常被DDOS攻击和篡改主页内容。目前客户访问网站，都是直接访问站源，这种原始的架构缺点是，不同地区的访客访问进来，会出现不同程度的延时，所有访客都在同一时间挤到回源的线路上。即使没遭到DDOS攻击，也会因线路不稳定影响到访问质量。
这是原始网站搭建的情况，当访问量大了，CPU和MEM的开销将会很大。
第一版本的改良：（Website+Cloudflare）
可以针对jpg,css,js等静态文件进行压缩处理，并启用memcached。然后通过apache/nginx的配置文件，把这些静态文件放到CDN上面，在此我选择了amazon的Cloudflare，应该是目前所有CDN服务提供商中最经济和方便的一种。
添加两个子域：cdn.domain.com 和source.domain.com，cdn.domain.com是用于绑定到Cloudflare的CNAME，source.domain.com用于回源。如果是加了SSL证书的网站，还需要再添加一个子域名，并为这三个子域申请SSL证书。
这个方案最大的优点是：亚马逊的CDN全球布点比较多，通过就近原则，把站源静态文件缓存当地CDN服务器上面，在美国和欧洲等地区，基本上是0.5－20ms左右。这个访问速度比访问站源（大概120ms）快很多。
缺点依然有不少：1.中国地区访问比较慢，目前amazon的Cloudflare并没有覆盖到中国区域。2. 仍然暴露了站源的真实IP地址，有被入侵和DDOS攻击的可能。3. 站源线路不稳定时，除了静态文件走全球CDN这外，动态文件的传输也是同样受到影响。
第二版本：（website+cache）
针对以上的缺点，暴露站源IP是个极大的安全隐患，当网站有一定的知名度，容易受到DDOS攻击和网站内容被篡改。这一次的改良，就是为了杜绝这一情况的发生。可以进行以下的调整：
1.
采用前后端架构，以站源作为后端，并增加前端缓存服务器，作用相当于亚马逊的Cloudflare，但自己架构缓存服务器的好处是可以隐藏站源的真实IP，从而免受攻击。把站源仅允许Cache服务器访问，如果条件允许，Cache服务器与站源仅进行VPN或LAN通讯，站源公网IP不对外开放。如果站源与cache只能公网通讯，那么可以通过apache/nginx的配置文件，设置允许cache的IP访问外，把所有IP都drop掉。但其安全隐患仍然是处于互联网公网之中，只是攻击者可能不是从website分析进来的，这样攻击针对性就小很多了。一般大型网站的站源部署基本上都是处于LAN之中。
另外，cache服务器的部署，可以选择这几个反向代理：squid、Varnish或是Nginx，这里我选择squid，具体看哪个比较适合自己的生产环境。
第三版本：（website+Ncache+bind）
基于第二版本website+单点cache的布部，还仅仅是解决了隐藏站源真实IP的同时，加速了就近于单点cache的用户访问。当然把cache部署到CN2线路还是不错的选择，目前香港CN2机房的线路，到达国内和全球大部分地方的速度还是比较思想的，到达国内的速度可达11ms，到欧洲和美洲的主流国家，达到50多ms。当你的网站达到一定的访客数量和知名度外，还得要有全球CDN布局的思维，这样通过多台cache与站源通讯，减轻站源的访问压力。
这里多台cache的布点，涉及到负载均衡的技术问题，可以通过一台bind服务器，把不同地区的访客自动分布到分支上面。采用bind做域名解析系统，比较麻烦的一点就是需要做比较全面的IP网段的分流。
真正跑起来的大站，还需要进行主从数据库分离，并结合HAProxy+Nginx进行心跳连接，有米的话在上层选用F5、Radware等的硬件设备做负载均衡。
回归网站本质：（优化>运营
在访客流量和品牌影响力还没有到一定的规模时，优化和海外推广才是最重要，在运营的初级阶段必须把网站内容生成一定量的长尾词，抓住几个大的关键词做好排名分析。当达到一定流量我们就需要考虑到以上的架构调整，重点是要知道自身网站的瓶颈到哪一个阶段。任何阶段，站外推广和渠道合作都是至关重要，这是反映了网站运营的实力，有了实力就有能力调整网站架构。
下一期，将从海外推广方面进行详细解说，主要内容围绕：如何跟海外联盟机构合作，如何运营好你的社交媒体，如何在信息对称的网站合作及新闻稿、原创外链等的发布。
