http://zyan.cc/index.php zh-cn http://zyan.cc/architect_solitaire/ 张宴 <net@s135.com> Thu, 06 Jan 2011 05:12:52 +0000 http://zyan.cc/architect_solitaire/ http://www.programmer.com.cn/4544/）

　　主持人：冯大辉，现任丁香园 （http://www.dxy.cn）网站CTO。曾历任支付宝架构师、数据库团队负责人等职。

　　许式伟：作为系统架构师，您一般会从哪些方面来保证网站的高可用性（降低故障时间）？

　　张宴：很多因素都会导致网站发生故障，从而影响网站的高可用性，比如服务器硬件故障、软件系统故障、IDC机房故障、程序上线前测试未发现的Bug、遭受分布式攻击、突发访问人数剧增等。

　　一套良好的网站系统架构，应该尽可能地避免只有一台服务器、一个数据库、一套软件节点等单点故障的存在。单点故障一旦发生，将直接导致网站服务不可用，恢复正常服务所需的时间也比较长，甚至还可能无法恢复。负载均衡集群、双节点热备、分布式处理等都可以用来解决单点故障，比如提供相同业务的Web服务器、MySQL数据库从库，都可以构建负载均衡集群。一旦集群中的一台服务器、一个服务出现故障，自动实时摘除，对用户来说是不可感知的，不会影响到整个网站的访问，可以为运维工程师留下足够的时间去排查和解决故障。

　　对于重要的MySQL数据库主库，我们习惯于从硬件层和软件层来实现热备，避免单点。越是复杂的设备，发生故障的概率越大。在磁盘没有损坏的情况下，应用程序导致服务器宕机的概率，远高于简单的磁盘阵列宕机的概率。所以，从硬件层解决的话，可以在两台服务器上安装相同的数据库版本、进行相同的配置，用SAS或SCSI线连接一台磁盘阵列，将数据库数据文件存放到盘阵上。正常情况下用服务器A挂载盘阵分区，启动MySQL，绑定虚拟IP；如果服务器A宕机，则用服务器B挂载盘阵分区，启动MySQL，接管虚拟IP。从软件层解决的话，则可以借助DRBD等软件做镜像。

　　IDC机房发生故障的概率较小，但如果发生的话，影响面也是最大的。如果所有服务器都托管在一个IDC机房，一旦该机房遭遇长时间流量攻击、断电、断网、地方政策性封网等，通常只能联系IDC去处理，除此之外束手无策，解决时间也比较长。如果成本允许，将网站服务器分布在两个以上的IDC机房，当某个IDC发生故障时，可以临时切换DNS域名解析来优先恢复服务。

　　虽然程序代码上线前，经过了测试人员的严格测试，但测试环境和生产环境毕竟有差异，所以一些会急剧影响性能、正常服务的Bug往往在程序上线之后，才会被发现，这就要求我们在发现Bug后，能够迅速回滚到上一正常版本。我们在SVN的基础上，开发了Web代码发布系统，会将每个发布版本之间的文件变更记录下来，一键实现程序代码在多台Web服务器上的发布和回滚。

　　遭遇DDOS分布式拒绝服务攻击，使用防火墙来对付半连接、假IP，还算比较容易。而那种专挑复杂动态应用程序URL进行的分布式CC攻击，来源为真实IP、真实HTTP请求，具有模拟正规浏览器User-Agent、单个IP的每秒请求数不高、有成千上万个攻击源等特征，很难与正常访问区分开，比较难对付。但是，正常通过浏览器访问一个URL，会加载该URL中引入的JavaScript脚本、CSS样式、图片等文件。遇到CC攻击，需要及时分析日志，找出访问量异常上涨的URL，然后用事先写好的shell脚本找出哪些IP的请求只访问了该URL，而不加载该URL引入的文件，对这些IP进行自动封锁。

　　系统架构设计时，需要事先考虑到高于目前访问量多少倍的突发访问。对于网游站点来说，访问量受广告集中时间段投放、线上活动的影响较大，带宽峰值时间不固定，对于静态内容，可以使用商业CDN，按实际使用量计费。对于动态内容，如果遇到突发访问人数剧增，超过现有服务器处理能力，最简单的临时处理办法就是增加服务器。上架新服务器需要时间，但是，同一个IDC机房内，可以借助其他业务的服务器，在不同端口开启一组新进程，加入到原有负载均衡池中。另外，可以临时关闭一些Web中的次要功能，来减少服务器消耗。

---

　　许式伟：您在任务切分上，有什么经验分享？您通过哪些手段保证任务的独立性？

　　张宴：相信很多人都遇到过这种情况：在一个老项目上修改、增加一些新功能所花费的时间，不比重新来做一个包含所有功能的新项目时间用得少。一个需要长期维护的项目，不可避免地会面临老员工的离职、新员工的接手，很多时候，项目代码的可维护性将决定一个项目的生存周期。让一个新员工在规定开发时间的压力下，去面对一个文档不够详细、陌生的、功能复杂的庞大项目，短时间弄明白所有功能逻辑不是一件容易的事。所以，任务需要切分，将一个大的任务切分成一个个小模块之后，各模块之间可以做到代码独立，互不影响，可维护性也大大增强。

