novelly的专栏

英文原文：Scalability Best Practices: Lessons from eBay　　在eBay，可伸缩性是我们每天奋力抵抗的一大架构压力。我们所做的每一项架构及设计决策，身前身后都能看到它的踪影。当我们面对的是全世界数以亿计的用户，每天的页面浏览量超过10亿，系统中的数据量要用皮字节（1015或250）来计算——可伸缩性是生死交关的问题。　　在一个可伸缩的架

在7月10日举行的淘宝技术嘉年华之淘宝技术专场上，来自淘宝产品技术部中间件团队的曾宪杰（花名华黎）为大家介绍了近几年Java在淘宝的应用情况――《Java@Taobao》。演讲之初，曾宪杰先分四个阶段介绍了淘宝的建构变迁：2003年5月至2004年5月，小而快的简单架构，基于LAMP，符合当时的需求。2004年2月至2008年3月，一个懵懂的阶段，开始分为多个层次。这个阶段

美国程序员Jon Scott Stevens，公布了他的创业公司所使用的开发工具清单。他的语言平台是Java，开发项目是一个网站（还未上线）。所用到的工具都是开源的，可以免费得到。在目前的创业者之中，用Java作为网站开发语言的人似乎很少。这当然不是没有原因的，Java看上去确实不像是最便捷的网站开发工具，给人的感觉是用起来麻烦又费事。但是不可否认的是，Java的平

互联网的网站和大部分企业管理软件一样都是使用B/S架构模型，但是大型的公共网站B/S架构会更加复杂，对架构人员的要求更高，今天我想在自己博客里聊聊我设计的网站的B/S技术架构。　　不管是B/S架构的企业管理系统还是网站技术架构可以抽象为如下简图：　　在传统B/S架构的企业管理系统里，技术架构往往就是一个工程项目，各个逻辑分层都是该工程的业务逻辑模块。但是作为提供公共服务的网

Tair是由淘宝网自主开发的Key/Value结构数据存储系统，在淘宝网有着大规模的应用。您在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候，都在直接或间接地和Tair交互。Tair于2010年6月30号在淘宝开源平台上正式对外开源，本文较详细地介绍了Tair提供的功能及其实现的细节，希望对大家进一步了解Tair有所帮助。Tair的功能Tair是一个Key/V

作者: 赵超  发布时间: 2012-02-25 11:32    原文链接   　　目录　　一、引言　　二、个人网站　　三、Oracle/支付宝/旺旺　　四、淘宝技术发展（Java时代：脱胎换骨）　　五、淘宝技术发展（Java时代：坚若磐石）　　六、淘宝技术发展（Java时代：创造技术-TFS）　　七、淘宝技术发展（分布式时

通俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点，你可以说：Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。 下面让我们来细细道来： Web服务器(Web Serv

GPS定位数据库表设计在开发工业系统的数据采集功能相关的系统时，由于数据都是定时上传的，如每20秒上传一次的时间序列数据，这些数据在经过处理和计算后，变成了与时间轴有关的历史数据（与股票数据相似，如下图的车辆行驶过程中的油量曲线、历史轨迹数据等）。当采集点多的时候，如上万个采集终端，再加上时间的累积，数据表会变得越来越大。数据库会越来越难以维护。对历史数据操作的功能有历史数据的查询

淘宝网拥有国内最具商业价值的海量数据。截至当前，每天有超过30亿的店铺、商品浏览记录，10亿在线商品数，上千万的成交、收藏和评价数据。如何从这些数据中挖掘出真正的商业价值，进而帮助淘宝、商家进行企业的数据化运营，帮助消费者进行理性的购物决策，是淘宝数据平台与产品部的使命。为此，我们进行了一系列数据产品的研发，比如为大家所熟知的量子统计、数据魔方和淘宝指数等。尽管从业务层面来讲，数据产品的研

随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。AD：2013大数据全球技术峰会课程PPT下载一个小型的网站，比如个人网站，可以使用最简单的

作者: 醉梦独倚  发布时间: 2012-12-11 22:04  阅读: 4899 次  推荐: 23   原文链接   [收藏]  　　1、软件长期运营存在什么问题　　一个大规模的客户端软件的生命周期中，我们可以把它分为两个比较粗的时期。一个是前期的搭建软件的时期，即从无到有的时期；第二个是搭建完成之后，进入的一个稳定的运营时期。第二个时期才是最关键的，在这个时期我们会持续的迭

原文链接：The Pragmatic Architect - To Boldly Go Where No One Has Gone Before　　本文首次发表在 IEEE Software ，并由 InfoQ 和 IEEE 计算机协会为您引进。　　是什么让架构师们精通自己的技艺？熟练的架构师是如何进行设计的？一次次，有人问起我这些问题，而我也不止一遍的问我自己。很明显，这并不

双“11”最热门的话题是TB ，最近正好和阿里的一个朋友聊淘宝的技术架构，发现很多有意思的地方，分享一下他们的解析资料：　　淘宝海量数据产品技术架构　　数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。这为我们设计缓存奠定了非常重要的基础。 图1 淘宝海量数据产品技术架构　　按照数据的流向来划分，我

上一篇 事务原理http://rdc.taobao.com/team/jm/archives/1362单机事务:其实在上面介绍ACID的时候我们已经提到了一种最简单的实现方式，就是锁的实现方式。从原理来看，事务是个变态而复杂的事情。其实如果是序列化的话呢，那么实现起来一定是非常简单的。但问题就在于，这样性能实在比较低，于是，就有了非常多的方案，为了能哪怕减少

很久木有和大家见面了，因为博主也需要时间来沉淀。。博主也需要学习和思考。。好吧，不多废话，进入正题，今天我们谈的东西是一致性和安全性。一致性这个问题，非常绕，想用语言表述，难度很大，我给别人去讲的时候，一般都是白板，因为白板有类似“动画”的效果，能够帮助别人理解，但使用文字，就没有办法了，只好要求各位有一定的抽象思维能力，能在自己的脑袋里模拟这种动画吧:) 主要会聊

http://rdc.taobao.com/team/jm/archives/1411 上一篇ps : 最近霸神推了一把，粉丝增加不少，顿时亚历山大。。还是希望大家用轻松一点的心态来看待我的这些科普文。如果想精细推敲，欢迎在后面留言，我一定会与您讨论与分享。上一期我们主要在介绍hash相关的切分方式，那么这次我们来看一下有序结构的切分 有序结构的拆分，目

http://rdc.taobao.com/team/jm/archives/1387首先来回答一个问题：为什么在磁盘中要使用b+树来进行文件存储呢？原因还是因为树的高度低得缘故，磁盘本身是一个顺序读写快，随机读写慢的系统，那么如果想高效的从磁盘中找到数据，势必需要满足一个最重要的条件：减少寻道次数。我们以平衡树为例进行对比，就会发现问题所在了：先上个图

这一次，我们来讲讲数据安全和读写高可用oh no,亲，于是我们又掉入了CAP所描述的陷阱。好吧，那么我们也就进入这个领域，来看看这数据安全所代表的一切。在20年以前，数据安全对于大部分用户来说，只意味着数据库ACID中的”D”，数据写入到数据库，并返回成功后，这个数据也就是安全的了，在老师教给我们的计算机原理课上，似乎最多也就讲到，数据库有冷备份，也有热备份，因此写入数据库

作者: Aliaksei Papou  来源: InfoQ  发布时间: 2013-06-14 14:30  阅读: 1471 次  推荐: 4   原文链接   [收藏]  　　英文原文：How Would You Build Up a City from Components?　　为什么越来越多的企业应用开发正在转向组件框架和解决方案？组件架构是否有前途？我相信答案是肯定的

前面的话：提到依赖注入，大家都会想到老马那篇经典的文章。其实，本文就是相当于对那篇文章的解读。所以，如果您对原文已经有了非常深刻的理解，完全不需要再看此文；但是，如果您和笔者一样，以前曾经看过，似乎看懂了，但似乎又没抓到什么要领，不妨看看笔者这个解读，也许对您理解原文有一定帮助。1.依赖在哪里   老马举了一个小例子，是开发一个电影列举器（MovieList），这个电影列举器需要使用一

来源: itivy  发布时间: 2011-05-02 20:21     原文链接  　　之前我简单向大家介绍了各个知名大型网站的架构，MySpace的五个里程碑、Flickr的架构、YouTube的架构、PlentyOfFish的架构、WikiPedia的架构。这几个都很典型，我们可以从中获取很多有关网站架构方面的知识，看了之后你会发现你原来的想法很可能是狭隘的。　　今天我

