From: http://blog.sina.com.cn/iyangjian
一，系统部署（高并发,可扩展）
二，负载均衡LVS（高可用,低成本）
三，IDC分布，DNS解析（快速）
-----------------------------------------------------------------------------------------
一，系统部署（高并发,可扩展）
本来想画在手稿上然后扫描上去的，貌似方法太土，在朋友的帮助下费了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资料参见
下面是DR单臂模式的系统结构图:
下面引用一下官网的介绍: 在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年的统计)：
广东 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六层功力。