当前位置: 首页 > 网站架构 > 正文

网站加速–系统架构篇

1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share
文章目录

一,系统部署(高并发,可扩展)

本来想画在手稿上然后扫描上去的,貌似方法太土,在朋友的帮助下费了n个小时用Visio画了个,感觉很好看 ^-^ 。这一篇将主要围绕这个图来讲述。

首先从数据源说起,所谓狡兔三窟,我们数据源也是按三路设计,以保证IDC内部和不同IDC之间实现灾备。源头转发机A,B,C拥有往集群中任何一台服务器同步数据的权限,所以他们三个有一个活着,数据就可以同步更新,而且可以自动切换。从源头转发机到其他各IDC的数据都是双路的,然后每个IDC的前两台服务器具备转发功能,往IDC内部其他服务器分发数据,同一IDC内部的主备转发机可以自动切换。这样就实现了数据同步更新的高可用性。

介绍下这个集群里的角色,备机A来自行情系统,兼任源头转发的异地备份。系统内的另外两个备机属于轻负荷服务器,80端口空出来,必要时候只要一启动,就会立即自动加入到LVS后面服役。除了A以外所有具备转发功能的机器同时也是集群内的普通成员,需要提访问供服务的。各IDC的LVS本身也是有主备的,可以实现自动切换。

整个系统增减服务器非常方便,用户根本感觉不到,备机的启用更快,也就3~5秒,具备很好的扩展性。

我们的数据从源头上就是使用我编写的myzip压缩好了的,后缀名用”*.mz” ,比如 a.js.mz ,一直到用户的浏览器端才解压。数据传输量小,速度快。 源头转发机上同时运行一个checkchange的程序,确保内容实际更新过的文件才往其他IDC转发,这样能有效的减少传输文件数量,以达到更快的更新速度。

另外,跨IDC系统部署,很重要的一点是,内网连通,路由选择,这影响数据传输速度的关键。北京的各机房间一般都有比较好的专线连通,只需要把路由打通就ok了。跨IDC的,一般都使用vpn来做内网传输,有条件的使用专线,这个比较昂贵,省着点用。另外跨网通,电信,和移动机房的一般都从双线机房路由,或者说,从到不同信息服务商连通性都比较好的机房路由。总之跨IDC数据传输,要做到各IDC之间的传输速度心中有数。

最后,请稍微注意下系统的安全性,包括数据传输的安全性,和网络安全性,避免遭受攻击。

二,负载均衡LVS(高可用,低成本)

LVS 有三种模式,NAT,TUN,DR,其中DR是最高效的,下面我将主要介绍DR的应用。更多LVS资料参见 LVS项目中文文档。 目前我们公司的LVS应用规模在国内应该至少可以排前三,更多技术细节请咨询我们的LVS大牛xiaodong2.

下面引用一下官网的介绍: 在VS/DR 中,调度器根据各个服务器的负载情况,动态地选择一台服务器,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址,再将修改后 的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器,所以服务器肯定可以收到这个数据帧,从中可以获得该IP报文。当服务器发现 报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文,然后根据路由表将响应报文直接返回给客户。

我在财经时要使用LVS的初衷只是为了解决负载的均衡性,因为DNA轮询各前端服务器上连接数有不小的差距,那时候我们老大阿图对于这个项目给予了很大支持,还亲自组织过几次会议。话说恰巧yingyuan做了个新技术讲座,我从中发现LVS/DR后想让它帮忙修改负载均衡算法,后来部署上以后发现,不用修改,均衡的很,再后来xiaodong2接手后对性能和稳定性做了很大的提升,我们使用两年来没出过问题。另外lvs还额外带来了两个好处,高可用性,和可伸缩性。是可以随时把lvs后面的一台服务器下掉,扛走,用户是不知道的。服务器坏了也不用着急修,也不用修改DNS(另外DNS的层层cache影响不是一时半会就能消除的)。新增加一台服务器也是同理,最绝的就是备机的启用可以用秒来衡量(这些F5都能实现,代价不菲)。财经应用对公司内lvs的项目推动有不可磨灭的贡献 ,xiaodong2也这么说地 :)

三,IDC分布,DNS解析(快速)

这里思路跟CDN是一致的,尽量减少主干线路上的拥塞,让用户就近访问,以达到最快的数据传输速率。
我们要做的就是了解自己应用的用户分布情况,然后再结合现有资源以及各地网络出口特征,信息服务商的特征来部署我们的服务。

