高性能、高流量互联网应用系统架构设计上所遵循的基本原则
2010-06-04 15:37
591 查看
高性能
、高
流量互联网
应用
系统
架构
设计
上所遵循的基本原
则。
原则一:假设故障总会发生(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大会演讲内容基础上部分整理。
作者简介:
本文作者系freewheel核心系统技术
总监,email:
wangdieda@hotmail.com
,欢迎交流,今后有机会希望能与大家分享
freewheel在利用hadoop进行日志处理方面的一些心得。
·容易在分组内进行再分区
·减少分组数据之间的状态依赖
·减少数据中心之间的数据交换
、高
流量互联网
应用
系统
架构
设计
上所遵循的基本原
则。
原则一:假设故障总会发生(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大会演讲内容基础上部分整理。
作者简介:
本文作者系freewheel核心系统技术
总监,email:
wangdieda@hotmail.com
,欢迎交流,今后有机会希望能与大家分享
freewheel在利用hadoop进行日志处理方面的一些心得。
·容易在分组内进行再分区
·减少分组数据之间的状态依赖
·减少数据中心之间的数据交换
相关文章推荐
- 高性能、高流量互联网应用架构设计实战原则
- 高性能、高流量互联网应用架构设计实战原则
- 高性能、高流量互联网应用架构设计实战原则
- 高性能、高流量互联网应用架构设计实战原则
- 企业级系统架构设计技术与互联网应用技术结合主题一 大规模并发性能问题探讨
- 应用系统架构设计
- 关于大型ASP.NET应用系统的架构—如何做到高性能高可伸缩性
- 架构设计:系统存储(18)——Redis集群方案:高性能
- [导入]从架构设计到系统实施——基于.NET 3.0的全新企业应用系列课程(7):设计基于MMC 3.0的管理工具.zip(8.70 MB)
- [导入]从架构设计到系统实施——基于.NET 3.0的全新企业应用系列课程(7):设计基于MMC 3.0的管理工具.zip(8.70 MB)
- 架构设计:系统间通信(32)——其他消息中间件及场景应用(下2)
- 应用系统架构设计-补全篇
- 【转帖】应用软件系统架构设计的七种武器
- 企业级互联网分布式系统应用架构学习
- 系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]
- 从架构设计到系统实施-基于.NET 3.0的全新企业应用之设计基于WPF的客户端
- 应用系统架构设计
- 【转】大访问量系统的设计——高并发高流量网站架构
- 系统架构师-基础到企业应用架构-系统设计规范与原则[下篇]
- 【转】应用系统架构设计