【IT168 专稿】
FreeWheel是由前DoubleClick高管Douglas Knopper, Jon Heller和Diane Yu于2007年创建，由硅谷优异的风险投资机构Battery Ventures投资的互联网视频广告技术服务提供商，总部位于硅谷的Palo Alto，提供互联网视频广告投放、监测、预测和内容互联增值等关键解决方案。不同于其他外资企业，FreeWheel的研发中心设在中国，数据运营中心则设立在美国纽约。
FreeWheel北京研发团队成立两年多来，在敏捷软件开发、Ruby On Rails开发大型复杂商业系统、视频广告技术、完全离岸的产品研发与跨国运营等方面受到关注。本文将谈谈FreeWheel在高性能、高流量互联网应用系统架构设计上所遵循的基本原则。
原则一：假设故障总会发生（Design with failure in mind）
在设计和实现大型互联网在线应用时，架构师必须考虑到系统各模块、各应用服务器、各开源应用软件的故障比率和失效的潜在原因。当服务的可用性（Availability）成为系统设计的首要目标时，尤其需要在设计阶段就充分考虑如何在系统某部分发生故障时，仍然保持一定的服务可用性。一些基本的假设包括：
·没有Bug的软件不存在，只是故障率高低不同，应优先关注高故障率应用。
·硬件总会发生故障，需要备份和冗余。
·导致某应用崩溃的请求，如不能及时终止或被redirect，可能会导致所有服务器一个接一个的瘫痪。
·构建仅包括最简单输入输出逻辑和固定输出内容的Dot 模式Server，以应对应用服务群大面积瘫痪或负载极限发生时的服务响应。
·每次release正式升级前，在模拟生产环境的Staging环境运行版本测试
原则二：数据分区处理（Partition Your Data）
在分布式计算环境下，如何高效的处理海量数据？如何在Bug发生后更加容易的重新批处理？一个基本的设计原则就是分区（Partition），即将待处理信息按照生成节点、内在一致性（Self Contain）、时间等因素进行分组，让每个平行处理节点可尽量仅处理切分后的数据，而减少节点间的数据交换。分区的基本原则包括：
·应用流量均衡Load Balance和数据分区结合
·容易在分组内进行再分区
·减少分组数据之间的状态依赖
·减少数据中心之间的数据交换
原则三：冗余（Redundancy）
冗余几乎是高可用系统设计的必然选择，也是老生常谈的话题，然而如何做到成本与效率的非常好的平衡则是架构设计考虑的重点。可以参考的经验包括：
·优先减少单点故障。
·单个应用可快速重启恢复。
·应用间减少启动和运行依赖，尽量可独立工作。
·与其依赖热备冗余，不如建立服务中断后的快速恢复预案（依赖热备系统，在实战中总是很难理想地恢复全部服务）。