TairTFS的开发，让淘宝的图片功能得到了充分的发挥。同TFS一样，很多技术都是在产品的推动下得到发展的。在讲下面的技术之前，有必要说说那些年，我们一起做过的几个产品。先说个比较悲剧的——【团购】，这个团购可不是现在满大街挂的那种groupon类型的模式，在groupon出生之前，在2006年，淘宝的产品经理一灯就提出了“团购”这种产品。一灯最初的设想是让买家在社区发起团购，“团

摘要：Google、Amazon和Facebook等7家知名互联网都会针对不同使用场景做合适的设计，但总有一些万变不离其宗的思想。比如保持简单、让所有事情自动化、不断迭代、使用缓存、根据场景在数据一致性和可用性间取舍。本文出自澳大利亚一位ID为Dodgy Coder的程序员2012年4月的博客文章。他从High Scalability上整理和总结了Google、YouTube、Twit

实现伸缩性和性能调优的经验所保有的价值容易被低估。两者都是“晚些时候”或“我们真正流行起来时”所面临的难题。早期创业公司确实不应该立即花这份钱，而大公司通常不能做出足够快速的反应以实现所需的改变。再加上这需要一个多学科的团队，它立刻就变成了一个需要解决的政治上和工程上的难题。但是它从来不会从我们的视线中消失——在过去的少数几个Qcon会议上，“Architectures You"ve Al

简介浏览器可以被认为是使用最广泛的软件，本文将介绍浏览器的工 作原理，我们将看到，从你在地址栏输入google.com到你看到google主页过程中都发生了什么。将讨论的浏览器今天，有五种主流浏览器——IE、Firefox、Safari、Chrome及Opera。本文将基于一些开源浏览器的例子——Firefox、 Chrome及Safari，Safari是部分开源的。根据W3C

从最简单的水平来看，可伸缩性就是做更多的事情。更多的事情可以是响应更多的用户请求，执行更多的工作，或处理更多的数据。设计软件这件事本身是复杂的，而让软件做更多的工作也有其特有的问题。这篇文章针对构建可伸缩软件系统提出了一些原则和方针。1. 减少处理时间增加应用所做工作数量的一个方法就是减少完成单项工作所花费的时间。举例来说，减少处理一个用户请求所需的时间意味着你能在同样长的时间内处

引言在扩展大量大型的分布式系统期间，我有机会观察（并实践）了一些最差实践。这些最差实践中的大部分在开始时都没有危害，但如果疏忽大意，它们就会对系统的发展和可伸缩性构成危害。很多文章都聚焦于最佳实践，以确保拥有一个易于维护和可伸缩的系统，但在本文中，我主要强调的则是一些应该规避的最差实践。技术没有任何一种技术或架构能实现所有的需求。了解何时该反思现有的方法、如何拓宽视野以超越

记得以前给大家介绍过视频网站龙头老大YouTube的技术架构，相信大家看了都会有不少的感触，互联网就是这么一个神奇的东西。今天我突然想到，优酷网在国内也算是视频网站的老大了，不知道他的架构相对于YouTube是怎么样的，于是带着这个好奇心去网上找了优酷网架构的各方面资料，虽然谈得没有YouTube那么详细，但多少还是挖掘了一点，现在总结一下，希望对喜欢架构的朋友有所帮助。一、网站基本数据概

搜索引擎最重要的是什么？有人会说是查询结果的准确性，有人会说是查询结果的丰富性，但其实这些都不是搜索引擎最最致命的地方。对于搜索引擎来说，最最致命的是查询时间。试想一下，如果你在百度界面上查询一个关键词，结果需要5分钟才能将你的查询结果反馈给你，那结果必然是你很快的舍弃掉百度。搜索引擎为了满足对速度苛刻的要求（现在商业的搜索引擎的查询时间单位都是微秒数量级的），所以采用缓存支持查询需求的方

在世界范围构建可靠的分布式系统往往要求在一致性和可用性之间进行权衡。上个月，亚马逊公司的CTO Werner Vogels发表了一篇文章，描述在大型分布式系统中容忍最终数据一致性的方法。正如InfoQ之前的一篇文章《牺牲一致性来换取分布式架构的可伸缩性》里所讨论的：系统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。亚马逊公司