1,各省市网络用户分布依次排名(数据来自cnnic2007年的统计):

1
2
3
4
广东 13.4%
山东 8.2%
江苏 7.5
...

2,运营商的网络分布特点:
网通:以北京为超核心的放射性结构。山东应该是网通最大的用户,但它的网络存在瓶颈,会有丢包,造成外面访问它慢,它访问别人也慢。对此我们没有必要浪费珍贵的主干带宽,在济南布个点,同步一份数据过去就,让他们在自己省内访问,访问速度会立刻提升n倍。

电信:以几大省市为核心的环状结构,省市内部也是大环套小环。其中以广东用户最多,必须要部点的地方。记得很久以前我拿到一份数据说,上海人访问本IDC的数据,不如访问广东的速度快,不晓得现在是否还存在这种情况。电信有7个主要核心,分布在广州,上海,江苏,西安,成都,武汉,北京。

教育网:以国内主要的八个结点为核心。这八个结点分布在北京,西安,成都,广州,武汉,南京,上海,和沈阳。

3,DNS解析时候需要权衡的:
现在了解了这些信息,那我们开始讨论如何部署我们的服务。要考虑三个问题:
一,要部署在哪几个IDC。
二,每个IDC部署的服务器数量。
三,DNS如何按区域划片。

要部署在哪几个IDC ?
其实这里还涉及到规模化应用的好处,一个小应用就部署了N多个IDC显然不划算。如果我的应用上了规模,我可以在每个省都部署上,那样用户体验将非常好,而且规模化以后会有专业人员对应用进行优化。所以公司里有动态池,和静态池这样的公用平台是好事(也许将来还会有我的js池)。如果我们的服务还没有上升到公司级别的规模,那就得考虑下取舍。

网通:东北三省,可以在沈阳和哈尔滨选择一个部署,有条件可以都部署。沈阳到北京的速率比哈尔滨到北京的速率快一倍,而哈尔滨到沈阳的速率,还不如到北京的快。北京,如果只让我在网通部署一个点的话,毫无疑问我会选择北京,其他所有结点到它的速率都比较快,但是北京的带宽比较昂贵。天津,这个点重要性仅次于北京,可以辐射河北,河南,江苏,离北京也比较近,价钱便宜。太原,可以辐射到西北一带。山东,前面已经说过,最好要部署的。

电信:那七个核心结点上部署了,速度就有保证。具体覆盖范围。广州覆盖周边几省,上海覆盖本地,江浙一带。 武汉覆盖华中一带,西安可以覆盖西北5省,成都覆盖西南5省。

每个IDC部署的服务器数量?
这要根据具体应用来决定。比如财经用户网通,电信比例:3:4 而体育是 1:2 。教育网用户一般占1/30左右。 这里还不能单纯考虑用户分布,还要考虑IDC内部灾备和IDC间灾备,是要有个取舍的。拿咱们的某个具体项目来说,教育网,够不上一台服务器,但是不得不部,因为它访问外界实在太慢了,我就住在学校里,也为了方便自己。我把北京作为主要结点部署了3台,天津,其实一台就够了,山东一台有点多。但是考虑到北京IDC一旦倒了,实力相当的IDC可以灾备,同时考虑到,天津,和山东只有一台,idc内部,都无法实现灾自动切换。所以,我选择天津两台,山东不部署,以性能换安全。

DNS如何按区域划片?
原则,就近分片,以达到最快传输速率。其次,考虑到各IDC间快速切换比较容易,DNS解析文件要写的简洁一些。另外,DNS解析有有个缺陷,每个单独域名里写在最前面的那个ip,它被轮询到的概率要比同组的服务器高10%,而且随着同组服务器的增多,这个差距会变大。所以最解析时候,每个IDC我都把硬件性能最好的服务器ip放在最前面。

另外:
做系统架构不提数据库,有点过不去。这块问题可以请教我们的DBA大牛zongwen同学。数据库是我将来一年的学习重点,争取一年后在DB方面能达到我们DBA六层功力。

本文固定链接: http://www.chepoo.com/site-accelerator-system-architecture.html | IT技术精华网

网站加速–系统架构篇:等您坐沙发呢!

发表评论