　　关于任务切分，我以本人今年负责的两个重要项目架构设计为例来介绍一下。在第一个项目：金山游戏官网的《用户行为分析系统》中，由于数据挖掘计算需要消耗较高的内存、CPU资源，一台服务器的处理能力不够，而商业的分布式数据仓库价格又太贵，所以，只有从程序应用中下手，进行任务切分。我们先按需要挖掘的数据指标，将整个数据挖掘任务切分成多个数据挖掘插件，每个插件可以在不同的服务器上运行，多个插件可以同时在多台服务器上。多个数据挖掘插件之间，如果用到相同的某项数据，那么，就将该项数据以冗余方式，复制几份提供给需要的插件，从而实现插件之间无交互、无关联，保证了超大数据量下插件的运算速度。

　　在第二个项目：金山游戏新版运营管理系统中，则将整个任务切分成了PHP Web管理界面、PHP Web API功能接口、C/C++中间件引擎三部分。这是一种分层结构切分，最上层的“PHP Web管理界面”调用“PHP Web API功能接口”，“PHP Web API功能接口”调用运行在游戏服务器端的“C/C++中间件引擎”，“C/C++中间件引擎”与“游戏服务器端进程”通过TCP、UDP二进制协议、信号、命令行等多种方式通信。四者之间相对独立，代码无关联，通过一层层API接口实现交互。“PHP Web管理界面”负责通用界面实现。“PHP Web API功能接口”内部，又按接入的游戏模块、子功能模块进行了更细的切分，各功能模块之间通过内部API交互。“C/C++中间件引擎”大而全，不处理具体指令，但兼容TCP、UDP、HTTP、HTTPS/SSL、信号、命令行等大多数通信方式，负责和各种类型的游戏服务端交互。这是一套完全由API接口驱动的系统架构，一款新游戏接入运营管理系统时，只需在“PHP Web API功能接口”中增加一个模块；一个游戏新管理功能的增加，只需要在“PHP Web API功能接口”中增加一个子模块。通过任务切分，将复杂功能简单化，也将原来接入一款新游戏所需要的几个月时间，缩短为1~2周。

---

　　许式伟：您通过哪些手段，来保障产品的质量？您倾向于多久更新一次您的网站？

............

Tags - 程序员 , 架构师接龙 ]]> http://zyan.cc/architect_solitaire/#blogcomment7564 aganblog <user@domain.com> Thu, 06 Jan 2011 07:15:59 +0000 http://zyan.cc/architect_solitaire/#blogcomment7564 http://zyan.cc/architect_solitaire/#blogcomment7565 kimwu <user@domain.com> Thu, 06 Jan 2011 07:42:58 +0000 http://zyan.cc/architect_solitaire/#blogcomment7565 刚刷新一下就发现了 仔细拜读 ]]> http://zyan.cc/architect_solitaire/#blogcomment7566 苦咖啡 <user@domain.com> Thu, 06 Jan 2011 07:47:43 +0000 http://zyan.cc/architect_solitaire/#blogcomment7566 http://zyan.cc/architect_solitaire/#blogcomment7567 Leosio <user@domain.com> Thu, 06 Jan 2011 08:10:43 +0000 http://zyan.cc/architect_solitaire/#blogcomment7567 http://zyan.cc/architect_solitaire/#blogcomment7568 youxibaike <user@domain.com> Thu, 06 Jan 2011 08:17:20 +0000 http://zyan.cc/architect_solitaire/#blogcomment7568 http://zyan.cc/architect_solitaire/#blogcomment7570 testv <user@domain.com> Thu, 06 Jan 2011 09:39:56 +0000 http://zyan.cc/architect_solitaire/#blogcomment7570 http://zyan.cc/architect_solitaire/#blogcomment7571 wooley <user@domain.com> Thu, 06 Jan 2011 09:57:01 +0000 http://zyan.cc/architect_solitaire/#blogcomment7571 http://zyan.cc/architect_solitaire/#blogcomment7572 shiny <user@domain.com> Thu, 06 Jan 2011 10:34:45 +0000 http://zyan.cc/architect_solitaire/#blogcomment7572 http://zyan.cc/architect_solitaire/#blogcomment7573 air max <leesuabn@gmail.com> Thu, 06 Jan 2011 13:39:29 +0000 http://zyan.cc/architect_solitaire/#blogcomment7573 http://www.byairmax.com ]]> http://zyan.cc/architect_solitaire/#blogcomment7574 gaoyongzhi <user@domain.com> Thu, 06 Jan 2011 14:10:46 +0000 http://zyan.cc/architect_solitaire/#blogcomment7574 http://zyan.cc/architect_solitaire/#blogcomment7575 Apple <user@domain.com> Thu, 06 Jan 2011 14:58:32 +0000 http://zyan.cc/architect_solitaire/#blogcomment7575 http://zyan.cc/architect_solitaire/#blogcomment7577 mcsrainbow <user@domain.com> Fri, 07 Jan 2011 01:52:27 +0000 http://zyan.cc/architect_solitaire/#blogcomment7577 http://zyan.cc/architect_solitaire/#blogcomment7578 硬盘被格 <gjflsl111@gmail.com> Fri, 07 Jan 2011 01:57:30 +0000 http://zyan.cc/architect_solitaire/#blogcomment7578 http://zyan.cc/architect_solitaire/#blogcomment7580 校慰 <user@domain.com> Fri, 07 Jan 2011 03:52:03 +0000 http://zyan.cc/architect_solitaire/#blogcomment7580 http://zyan.cc/architect_solitaire/#blogcomment7581 Cheech <user@domain.com> Fri, 07 Jan 2011 04:53:47 +0000 http://zyan.cc/architect_solitaire/#blogcomment7581