iPhone大小的盒子服务器Cubieboard
[
2013-3-25 15:57 | by 张宴 ]
2013-3-25 15:57 | by 张宴 ]
在淘宝上350多元，买了个基于ARM平台的超小电脑 cubieboard，配置如下：
1G ARM cortex-A8 processor, NEON, VFPv3, 256KB L2 cache
Mali400, OpenGL ES GPU
512M/1GB DDR3 @480MHz
HDMI 1080p Output
10/100M Ethernet
4GB Nand Flash
2 USB Host, 1 micro SD slot, 1 SATA, 1 ir
96 extend pin including I2C, SPI, RGB/LVDS, CSI/TS, FM-IN, ADC, CVBS, VGA, SPDIF-OUT, R-TP..
Running Android, Ubuntu and other Linux distributions
找了台支持HDMI的显示器，安装了Ubuntu Linaro，然后很方便的安装了SSH Server、VNC Server、Nginx、PHP 5.3、MySQL 5.5：
C/C++的开发环境安装：
1G ARM cortex-A8 processor, NEON, VFPv3, 256KB L2 cache
Mali400, OpenGL ES GPU
512M/1GB DDR3 @480MHz
HDMI 1080p Output
10/100M Ethernet
4GB Nand Flash
2 USB Host, 1 micro SD slot, 1 SATA, 1 ir
96 extend pin including I2C, SPI, RGB/LVDS, CSI/TS, FM-IN, ADC, CVBS, VGA, SPDIF-OUT, R-TP..
Running Android, Ubuntu and other Linux distributions
找了台支持HDMI的显示器，安装了Ubuntu Linaro，然后很方便的安装了SSH Server、VNC Server、Nginx、PHP 5.3、MySQL 5.5：
apt-get install openssh-server
apt-get install vnc-server
apt-get install mysql-server mysql-client
apt-get install nginx
apt-get install php5-fpm
apt-get install php5-mysql php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-ming php5-ps php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
apt-get install vnc-server
apt-get install mysql-server mysql-client
apt-get install nginx
apt-get install php5-fpm
apt-get install php5-mysql php5-curl php5-gd php5-intl php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-ming php5-ps php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl
C/C++的开发环境安装：
apt-get install gcc
apt-get install g++
apt-get install cmake
apt-get install make
apt-get install g++
apt-get install cmake
apt-get install make
架构师接龙：盛大许式伟 VS 金山张宴
[ 2011-1-6 13:12 | by 张宴 ]
2011-1-6 13:12 | by 张宴 ]
（本文来自《程序员》杂志2011年01期，《程序员》官网地址：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周。
许式伟：您通过哪些手段，来保障产品的质量？您倾向于多久更新一次您的网站？
主持人：冯大辉，现任丁香园 （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周。
许式伟：您通过哪些手段，来保障产品的质量？您倾向于多久更新一次您的网站？
数据仓库与Web商业智能平台架构设计
[ 2010-7-23 18:12 | by 张宴 ]
2010-7-23 18:12 | by 张宴 ]
此文为《程序员》杂志约稿，发表在2010年6月刊。
文章以“KBI用户行为分析”的项目架构为原型，对Web商业智能平台的架构设计进行了概要介绍。实现海量数据的分析挖掘计算相对较易，如何以灵活的可扩展性框架，来便捷地应对项目开发周期中，来自众多项目干系人的需求变更，才是难点。
文章以“KBI用户行为分析”的项目架构为原型，对Web商业智能平台的架构设计进行了概要介绍。实现海量数据的分析挖掘计算相对较易，如何以灵活的可扩展性框架，来便捷地应对项目开发周期中，来自众多项目干系人的需求变更，才是难点。
从“军事战争”总结了一些服务器架构思考[原创]
[ 2009-5-28 15:31 | by 张宴 ]
2009-5-28 15:31 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2009.05.28 转载请注明原文链接：http://blog.zyan.cc/post/414/]
“客户端访问”与“服务器端响应”，犹如一场战争。初期，访问量较小，弄几台服务器随便拉起一只队伍，就能抵抗住客户端的进攻。慢慢的，访问量大起来，这时候，就需要讲究排兵布阵、战略战术、多兵种协调作战。于是，开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种；开始有了系统架构等战略战术。随着新项目和运营需求的越来越多，我们开始了多线作战。慢慢地，我总结了以下一些思考：
1、“收编绿林队伍”与“自己招兵买马”：
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”，如果已有的开源软件、框架、架构能够较好地用于自己的项目，并便于扩展，则优先使用开源软件；如果没有现成的东西，或者已有的开源软件性能不高、扩展性差、学习成本高，则可以取长补短，在项目中打造自己的“队伍”。
2、适当利用“雇佣军”：
在多个项目同时进行时，不要认为自己能打赢每一场战斗，而每一场战斗都由自己亲自去打。确实，我相信很多人能够打赢一场场战斗，却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭，印证了这样一个事实：一群天才，却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲，自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统，最终自己被自己给拖垮了。
不要让战线拉得太广，适当利用“雇佣军”，项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务，时间、费用、维护成本可能要更低。最近，我工作中的两项服务使用了“雇佣军”：(1)、购买ChinaCache CDN的Flash Media Server点播加速服务，支撑金山游戏视频宣传站点，节省了部署多节点的成本和时间；(2)、购买快网的智能DNS解析服务，来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务，节省了收集、整理，将来更新维护IP信息等工作。
3、打造“高技术兵器”：
现代战争的特点都拥一个有共同的前提那就是：都不可能离开“高技术兵器”。同样，要想承担高并发访问，而又希望系统架构简单一点、程序开发快捷一点，那么，则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页，内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存，高并发访问下需要实时更新的列表页缓存，目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下，实时更新的列表页，成为最主要的瓶颈。我目前正在基于一些开源类库，开发的一款简单关系型数据库，将实现MySQL单表拥有的大部分复杂条件查询功能，并将达到单表千万级以上记录下，Memcached 60%左右的并发查询性能，预计6月6日开发完成进入测试阶段。
4、精简军队，提高战斗力：
军队越多，补给、后勤等开支也会越大，同样，服务器越多，维护成本、托管成本、复杂度也越高。所以，服务器不是越多越好，在能够保证容错性、避免单点故障的情况下，如果能用一台高配置服务器来解决的事，不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等，技术含量并不是特别高，只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降，单台服务器扩充到64G内存的事情不再罕见；Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高，我预测，将来的系统架构与服务器集群将不再从服务类型上划分，而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序，也逐渐向后者转移。
最近，Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文，提出了一个数据中心就是一台计算机（The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines ）
“客户端访问”与“服务器端响应”，犹如一场战争。初期，访问量较小，弄几台服务器随便拉起一只队伍，就能抵抗住客户端的进攻。慢慢的，访问量大起来，这时候，就需要讲究排兵布阵、战略战术、多兵种协调作战。于是，开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种；开始有了系统架构等战略战术。随着新项目和运营需求的越来越多，我们开始了多线作战。慢慢地，我总结了以下一些思考：
1、“收编绿林队伍”与“自己招兵买马”：
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”，如果已有的开源软件、框架、架构能够较好地用于自己的项目，并便于扩展，则优先使用开源软件；如果没有现成的东西，或者已有的开源软件性能不高、扩展性差、学习成本高，则可以取长补短，在项目中打造自己的“队伍”。
2、适当利用“雇佣军”：
在多个项目同时进行时，不要认为自己能打赢每一场战斗，而每一场战斗都由自己亲自去打。确实，我相信很多人能够打赢一场场战斗，却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭，印证了这样一个事实：一群天才，却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲，自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统，最终自己被自己给拖垮了。
不要让战线拉得太广，适当利用“雇佣军”，项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务，时间、费用、维护成本可能要更低。最近，我工作中的两项服务使用了“雇佣军”：(1)、购买ChinaCache CDN的Flash Media Server点播加速服务，支撑金山游戏视频宣传站点，节省了部署多节点的成本和时间；(2)、购买快网的智能DNS解析服务，来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务，节省了收集、整理，将来更新维护IP信息等工作。
3、打造“高技术兵器”：
现代战争的特点都拥一个有共同的前提那就是：都不可能离开“高技术兵器”。同样，要想承担高并发访问，而又希望系统架构简单一点、程序开发快捷一点，那么，则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页，内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存，高并发访问下需要实时更新的列表页缓存，目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下，实时更新的列表页，成为最主要的瓶颈。我目前正在基于一些开源类库，开发的一款简单关系型数据库，将实现MySQL单表拥有的大部分复杂条件查询功能，并将达到单表千万级以上记录下，Memcached 60%左右的并发查询性能，预计6月6日开发完成进入测试阶段。
4、精简军队，提高战斗力：
军队越多，补给、后勤等开支也会越大，同样，服务器越多，维护成本、托管成本、复杂度也越高。所以，服务器不是越多越好，在能够保证容错性、避免单点故障的情况下，如果能用一台高配置服务器来解决的事，不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等，技术含量并不是特别高，只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降，单台服务器扩充到64G内存的事情不再罕见；Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高，我预测，将来的系统架构与服务器集群将不再从服务类型上划分，而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序，也逐渐向后者转移。
最近，Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文，提出了一个数据中心就是一台计算机（The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines ）
珠海金山软件之行[原创]
[ 2009-4-19 23:56 | by 张宴 ]
2009-4-19 23:56 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2009.04.19 转载请注明原文链接：http://blog.zyan.cc/post/410/]
2009年4月14日（星期二）
下班后，和同事打的到首都国际机场，乘21:10起飞的中国南方航空CZ3734航班飞往珠海。这也是我第一次坐飞机。
波音737穿越着宁静的天空，云端望月的景象，罕见而优美。经过的三个小时的飞行，掠过了大半个中国，飞机降落在珠海三灶机场。
走出飞机，打的前往吉大区的如家快捷酒店，沿途海风扑面，湿气弥漫，与北京的干燥行成鲜明的对比。
2009年4月15日（星期三）
上午10点，我们去了珠海金山软件公司，在“万花谷”会议室跟西山居工作室开了个小会，随后参观了三楼的《剑侠世界》研发团队和四楼的《剑侠情缘网络版3》研发团队，向他们请教了100多人协作开发的项目管理经验。
下午，跟金山网游公司CTO的会议，是我主要关心的议题，以下几项收获也不错：
1、我所设计的“广州电信机房、天津网通机房、北京电信通多线机房”三个核心IDC的系统架构得以通过，只是做了点小调整，将“广州电信机房”换成了“珠海电信机房”，因为金山享有珠海电信在带宽和线路上的特殊待遇。
PS：百度网页搜索前端服务器也分布在三个机房：北京电信机房、北京网通机房、北京长城宽带多线机房。
全国所有电信用户访问 www.baidu.com 将被解析到以下两个VIP：
220.181.6.19 （北京市·电信）
220.181.6.18 （北京市·电信）
全国所有网通用户访问 www.baidu.com 将被解析到以下两个VIP：
202.108.22.5 （北京市·网通）
202.108.22.43 （北京市·网通）
全国铁通、教育网等其他访问 www.baidu.com 将被解析到以下两个VIP：
119.75.213.50 （北京市·长城宽带）
119.75.213.51 （北京市·长城宽带）
2、获批了20台服务器。搭建我三个IDC的架构平台，硬件资源得以满足，剩下要解决的就是这20台服务器尽快到位的问题了。
3、允许了将来购买 Adobe 即将推出的 Flash Media Server 4.0 授权，利用 Flash Player 10 和 RTMFP协议（支持P2P）提供 FLV/MP4(H264) 视频流媒体点播服务。
目前逍遥网《基于开源Flash Server：Red5构建RTMP流媒体播放平台》，采用的是 RTMP 协议，生产环境（剑网3相关视频：http://jx3.xoyo.com/xgxz/video/）平均每个视频播放所消耗的带宽是25KB/秒，100M独享带宽可以支撑500人同时在线观看。将来采用 RTMFP 协议进行 Flash P2P 视频点播服务，将大大地节省带宽。
RTMFP 是 Real‐Time Media Flow Protocol的缩写，是Adobe推出的一种新的通信协议，这种通信协议可以让 Flash 客户端直接和另外一个Flash 客户端之间进行数据通信，也就是常说的P2P的方式进行通信。
RTMFP 将会大大地减少音视频直播、点播、多人在线游戏等应用的网络带宽的消耗，减轻服务器的负担。因为很多数据都是客户端之间直接传输了，无须再经过服务器中转了。RTMFP由于使用了UDP网络协议，所以相对之前的TCP协议在数据传输效率上也会大大提高，这种优势在音视频数据传输方面是非常明显的。
下面的示意图表现了RTMFP和RTMP的不同之处：
2009年4月14日（星期二）
下班后，和同事打的到首都国际机场，乘21:10起飞的中国南方航空CZ3734航班飞往珠海。这也是我第一次坐飞机。
波音737穿越着宁静的天空，云端望月的景象，罕见而优美。经过的三个小时的飞行，掠过了大半个中国，飞机降落在珠海三灶机场。
走出飞机，打的前往吉大区的如家快捷酒店，沿途海风扑面，湿气弥漫，与北京的干燥行成鲜明的对比。
2009年4月15日（星期三）
上午10点，我们去了珠海金山软件公司，在“万花谷”会议室跟西山居工作室开了个小会，随后参观了三楼的《剑侠世界》研发团队和四楼的《剑侠情缘网络版3》研发团队，向他们请教了100多人协作开发的项目管理经验。
下午，跟金山网游公司CTO的会议，是我主要关心的议题，以下几项收获也不错：
1、我所设计的“广州电信机房、天津网通机房、北京电信通多线机房”三个核心IDC的系统架构得以通过，只是做了点小调整，将“广州电信机房”换成了“珠海电信机房”，因为金山享有珠海电信在带宽和线路上的特殊待遇。
PS：百度网页搜索前端服务器也分布在三个机房：北京电信机房、北京网通机房、北京长城宽带多线机房。
全国所有电信用户访问 www.baidu.com 将被解析到以下两个VIP：
220.181.6.19 （北京市·电信）
220.181.6.18 （北京市·电信）
全国所有网通用户访问 www.baidu.com 将被解析到以下两个VIP：
202.108.22.5 （北京市·网通）
202.108.22.43 （北京市·网通）
全国铁通、教育网等其他访问 www.baidu.com 将被解析到以下两个VIP：
119.75.213.50 （北京市·长城宽带）
119.75.213.51 （北京市·长城宽带）
2、获批了20台服务器。搭建我三个IDC的架构平台，硬件资源得以满足，剩下要解决的就是这20台服务器尽快到位的问题了。
3、允许了将来购买 Adobe 即将推出的 Flash Media Server 4.0 授权，利用 Flash Player 10 和 RTMFP协议（支持P2P）提供 FLV/MP4(H264) 视频流媒体点播服务。
目前逍遥网《基于开源Flash Server：Red5构建RTMP流媒体播放平台》，采用的是 RTMP 协议，生产环境（剑网3相关视频：http://jx3.xoyo.com/xgxz/video/）平均每个视频播放所消耗的带宽是25KB/秒，100M独享带宽可以支撑500人同时在线观看。将来采用 RTMFP 协议进行 Flash P2P 视频点播服务，将大大地节省带宽。
RTMFP 是 Real‐Time Media Flow Protocol的缩写，是Adobe推出的一种新的通信协议，这种通信协议可以让 Flash 客户端直接和另外一个Flash 客户端之间进行数据通信，也就是常说的P2P的方式进行通信。
RTMFP 将会大大地减少音视频直播、点播、多人在线游戏等应用的网络带宽的消耗，减轻服务器的负担。因为很多数据都是客户端之间直接传输了，无须再经过服务器中转了。RTMFP由于使用了UDP网络协议，所以相对之前的TCP协议在数据传输效率上也会大大提高，这种优势在音视频数据传输方面是非常明显的。
下面的示意图表现了RTMFP和RTMP的不同之处：
Google 构建大规模信息检索系统中的挑战
[ 2009-4-5 00:07 | by 张宴 ]
2009-4-5 00:07 | by 张宴 ]
以下是 Google 检索系统的架构师、Google Mapreduce 的发明者 Jeff Dean 在 WSDM 2009 上的主题演讲：《Challenges in Building Large-Scale Information Retrieval Systems》。在这个主题演讲中，Jeff Dean 讲述了 Google 在10年中，Google 检索系统的演变和发展。
英文原文：http://research.google.com/people/jeff/WSDM09-keynote.pdf
演讲视频：http://videolectures.net/wsdm09_dean_cblirs/
中文译文（由银杏泰克有限公司郝培强翻译）：
英文原文：http://research.google.com/people/jeff/WSDM09-keynote.pdf
演讲视频：http://videolectures.net/wsdm09_dean_cblirs/
中文译文（由银杏泰克有限公司郝培强翻译）：
使用Nginx轻松实现开源负载均衡──9月20日在ChinaUnix技术沙龙上的演讲PPT[原创]
[ 2008-9-21 13:21 | by 张宴 ]
2008-9-21 13:21 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2008.09.21 转载请注明原文链接：http://blog.zyan.cc/post/369/]
9月20日下午，我应邀参加了 ChinaUnix 举办的以“如何搞定服务器负载均衡？”为主题的技术沙龙（http://linux.chinaunix.net/bbs/thread-1019366-1-1.html），很高兴能够跟诸多业界精英一起探讨交流，很荣幸能够与Unix资深系统工程师──田逸、HonestQiao，以及F5资深技术工程师──杨明非，同台演讲。
《使用Nginx轻松实现开源负载均衡》是我的演讲PPT（PowerPiont），现提供下载。
PPT分为四个部分：
1、介绍Nginx的基本特征，以及使用Nginx做负载均衡器的理由。
2、用实例，来介绍Nginx负载均衡在大型网站的典型应用。
3、以实现网站动静分离为原型，对NetScaler硬件七层负载均衡和Nginx软件负载均衡做一个对比。
9月20日下午，我应邀参加了 ChinaUnix 举办的以“如何搞定服务器负载均衡？”为主题的技术沙龙（http://linux.chinaunix.net/bbs/thread-1019366-1-1.html），很高兴能够跟诸多业界精英一起探讨交流，很荣幸能够与Unix资深系统工程师──田逸、HonestQiao，以及F5资深技术工程师──杨明非，同台演讲。
《使用Nginx轻松实现开源负载均衡》是我的演讲PPT（PowerPiont），现提供下载。
PPT分为四个部分：
1、介绍Nginx的基本特征，以及使用Nginx做负载均衡器的理由。
2、用实例，来介绍Nginx负载均衡在大型网站的典型应用。
3、以实现网站动静分离为原型，对NetScaler硬件七层负载均衡和Nginx软件负载均衡做一个对比。
利用NetScaler和自行编写的健康检查脚本，完美解决多台MySQL Slave数据库的负载均衡[原创]
[ 2008-5-29 23:21 | by 张宴 ]
2008-5-29 23:21 | by 张宴 ]
[文章作者：张宴 本文版本：v1.1 最后修改：2008.07.17 转载请注明出自：http://blog.zyan.cc]
Citrix NetScaler是一款不错的4-7层硬件负载均衡交换机，市场占有率仅次于F5 BIG-IP，位居第二。NetScaler 8.0是美国思杰系统有限公司（Citrix Systems, Inc）正式推出的最新版本NetScaler产品系列。
从我的实际测试来看，NetScaler 8.0在七层负载均衡方面，性能和功能都要比F5 BIG-IP强。
NetScaler 8.0的负载均衡监控中，可以对MySQL数据库进行健康检查，而F5 BIG-IP目前只支持对Oracle和Microsoft SQL Server数据库的健康检查。
但是，NetScaler 8.0自带的MySQL健康检查脚本（nsmysql.pl）并不完善，它只能检查一条SQL语句执行是否出错，并不能检查MySQL主从结构中的MySQL Slave数据库同步是否正常、表有无损坏、同步延迟是否过大、是否出现错误、非sleeping状态的连程数是否过高等情况。于是，我根据自己的需要，为NetScaler 8.0写了一个MySQL Slave数据库负载均衡健康检查脚本（nsmysql-slave.pl），实现了上述需求。
有了“nsmysql-slave.pl”做健康检查，利用NetScaler的VIP（虚拟IP），就可以完美实现多台MySQL Slave数据库的负载均衡了。当一台MySQL Slave数据库出现不同步、表损坏、同步延迟过大（本脚本中默认设置的落后MySQL主库600秒视为延迟，可根据具体应用修改）、活动连程数太高（本脚本中默认设置的是大于200视为连程数太高，可根据具体应用修改）等情况，“nsmysql-slave.pl”就会自动将其检查出来，并告知NetScaler，NetScaler会将该数据库标识为宕机，从而不将用户的查询请求传送到这台发生故障的数据库上。故障一旦修复，“nsmysql-slave.pl”会自动告知NetScaler，该数据库已经可以使用。
“nsmysql-slave.pl”源代码如下：
Citrix NetScaler是一款不错的4-7层硬件负载均衡交换机，市场占有率仅次于F5 BIG-IP，位居第二。NetScaler 8.0是美国思杰系统有限公司（Citrix Systems, Inc）正式推出的最新版本NetScaler产品系列。
从我的实际测试来看，NetScaler 8.0在七层负载均衡方面，性能和功能都要比F5 BIG-IP强。
NetScaler 8.0的负载均衡监控中，可以对MySQL数据库进行健康检查，而F5 BIG-IP目前只支持对Oracle和Microsoft SQL Server数据库的健康检查。
但是，NetScaler 8.0自带的MySQL健康检查脚本（nsmysql.pl）并不完善，它只能检查一条SQL语句执行是否出错，并不能检查MySQL主从结构中的MySQL Slave数据库同步是否正常、表有无损坏、同步延迟是否过大、是否出现错误、非sleeping状态的连程数是否过高等情况。于是，我根据自己的需要，为NetScaler 8.0写了一个MySQL Slave数据库负载均衡健康检查脚本（nsmysql-slave.pl），实现了上述需求。
有了“nsmysql-slave.pl”做健康检查，利用NetScaler的VIP（虚拟IP），就可以完美实现多台MySQL Slave数据库的负载均衡了。当一台MySQL Slave数据库出现不同步、表损坏、同步延迟过大（本脚本中默认设置的落后MySQL主库600秒视为延迟，可根据具体应用修改）、活动连程数太高（本脚本中默认设置的是大于200视为连程数太高，可根据具体应用修改）等情况，“nsmysql-slave.pl”就会自动将其检查出来，并告知NetScaler，NetScaler会将该数据库标识为宕机，从而不将用户的查询请求传送到这台发生故障的数据库上。故障一旦修复，“nsmysql-slave.pl”会自动告知NetScaler，该数据库已经可以使用。
“nsmysql-slave.pl”源代码如下：
F5 BIG-IP负载均衡器配置实例与Web管理界面体验[原创]
[ 2008-5-22 23:33 | by 张宴 ]
2008-5-22 23:33 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2008.05.22 转载请注明出自：http://blog.zyan.cc/f5_big_ip]
前言：最近一直在对比测试F5 BIG-IP和Citrix NetScaler负载均衡器的各项性能，于是写下此篇文章，记录F5 BIG-IP的常见应用配置方法。
目前，许多厂商推出了专用于平衡服务器负载的负载均衡器，如F5 Network公司的BIG-IP，Citrix公司的NetScaler。F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。
以下是F5 BIG-IP用作HTTP负载均衡器的主要功能：
①、F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。
②、F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
③、F5 BIG-IP具有动态Session的会话保持功能。
④、F5 BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。
下面，结合实例，配置F5 BIG-IP LTM v9.x：
①、如图，假设域名blog.zyan.cc被解析到F5的外网/公网虚拟IP：61.1.1.3（vs_squid），该虚拟IP下有一个服务器池（pool_squid），该服务器池下包含两台真实的Squid服务器（192.168.1.11和192.168.1.12）。
②、如果Squid缓存未命中，则会请求F5的内网虚拟IP：192.168.1.3（vs_apache），该虚拟IP下有一个默认服务器池（pool_apache_default），该服务器池下包含两台真实的Apache服务器（192.168.1.21和192.168.1.22），当该虚拟IP匹配iRules规则时，则会访问另外一个服务器池（pool_apache_irules），该服务器池下同样包含两台真实的Apache服务器（192.168.1.23和192.168.1.24）。
③、另外，所有真实服务器的默认网关指向F5的自身内网IP，即192.168.1.2。
④、所有的真实服务器通过SNAT IP地址61.1.1.4访问互联网。
详细配置步骤：
前言：最近一直在对比测试F5 BIG-IP和Citrix NetScaler负载均衡器的各项性能，于是写下此篇文章，记录F5 BIG-IP的常见应用配置方法。
目前，许多厂商推出了专用于平衡服务器负载的负载均衡器，如F5 Network公司的BIG-IP，Citrix公司的NetScaler。F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。
以下是F5 BIG-IP用作HTTP负载均衡器的主要功能：
①、F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。
②、F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
③、F5 BIG-IP具有动态Session的会话保持功能。
④、F5 BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。
下面，结合实例，配置F5 BIG-IP LTM v9.x：
①、如图，假设域名blog.zyan.cc被解析到F5的外网/公网虚拟IP：61.1.1.3（vs_squid），该虚拟IP下有一个服务器池（pool_squid），该服务器池下包含两台真实的Squid服务器（192.168.1.11和192.168.1.12）。
②、如果Squid缓存未命中，则会请求F5的内网虚拟IP：192.168.1.3（vs_apache），该虚拟IP下有一个默认服务器池（pool_apache_default），该服务器池下包含两台真实的Apache服务器（192.168.1.21和192.168.1.22），当该虚拟IP匹配iRules规则时，则会访问另外一个服务器池（pool_apache_irules），该服务器池下同样包含两台真实的Apache服务器（192.168.1.23和192.168.1.24）。
③、另外，所有真实服务器的默认网关指向F5的自身内网IP，即192.168.1.2。
④、所有的真实服务器通过SNAT IP地址61.1.1.4访问互联网。
详细配置步骤：
YouTube 系统架构
[ 2007-12-27 18:08 | by 张宴 ]
2007-12-27 18:08 | by 张宴 ]
视频演讲：Cuong Do （YouTube/Google 的一位工程部经理）
演讲地点：西雅图扩展性的技术研讨会
Flash Player文件
以下为 Kyle Cordes 根据上述视频写下的文章：
YouTube Scalability Talk
Cuong Do of YouTube / Google recently gave a Google Tech Talk on scalability.
I found it interesting in light of my own comments on YouTube’s 45 TB a while back.
Here are my notes from his talk, a mix of what he said and my commentary:
In the summer of 2006, they grew from 30 million pages per day to 100 million pages per day, in a 4 month period. (Wow! In most organizations, it takes nearly 4 months to pick out, order, install, and set up a few servers.)
YouTube uses Apache for FastCGI serving. (I wonder if things would have been easier for them had they chosen nginx, which is apparently wonderful for FastCGI and less problematic than Lighttpd)
演讲地点：西雅图扩展性的技术研讨会
Flash Player文件以下为 Kyle Cordes 根据上述视频写下的文章：
YouTube Scalability Talk
Cuong Do of YouTube / Google recently gave a Google Tech Talk on scalability.
I found it interesting in light of my own comments on YouTube’s 45 TB a while back.
Here are my notes from his talk, a mix of what he said and my commentary:
In the summer of 2006, they grew from 30 million pages per day to 100 million pages per day, in a 4 month period. (Wow! In most organizations, it takes nearly 4 months to pick out, order, install, and set up a few servers.)
YouTube uses Apache for FastCGI serving. (I wonder if things would have been easier for them had they chosen nginx, which is apparently wonderful for FastCGI and less problematic than Lighttpd)
