虽然常在网上游荡，可以对它内部却了解甚少。不就是个网站嘛，我也能做！直到到了淘宝，我才发现是网站流量上了数量级以后，就不再就是个网站这样简单了。

网站整体运营的规划，如何在特定的环境下生存下去，把握行业的动态，如何更好的留住用户，网站慢于500 ms以上就等于 20% 将放弃访问，这并不是危言耸听。

如果要在互联网行业生存下去，就必须要快速的相应用户的需求，以迅雷不及掩耳的速度将用户最想要的放到用户的面前。

         这就给构架一个高可用的web站点制造了很多难题。CDN，分布式缓存，分布式文件系统，远程调用，负载均衡，集群技术，配置中心，数据库的分表分库。

                                               图一：互联网架构

很多静态的文件是不用通过服务器处理就可以直接展现的用户面前的，如图片文件，css，js，静态html，并且如果用户每次请求这些内容都到服务器获取，这将给服务器带来很大的压力。这时候我们就这些内容放在最接近用户网络边缘，也就是CDN节点,采用CDN技术，能处理整个网站页面的70%～95％的内容访问量。

随着用户的增加，访问页面数上亿级，每天千万级的时候，一个APP服务器，肯定是不够的，上千台同时协助是必须的，如何管理好这些猛兽，也是一个问题。负载均衡集群就可以将用户的请求分发到后台的各个APP服务器中。而APP之间的session共享又是一个难题，常见的做法是单点登录，无Session架构。

大量的动态页面里面充斥着相对比较静态的一些内容，如主页面估计只会一天动态生成一次，我们这时候可以采用页面片段缓存技术，将其缓存在服务器中到失效。

各个APP当中会有一些相同的逻辑，如用户管理的逻辑，邮件发送。APP服务器和逻辑服务器分离是必要的。系统的拆分有很多策略，着重要注意系统的依赖和业务的整理。该部就要涉及到APP和后台服务器集群的通信了，一个高性能的RPC是必须的（同步和异步的）。目前比较成熟的有ICE，Jboss Remoting。调用后台如果有多台服务器的话，这样难度就大了。

我们要时刻注意到服务器时刻会挂掉的，容错是必要的。有一个中枢配置中心是必要的。

通常用一个key-value系统来做，目前linkedin有一款叫Voldemort开源产品可以实现该功能

数据的持久化是一个系统必须的，加上面对互联网的将是海量数据，由此就产生了具有互联网特色的持久层架构的诞生了，根据CAP原则，为了好的响应性能，可靠性，尽量放弃了一些一致性的东西，而只是做到最后一致。相对于传统的关系数据库，互联网的数据可以更形象的表示为key-value的形式，而大量的文件是不能再存储在一个服务器里面，这时候一个分布式的文件系统就是必须的了。数据库系统则要分表分库处理。