原则一:假设故障总会发生(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大会演讲内容基础上部分整理。
分享到:
相关推荐
, 《高性能网站构建实战》从高性能站点的实际需求出发,详细介绍了如何使用当前流行的开源软件和工具构建Web站点所需的各种应用服务环境。全书共分为7篇16章和3个简短的附录。, 第一篇是架构规划篇,也就是第1章,...
详细讲解如何实现一个复杂的缓存系统架构,去直接支撑电商背景下的高并发与高性能的访问,同时基于缓存架构本身所处的复杂分布式系统架构环境下,如何设计与实现一个高可用的分布式系统架构。期望通过本套课程能帮助...
讲解一个真实的、复杂的大型企业级亿级高并发项目,是java架构实战课程。 通过本套课程的学习,可以积累大量架构设计经验,迈入架构师行列。 课程特色: 1、完整的大型电商详情页系统架构:不再只是关注电商详情页...
19 应用数据静态化架构高性能单页Web应用 377 19.1 整体架构 378 19.1.1 CMS系统 379 19.1.2 前端展示系统 380 19.1.3 控制系统 380 19.2 数据和模板动态化 381 19.3 多版本机制 381 19.4 异常问题 382 20 使用...
│ 开篇词 跳出单点思维模式,才能真正理解架构设计.mp4 │ 01 为什么不同类型的业务后台架构模式是通用的?.mp4 │ 05 如何做到异构数据的同步一致性?.mp4 │ 07 如何基于流量回放实现读服务的自动化测试回归...
《亿级流量网站架构核心技术》一书总结并梳理了亿级流量网站高可用和高并发原则,通过实例详细介绍了如何落地这些原则。本书分为四部分:概述、高可用原则、高并发原则、案例实战。从负载均衡、限流、降级、隔离、...
基于Dubbo的分布式系统架构实战 Dubbo负载均衡策略分析 Dubbo服务调试之服务只订阅及服务只注册配置 Dubbo服务接口的设计原则(实战经验) Dubbo设计原理及源码分析 基于Dubbo构建大型分布式电商平台实战雏形 ...
Randy Shoup:Best Practices for Scaling Websites 毛新生:Java在企业级开发中应用 马鉴:Flex体系结构深度剖析 王迪:高性能,高流量,多数据中心互联网应用架构实战-以FreeWheel MRM系统后台为例
高性能存储及文件系统 个性化推荐架构设计和实践搜狐视频 银行数据中心架构创新之路 互联网对传统企业应用架构 基于Kafka-Spark Streaming的数据处理系统及测试 交互式直播推流编码器的设计 Elasticsearch实时高效...
4、项目中采用完全还原企业大数据项目开发场景的方式来讲解,每一个业务模块的讲解都包括了需求分析、方案设计、数据设计、编码实现、功能测试、性能调优等环节,真实还原企业级大数据项目开发场景。 模块简介: 1、...
RocketMQ作为中间件,...所以消息队列可以解决应用解耦、异步消息、流量削锋等问题,是实现高性能、高可用、可伸缩和最终一致性架构中不可以或缺的一环。文档为市场上流行的消息队列以列表对比形式进行分析,比较全面
《Hadoop实战》作为云计算所青睐的分布式架构,Hadoop是一个用Java语言实现的软件框架,在由大量计算机组成的集群中运行海量数据的分布式计算,是谷歌实现云计算的重要基石。《Hadoop实战》分为3个部分,深入浅出地...
│ 03 非功能需求:高可用、高性能、高并发的指标如何计算?.mp4 │ 06 云架构:基础设施是如何做到高可用的?.mp4 │ 08 过载保护:如何通过熔断和限流解决流量过载问题?.mp4 │ 09 KV 存储:etcd 和 Redi...
724.5.4 通过Aggregate包使用Streaming 754.6 使用combiner提升性能 804.7 温故知新 834.8 小结 844.9 更多资源 84第5章 高阶MapReduce 855.1 链接MapReduce作业 855.1.1 顺序链接MapReduce作业 855...
消息中间件,已经成为互联网企业应用系统内部通信的核心手段,是目前企业内主流标配技术,它具有解耦、异步、削峰、签收、事务、流量控制、最终一致性等一系列高性能架构所需功能。 当前使用较多的消息中间件有...
LightSeq 高性能序列处理与生成加速库.pdf RocketMQ5.0,生于云、长于云的新一代&消息、事件、流&融合处理平台.pdf SenseMARS 火星混合现实平台及应用开发的实现与挑战.pdf TDSQL-C PostgreSQL 在云原生架构下的新...
Folly是Facebook的一个开源C++11组件库,它提供了类似Boost库和STL的功能,用于满足大规模高性能的需求。 (2)用C++进行函数式编程 《Quake》作者Carmack认为追求函数式编程有着实在的价值,但劝说所有程序员...
阿里云文件存储:K8s 云原生场景下的共享高性能存储 安全容器的发展与思考 拐点已至, 云原生引领数字化转型升级 拐点已至,云原生引领数字化转型升级易立 函数计算在 双11 小程序场景中的应用 基于 K8s 扩展机制...
它具有解耦、异步、削峰、签收、事务、流量控制、最终一致性等一系列高性能架构所需功能。 当前使用较多的消息中间件有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ等, 本次以Apache的ActiveMQ作为切入点...