张宴 VS. 岑文初 VS. 许式伟 问答

张宴VS.岑文初

张宴：在项目的架构设计中，对于未来可能发生的需求变更，你是如何考虑的？如何应对？[1] 

岑文初：需求变更可以分为业务性和非业务性两类。

金山张宴VS.淘宝岑文初

对于业务性需求变更，思维方式应当按如下顺序进行：

第一，是否已经有类似功能，需要做些改进就可以满足需求；

第二，没有类似功能，是否可以抽取部分已有功能，再做部分封装即可实现；

第三，完全没有可以复用的内容，考虑一下后续可能的业务需求。

也许上面的内容比较虚，但业务一定是根据场景来做出实际判断，而这三点其实就是一个理念——不断优化业务代码，复用的思考会促进不断地合理化结构（因为大部分情况下，复用性越小的代码其结构本身存在耦合性过强的问题）。

非业务性需求变更主要是指由于系统自身应用场景发生变化（包括处理的数据量、业务规则复杂度等），而使得需要对现有系统做结构性调整。下面我举个例子。

开放平台的日志分析系统，在数据量不断增大和计算实时性要求增强的情况下，由单机多线程计算演变为多机分布式协作计算，从全量文件分析转变为增量基于数据流分析。但整体结构却没有发生太大变化。

最初，系统日访问量为六千万，数据分析报表每日出一次，分析器仅仅用于业务行为分析统计、单机每日拖取全量日志文件、多线程切割分析后合并。系统设计中有统计模型抽象层和简单的任务管理层：统计模型抽象层就是将传统的统计分析抽象成为对无结构化的数据做MapReduce计算，模型规则引擎可以根据配置直接分析无结构化定义的日志数据；任务管理层在第一阶段只是负责任务多线程内分配和管理。

当日志量每日达到两亿，分析器每日分析数据涵盖了系统、ISV、服务提供方，业务多角度分析和数据挖掘、单机I/O及CPU就成为瓶颈。因此，首先修改任务管理层，将原来多线程的任务管理和分配，扩展为支持多机任务管理和分配（基于TCP层的数据交互协议）。数据通信层理所当然地成为承载多机协作的基础层，因为本身没有太多的复杂流程在里面，就直接实现NIO的通信层。这次需求变更的代价就是扩展了任务分配协议以支持多机协作工作，本地的数据合并转变为通信传输后的本地数据合并，但对上层业务分析引擎没有任何影响。

当日志量每日达到八亿，分析器已经应用于整个系统的监控和告警及业务趋势分析等各方面，全量每日分析满足不了业务需求，于是由每日全量分析改变为实时增量分析。这次需要修改任务管理层：首先，扩展了Slave的数据源获取方式，除了支持文件获取，还支持HTTP数据流的获取；其次，扩展了Master对于任务周期的管理，任务列表可以被周期性重置，同时可以周期性导出增量数据，因此实时分析可以通过使用较短周期（分钟级别）的任务列表管理、任务分配、结果合并和增量导出，实现实时的大数据量分析。这次需求变更仅仅是对任务管理的周期做了更灵活的扩展，同时在Slave上做了多数据源数据的获取，对于本身的任务管理、合并、计算都没有任何影响。总之，对于非业务性的需求改变，需要能够将业务性设计和系统设计隔离开来，同时明晰系统设计边界，支持外部接口的可扩展，这样就能够支撑由于系统应用场景的变化带来的系统架构的变化。

许式伟VS.张宴

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

张宴：很多因素都会导致网站发生故障，从而影响网站的高可用性，比如服务器硬件故障、软件系统故障、IDC机

盛大许式伟VS. 金山张宴

房故障、程序上线前测试未发现的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://baike.baidu.com/view/1906052.htm?fr=aladdin