切分是最基本，且最多变的思路之一，说基本，是因为在学习程序设计的第一天就应该知道，说多变，是因为在未来的很多年里，你会不停的应用这个方法来解决问题。不幸的是，切分这个思路并没有得到应有的重视。大概是因为这个词比较土，说起来也比较普通，远不如并行，集群，负载平衡这些词听起来大。所以碰到一个问题的时候，往往被拿出来的解决方案会是以上3个大词之一，很少有人去认真的考虑切分问题。但事实上，这3个大

这几天一直在关注和学习一些大型网站的架构，希望有一天自己也能设计一个高并发、高容错的系统并能应用在实践上。今天在网上找架构相关的资料时，看到一个被和谐的视频网站YouTube的架构分析，看了以后觉得自己又向架构走近了一步，于是赶快拿出来与大家一起分享。YouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。这点和PlentyOfFish类似，少数人维护庞大系统

Wille Faler 提出了八项提升系统可伸缩性和性能的最佳实践，其中包括减少数据库操作、使用缓存、减少网络通信等实践。1. 减少数据库操作 － 尽可能远离数据库。如无必要，就不要打开数据库连接或者启动事务。2. 缓存带来的显著变化 － 缓存能极大地减低数据库的负担，特别是当系统通过只读方式访问数据库的时候。内存缓存优于磁盘缓存，而磁盘缓存又优于远程缓存和关系型数据库。3

作为140个字的缔造者，twitter太简单了，又太复杂了，简单是因为仅仅用140个字居然使有几次世界性事件的传播速度超过任何媒体，复杂是因为要为2亿用户提供这看似简单的140个字的服务，这真的是因为简单，所以复杂。今天就结合网络上的一些资料，来浅谈一下我对twitter网站架构的学习体会，希望给路过的朋友一点启示.......一、twitter网站基本情况概览截至2011年4月，

本系列文章基于公开资料对Google App Engine的实现机制这个话题进行深度探讨。在切入Google App Engine之前，首先会对Google的核心技术和其整体架构进行分析，以帮助大家之后更好地理解Google App Engine的实现。本篇将主要介绍Google的十个核心技术，而且可以分为四大类：分布式基础设施：GFS、Chubby 和 Protocol Bu

统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂，越来越多关于如何构建应用的传统智慧正在受到挑战。比如说，去年3月在伦敦召开的QCon会议上，Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道，其中一个主要的结论就是eBay不使用事务，用数据一致性上的损失来换取系统整体伸缩性和性能上相当大的

在JavaOne 2008的会议上，著名社交网站LinkedIn的开发者做了2个关于LinkedIn网站的架构技术的演讲可以看一下LinkedIn网站的基本情况：1. 2千2百万用户2. 每个月4百万独立用户访问3. 每天4千万Page View4. 每天2百万搜索流量5. 每天25万邀请发送6. 每天1百万的回答提交7. 每天2百万的Email消息

负载均衡这里把多台nginx反向代理服务器顶在最前面，可以通过DNS简单轮循或绑定虚拟IP的方法来实现分流。之所以用nginx是因为它的稳定、强大、高性能、低开销、以及对高并发的支持。也可以换成LVS，从效率上来说肯定会比nginx高，因为工作在OSI的第四层(传输层)，可以修改目标IP。甚至可以在第二层(数据链路层)修改MAC地址(DR模式，相当于路由器)，让数据包直接到达目标服务器。不

引言近段时间以来，通过接触有关海量数据处理和搜索引擎的诸多技术，常常见识到不少精妙绝伦的架构图。除了每每感叹于每幅图表面上的绘制的精细之外，更为架构图背后所隐藏的设计思想所叹服。个人这两天一直在搜集各大型网站的架构设计图，一为了一饱眼福，领略各类大型网站架构设计的精彩之外，二来也可供闲时反复琢磨体会，何乐而不为呢?特此，总结整理了诸如国外wikipedia，Facebook，Yahoo！，

本文根据系统管理领域知名博客 Thomas A. Limoncelli 的 What is system administration like at Google 整理而成，添加了部分笔者观点。Google的系统工程师(System Administrator)如何工作由于Google的服务已经集群化，系统工程师并不大量接触硬件比如做安装服务器等事情。另外大部分工作也已经自动