今天我们来谈谈一个网站一般是如何一步步来构建起系统架构的，虽然我们希望网站一开始就能有一个很好的架构，但马克思告诉我们事物是在发展中不断前进的，网站架构也是随着业务的扩大、用户的需求不断完善的，下面是一个网站架构逐步发展的基本过程，读完后，请思考，你现在在哪个阶段。
这几天一直在关注和学习一些大型网站的架构，希望有一天自己也能设计一个高并发、高容错的系统并能应用在实践上。今天在网上找架构相关的资料时，看到一个被和谐的视频网站YouTube的架构分析，看了以后觉得自己又向架构走近了一步，于是赶快拿出来与大家一起分享。 YouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。这点和PlentyOfFish类似，少数人维护庞大系统
近段时间以来，通过接触有关海量数据处理和搜索引擎的诸多技术，常常见识到不少精妙绝伦的架构图。除了每每感叹于每幅图表面上的绘制的精细之外，更为架构图背后所隐藏的设计思想所叹服。个人这两天一直在搜集各大型网站的架构设计图，一为了一饱眼福，领略各类大型网站架构设计的精彩之外，二来也可供闲时反复琢磨体会，何乐而不为呢?特此，总结整理了诸如国外wikipedia，Facebook，Yahoo！，
负载均衡 这里把多台nginx反向代理服务器顶在最前面，可以通过DNS简单轮循或绑定虚拟IP的方法来实现分流。之所以用nginx是因为它的稳定、强大、高性能、低开销、以及对高并发的支持。也可以换成LVS，从效率上来说肯定会比nginx高，因为工作在OSI的第四层(传输层)，可以修改目标IP。甚至可以在第二层(数据链路层)修改MAC地址(DR模式，相当于路由器)，让数据包直接到达目标服务器。不
新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第
摘要：将应用交付给终端用户正变得越来越难，因为会涉及到更多的组件，也因此更容易犯错。技术性能公司Compuware总结了贯穿应用始终的八大影响应用性能的陷阱，望开发者引以为戒。 数据库访问低效、框架配置错误、内存使用过度、网页臃肿，以及不遵循常见Web性能最佳实践都是应用开发中常见的、影响应用性能的主要陷阱 。技术性能公司Computeware从实际案例总结了贯穿应用始终的八大影响应用性
简介 浏览器可以被认为是使用最广泛的软件，本文将介绍浏览器的工 作原理，我们将看到，从你在地址栏输入google.com到你看到google主页过程中都发生了什么。 将讨论的浏览器 今天，有五种主流浏览器——IE、Firefox、Safari、Chrome及Opera。 本文将基于一些开源浏览器的例子——Firefox、 Chrome及Safari，Safari是部分开源的。 根据W3C
首先来回答一个问题：为什么在磁盘中要使用b+树来进行文件存储呢？ 原因还是因为树的高度低得缘故，磁盘本身是一个顺序读写快，随机读写慢的系统，那么如果想高效的从磁盘中找到数据，势必需要满足一个最重要的条件：减少寻道次数。
Wille Faler 提出了八项提升系统可伸缩性和性能的最佳实践，其中包括减少数据库操作、使用缓存、减少网络通信等实践。 1. 减少数据库操作 － 尽可能远离数据库。如无必要，就不要打开数据库连接或者启动事务。 2. 缓存带来的显著变化 － 缓存能极大地减低数据库的负担，特别是当系统通过只读方式访问数据库的时候。内存缓存优于磁盘缓存，而磁盘缓存又优于远程缓存和关系型数据库。
1、软件长期运营存在什么问题 一个大规模的客户端软件的生命周期中，我们可以把它分为两个比较粗的时期。一个是前期的搭建软件的时期，即从无到有的时期；第二个是搭建完成之后，进入的一个稳定的运营时期。第二个时期才是最关键的，在这个时期我们会持续的迭
作为140个字的缔造者，twitter太简单了，又太复杂了，简单是因为仅仅用140个字居然使有几次世界性事件的传播速度超过任何媒体，复杂是因为要为2亿用户提供这看似简单的140个字的服务，这真的是因为简单，所以复杂。今天就结合网络上的一些资料，来浅谈一下我对twitter网站架构的学习体会，希望给路过的朋友一点启示.......
