大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Jean-Jacques Dubray 译者 胡键 发布于 2008年5月11日
去年,Olaf Zimmermann及其IBM研究院同事开发了一个能促进企业应用开发的架构决策框架。
在实践过程中,捕获架构决策对架构师来说依旧是一个挑战。已知的决策捕获抑制剂包括:项目发起人没兴趣、缺少时间和工具支持不足
他们提出了针对3个决策捕获步骤的概念框架:
- 决策识别 —— 现实:决策识别仅仅基于个人经验,而且[常常是]临时性的。
- 决策制定 —— 现实:决策制定者常常带有个人偏见……他们依赖于过去的经验……[或]……行业趋势。
- 决策执行 —— 现实:训练、架构模板和代码互审是主要的决策执行方法。
通过给决策建模提供一个结构、积极主动的方法,他们意在:
通过决策依赖模型、决策驱动者目录和推荐的决策制定技术来改善决策制定质量
几周前,Cesare Pautasso、Olaf Zimmermann和Frank Leymann在WWW 2008会议(在北京举行)上发表了一篇论文,详细比较了“RESTful Web服务和大型Web服务(Big Web Service)”,对“制定正确架构决策”进行了深入探讨。
首先,作者详细地回顾了每种技术公认的优缺点:集成企业应用可以使用多种不同风格。这个选择……是一个重要架构决策。“大型”Web服务技术栈(SOAP、WSDL、WS-Addressing、WS-ReliableMessaging、WSSecurity等)提供了远程过程调用(RPC)和消息集成风格的互操作性。最近,另一种解决方案被提出来实现跨互联网的远程过程调用:所谓的RESTful Web服务。
分布式系统中关键的架构决策,如选择集成风格和技术,应该以每个备选方案的技术论据和具体交付能力的公平比较为基础。而WS-* 与REST之争已经不幸地退化成了偏见和信仰的争论,这只能导致混乱和无法履行的期望。
在这篇论文中,[作者]在架构原则和决策的基础上,采用了量化方法来比较这两种集成风格。
除了它们公认的复杂性,SOAP消息格式和WSDL接口定义语言作为能在异构中间件系统中提供互操作性的网关技术得到了广泛使用。
自相矛盾的是,这种由当今WS-*工具所提供的将已有软件组件方便地转化为Web服务的能力也会被滥用。这样,避免跨抽象级别的信息泄露就变得很重要。例如,在服务接口中出现服务实现的本地数据类型和语言结构就会引发互操作性问题。这个缺点可通过表述和强制某种设计和编码指南(如契约优先的开发)得到缓解。
RESTful Web服务的简单性是公认的,因为REST利用了现有众所周知的W3C/IETF标准(HTTP、XML、URI、MIME),这种必须的基础设施已经深入人心……
这种轻量级的基础设施,使用极少的工具就能开发其中的服务,获取成本低廉且采用门槛很低。
[但是],关于公认的RESTful Web构建最佳实践存在一些混淆。高端REST(Hi-REST)推荐已被制定,但是它们并不总被所谓的低端REST(Lo-REST)实现遵守……[在实践中]只有2个动词(幂等请求使用GET,其他则使用POST)被使用……[因为]代理和防火墙可能不总是允许建立使用其他动词的HTTP连接……限制导致了一系列的替代方法(workaround),其中“真正的”动词要么使用一个特殊的HTTP头(X-HTTP-Method-Override)发送,要么就——如Ruby on Rails——用一个隐藏框(——method)提交……
接下来,他们基于架构决策框架确定了一个比较方法。他们使用字面含义识别候选决策和替代决策。在使用EST和WS-*时,他们开发了几个记录架构决策的集成场景。他们为每种集成风格创建了一个决策模型,这使得他们能使用一些数据(如决策数量、每个决策的备选数量……)来客观的比较这两个模型。
作者接着继续比较了原则、概念和技术。他们的发现包括:
在原则层次,两种方法有相似的量化特征。
在概念层次,在为WS-* Web服务决策时,必须制定的架构决策更少,而备选方案更多。
在技术层次,必须制定的决策数目相同,但是在构建RESTful Web服务时必须要考虑的备选方案更少。
特别地,作者说明:
这样,就从量化的观点认识了REST公认的简单性。
[但是],据我们的经验,对于RESTful服务非常容易做出的决策会导致显著的开发努力和技术风险,如设计严格的资源规范和它们的URI寻址模式。
作者总结说:
……灵活地使用RESTful服务,特别是跨互联网的集成(以Mashup的方式),对于生命跨度更长和具有高级QoS需求的专业企业应用,优先使用WS-* Web服务。
查看英文原文:A Fair Comparison of REST and WS-* using an Architectural Decision Framework: is the Debate Over?
译者 胡键 热心开源技术,《开源技术选型手册》作者,《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。
本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。
云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。
淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011。
2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。
12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011。
篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011。
本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。
1 条回复
关注此讨论 回复