某中大型网站系统架构--实战案例研究.docVIP

你是否一直考虑网站架构要有冗余性，安全性? 同时又有经济性呢？你是否经历过痛苦的思索网站的架构到底怎么样还算合理？怎么保证关键业务能够冗余，而其它业务可以选择冗余或不冗余。资金紧张的情况下 可以选择不冗余，一旦资金到位，系统架构又具备一定的灵活性，从而非常方便增加冗余设备？相 信每个网站的系统网络部门都经历了网站系统架构的艰苦摸索，从一开始只有简单的几台服务器，随着业务增长，到了上百台服务器，但从未停止过探索。下面我想 把从几次实战的中实验贡献出来，该架构已经在好几个较大的网站已经实施过，其中一个已经运行了4~5年，其中经历过无数次业务高峰的考验。该方案的特点：#1：简单 #2：可靠 #3：灵活 #4: 经济 #5：安全简 单：该方案简单理解成三个主要功能区域，Zone #1 ~#3 各司其职:Zone #3为Border区域，主要是面对Internet的关键应用接口区域，如Web应用，邮件外发，等等。 安全级别低 Zone #2 类似于DMZ区，但不一样，我现在还没有找到合适的名字命名，主要是放置对外提供服务的服务器，如Web Server. 安全级别中 Zone #1: 内部服务区，主要放置于数据库群组及功能服务器，该区域安全级别高。可靠：针对业务关键应用如网站服务，前端采用了主从负载均衡器，实 现10几秒之内的Failover切换。多台后端WEB服务器(Zone #2)提供服务，随着业务增长可以非常方便地增加Web服务器。负载均衡器采用商业级别的Load Balance，主要是F5和Netscaler，主要考虑到公司没有较牛的开源人才，出了问题之后很难得到支持，整个系统管理部门面对上层管理层压力非 常之大，目前还没有生产环境中使用开源项目的负载均衡器，但非常想试一试Nginx.灵活：关于主从负载均衡器，如果资金短缺的情况，可 以设置成单台设备运行，但后端Web服务器主机安全相应要做到非常好，如果万一前段的负载均衡器Down掉的话，可以通过DNS轮询解析把Website 地址解析到多个公网IP，然后把WEB服务器外网直接配上公网IP。这样也能做为应急措施。经济性：但如果稍会有些钱，建议主备 两台负载均衡器一起上。或者Linux高手较牛的情况，非常推荐用Linux开源的负载均衡器。这也是跟管理层展现自己实力的机会（做完之后一定要在管理 层上宣传省了多少￥）。另外经济性体现在防火墙及VPN设备上，该防火墙及VPN设备主要是连接公司办公室（或者其它功能中心如呼叫中心，物流中心等 等），由于VPN连接如果实现在办公室跟IDC之间的故障无缝切换，那是要花上大价钱的，Cisco有全套的解决方案（vPN+OSPF路由），设备非常 昂贵，我们已经把钱花在关键的网站业务上（购买商业级的负载均衡器），我相应大多数是互联网公司已经没有太多钱让你来提高Remote site(办公区，呼叫/物流中心)到IDC的连接可靠性上了。所以这里我们采取一台普通的防火墙及VPN设备，如Juniper的防火 墙，简单方便上手，硬件上又具备一定可靠性。如果你会问如果我这个防火墙也Down掉了，我们的呼叫中心及物流中心联不到IDC，处理不了业务怎么办？最 省钱的办法就在这个危急时刻暂时取消掉VPN加密，平时备一台Linux PC，安装开源路由防火墙软件，把备个办公区及呼叫/物流中心的出口IP地址加在白名单内。平时这台机器开着，出现紧急情况的时候，打电话给托管机房，让 他们帮忙把防火墙外卡拨插到Linux PC上，当然由于VPN功能丢失，各个办公区无法以私网IP地址来访问位于IDC的应用服务器，这个时候还得做好静态NAT，相当的烦琐。不是也是临时解 决问题的下策。上上策最好采购防火墙及VPN设备的时候，跟集成商谈好合同，要求他们提供备机服务，并在2/4小时内赶到机房，这样可以取得经济性跟可靠 性之间平衡点。安全性：不敢妄谈安全性很高，但架构分成三个区域，每个区域的安全级别不一样，相应于访问策略也是不一样，如Zone #3属于直接面对Internet用户，所以此处安全配置要相应地谨慎，一般来说就开个80和443端口已经足够。Zone #2的Web服务器虽然有负载均衡器的保护，但安全级别仍是较低，黑客可以通过http注入的攻击控制WEB服务器，所以我们要在这个Zone的WEB服 务器做足主机安全工作。而zone #1的数据库及App Server主要是面对Internal内部客户访问，如后台应用程序，相应来说安全威胁较小，可以通防火墙的配置对各个办公区访问IDC的服务器进行限 制，如数据库只开放3389/1433端口，不必把所有端口开放给办公区用户。附上网络基本配置：Zone #1: IP address