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）
　　冗余几乎是高可用系统设计的必然选择，也是老生常谈的话题，然而如何做到成本与效率的最佳平衡则是架构设计考虑的重点。可以参考的经验包括：
　　·优先减少单点故障。
　　·单个应用可快速重启恢复。
　　·应用间减少启动和运行依赖，尽量可独立工作。
　　·与其依赖热备冗余，不如建立服务中断后的快速恢复预案（依赖热备系统，在实战中总是很难理想地恢复全部服务）。
    　　原则四：监控，监控，还是监控（Monitor, monitor, monitor）
　　从应用部署到数据中心的第一天开始，就要意识到，没有人能够7x24小时的盯着几十个应用系统，近百个应用程序的运行状态。有没有down机，有没有程序崩溃，有没有数据库死锁，服务是否始终可用，这些不但是困扰工程师的问题，更是牵扯到客户支持，乃至建立产品品牌的重要问题。如果你想"一切尽在掌握"，不想经常（偶尔总是有的，因为未知故障总会发生）在凌晨被运营团队的电话叫醒，那么赶快set up你的自动监控系统，让你的生活轻松起来吧。
　　至少有两大类的Monitor群组需要建立起来：
　　从客户角度：
　　·服务的可用时间/失效时间
　　·服务响应延迟
　　·客户累积服务次数
　　从系统容量角度：
　　·各应用服务器的CPU/内存/存储负载统计
　　·高峰与平均比（Peak to mean ratio）
　　·应用服务失效/崩溃/延迟报警
　　·应用服务自动恢复通知
　　·数据同步延迟和失效警报
　　·后台日常处理日报/周报/月报，趋势图
　　原则五：保持简捷（Keep It Simple Stupid, KISS）
　　传统软件开发中的变更管理是一个难题，在互联网应用系统开发中变更则比过去更加频繁，同时对产品质量的要求则更高。面对这个难题，普遍的结论是，唯一不变的就是变化本身。然而实战中，控制变化的规模和影响，仍然需要找出一些"以不变应万变"的准则，这对于提高产品开发效率和保持高质量至关重要。
　　分清"保持"与"非保持"内容
　　·业务需求总会变化，属于"非保持"，架构设计上充分考虑其变化，而非特化。
　　·而软件本身像一个不断成长进化的生命，有自己的DNA。找到DNA，就找到了"保持"，例如设计的可扩展性，可维护性，可测试性。
　　简单原则
　　·代码写得越多，维护越复杂，需要不断地通过重构来简化。
　　·复杂的系统容易出错，维护成本高，要避免设计单个复杂系统。
　　·如果测试人员需要费九牛二虎之力才能理解"天才"的设计和实现，最好抛弃它。否则有一天你会为测试覆盖率难以提高，故障重现困难而沮丧。
　　原则六：即时架构（Just in Time Architect）
　　即时架构是在寻找最佳设计和资源限制之间所做出的实用选择，此原则可能更加适用于快速变化的软件开发领域，例如互联网，而非严谨的产品线软件开发。"设计"和"重构"成为每个版本开发周期中不断重复的迭代步骤。
　　即时设计
　　·在每个版本只有一个月的设计、开发和测试周期的约束下，要将基础设施（Infrastructure）一次设计到最佳状态是不可能的。
　　·基础架构可满足未来6个月至1年（视业务增长与投入的预测而定）应用的扩展要求即可。
　　即时重构
　　·知道何时、何处需要重构是关键，提前筹划，而不要临阵磨枪。
　　·要为重构预留足够的开发资源。在FreeWheel，新产品开发，现有产品维护和基础架构重构的资源比例大约是25% : 50% : 25%.
　　·重构不是"推到重来"，每次重构一部分要好得多，否则你的测试团队负担太重，会导致产品质量波动。
　　以上是FreeWheel中国研发团队在研发Monetization Rights Management，MRM在线视频广告平台过程中的一些实战经验分享，在QCon 2009 Beijing大会演讲内容基础上部分整理。　

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。