May
19
相信很多IT人士都有过搭建自己主页的经验，10多年前的个人主页都非常简单，很多由Frontpage构建，多属于静态HTML页面，最多加一点 特效而已。不过10年间，技术的进步是惊人的。现在，一个网站绝不可能仅仅由几个HTML页面构成。我们随便举一个例子，国内图片网站 yupoo.com，在 chinarank排名1000左右，而Alexa排名则为5000左右，这个网站不算大，就是这样一个中型站点，拥有超过60台服务器，架构中涉及的 Web服务器就包括了Lighttpd、Apache和 nginx。Yupoo的流量不算大，就已经拥有了60台服务器，事实上，排名前几位的网站，都拥有成千上万台服务器，如何协调这些服务器之间的工作负 载，如何统一指挥调度，如何维护这些服务器硬件都是棘手的挑战。
负载均衡：
负载均衡是所有大中型网站必备的部署。显然，大型网站每天上千万独立IP的访问量，一个Web服务器根本承担不了，网站后台必需有多台服务器共同工 作，因此各种负载均衡技术就应运而生了。
较早的负载均衡是DNS负载均衡。原理很简单，只要在域名解析的时候，将多个地址配置成同一个域名，负载均衡就完成了。不同用户点击同一个域名的时 候，实际上只解析给用户一个地址，这样用户实际上访问的是不同的Web服务器，就减轻了每个服务器的负担。这个DNS负载均衡方法，一般而言是随机抽取地 址。DNS负载均衡早期被广泛使用，优点是简单易用，但是DNS负载均衡还是有一些问题存在。如果某一台服务器发生了故障，而DNS的下一个刷新周期又没 到，这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强，比如一段时间内众多访问都被指向同一个地址，而另外的地 址却闲置，就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态，DNS负载均衡也无从得知，而依旧平均的解析域名。
稍微复杂一点的负载均衡，是反向代理，当外部有请求到代理服务器，代理服务器再将该请求均匀的转发到内网的服务器上。这种方式被广泛采用，比如说上 面提到的又拍网yupoo.com，就采用了nginx作为反向代理。此外，现在还可以购买专业的硬件设备，比如 Plentyoffish.com(全球最大的婚介网站)就采用了网捷网络公司的Web交换器ServerIron作为硬件负载均 衡，ServerIron 能够有效地处理 16，000，000个并发连接，并且可以改善服务器负载均衡和缓冲转换，像ServerIron这类的硬件产品并非只有网捷一家提供，由于大型网站预算 充裕，因此也可以选择一些其他的硬件设备来做负载均衡。当然了，我们也别忽略了最基本的软件负载均衡——Windows Server就带有这样的功能。
负载均衡还有一个极为简单的方法，就是建立镜像站点。比如华军软件或者天空软件，都直接采用了镜像站点。这个方式很直接，省去了很多麻烦。以华军软 件园为例，登陆华军软件园的时候，我们将有多种选择，可选电信、网通等网络；而下载某一软件的时候，为了使用户得到更快的速度，天空和华军在中国各地都安 排了服务器，可以提供距离最近的下载服务。不过，也有一些麻烦，就是每一次选择都是人工手动选择。总之，这一系列负载均衡方法，都得以让大型网站的负载均 匀，不会有哪个服务器有太大的压力。
CDN：
CDN( Content Delivery Network)，内容分发网络也是大型网站必备的部署之一。CDN的原理不难理解，就是将网页内容存放到离用户更近的缓存服务器上，减少路由，从而加快 远距离的访问速度。比如说，你随意登陆一个国外小站，速度可能很慢。因为国外网站到国内的最终客户端的路径冗长，但是如果你登陆部署了CDN的网站，比如 Plentyoffish.com，你会发现速度非常快，跟国内的网站访问速度差异已经无法从感知上判断。依照Cache存放的位置不同，CDN也有一些 类别，不同的网站会根据具体需求，有不同的选择。CDN通常是由独立的CDN商提供的。举一个例子，就是网易，我的查询时间是2008年2月28日，我们 发现，同一个域名下的有很多个IP地址，这就说明了首页CDN的部署。
C:>nslookup www.163.com
Server: ns.lnpta.net.cn
Address: 202.96.64.68
Non-authoritative answer:
Name: www.cache.split.netease.com
Addresses: 202.108.9.37, 202.108.9.38, 202.108.9.39, 202.108.9.51
202.108.9.52, 202.108.9.31, 202.108.9.32, 202.108.9.33, 202.108.9.34
202.108.9.36
Aliases: www.163.com
而我们如果查询一个简单的个人网站，则不可能有CDN；另外，如果有兴趣，我们也可以仔细察看一个网站多个二级域名的CDN情况。
平台设计：
大型网站一般都有着非常复杂的与用户交互的内容，必须大量调用数据库，因此一个完善的数据库设计对于大型网站非常重要。例如上面提到的 Plentyoffish.com，这个站其实是个人网站，但流量大的惊人，该网站有一个主要的数据库，两个搜索数据库，早些时 候，plentyoffish.com的数据库设计问题频频，经常到数据库堵塞，所以站长花费时间最多的地方就是数据库优化。数据库优化没有什么特别的捷 径，其实很少有一次成型的完美数据库构建，只能是按照特定的需要来设计数据库，如有不足再去着手改进。不过大型网站还是有一些共性，比如说图片存储单独使 用图片数据库，尽量使用静态页面来减少数据库调用等等。
还有很多大型网站，都有着非常深厚的技术实力，可以开发属于自己的平台。比如说谷歌，Google.com就有着自己独特的平台，主要包括 GFS、MapReduce和 BigTable。因为海量数据存储，所以常规的数据库调用查询是非常恐怖的，每次查询都将调用百亿个页面，成千上万个并发检索足以使得谷歌系统崩溃，因 此Google File System将大量页面以独特的方法压缩之后再提供检索；整个系统一共包括超过两百个集群，再由MapReduce来协同作业。不仅仅谷歌，比如百度、中 搜等等网站也都有自己研发的独特的平台。
硬件配置：
大型网站的硬件配置一定就好吗？答案是否定的。比如说全球最大的网站谷歌，google.com的整个架构的基础是几十万台普通的PC级别服务器。 谷歌一些服务器的细节为商业机密，但是根据谷歌已经披露的资料显示，在2006年之前谷歌拥有45万台服务器，这些服务器都是非常普通的PC级服务器，甚 至硬盘接口都还是有些过时的IDE接口。这也是谷歌的独特架构决定的，而对比谷歌，维基百科则拥有非常强势的服务器，全部为SCSI硬盘，而且主要的主机 中都有多达6块硬盘，超过16GB内存。这比较容易理解，因为谷歌在全球拥有很多个数据中心，员工数量众多，完全有能力管理数以万计服务器的运行，而维基 百科则为非营利机构，主要依靠捐赠生存，员工数量非常稀少，因此必须配备强势的服务器。其实，每个网站都应该根据自己独特的情况来配置硬件，目前 1TB SATA硬盘已经步入了量产阶段，可是2年以前1TB的硬盘只能通过RAID 0来实现，可见硬件的更新速度非常惊人，所以即便预算充裕，在配置服务器的时候也应该多考虑实际用途，而不一定要拥有最好的配置。
总结：
以上只是大型网站的概括总结，其实每个网站都有自己独特的一面，所以以上的每一条规则都未必是死规定。比如说着重沟通的Twitter.com，本 质就是一个异步聊天室，因此静态页面就不见的有必要。总之，网站架构没有死定律，只要合适网站的，就是好的架构。
负载均衡：
负载均衡是所有大中型网站必备的部署。显然，大型网站每天上千万独立IP的访问量，一个Web服务器根本承担不了，网站后台必需有多台服务器共同工 作，因此各种负载均衡技术就应运而生了。
较早的负载均衡是DNS负载均衡。原理很简单，只要在域名解析的时候，将多个地址配置成同一个域名，负载均衡就完成了。不同用户点击同一个域名的时 候，实际上只解析给用户一个地址，这样用户实际上访问的是不同的Web服务器，就减轻了每个服务器的负担。这个DNS负载均衡方法，一般而言是随机抽取地 址。DNS负载均衡早期被广泛使用，优点是简单易用，但是DNS负载均衡还是有一些问题存在。如果某一台服务器发生了故障，而DNS的下一个刷新周期又没 到，这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强，比如一段时间内众多访问都被指向同一个地址，而另外的地 址却闲置，就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态，DNS负载均衡也无从得知，而依旧平均的解析域名。
稍微复杂一点的负载均衡，是反向代理，当外部有请求到代理服务器，代理服务器再将该请求均匀的转发到内网的服务器上。这种方式被广泛采用，比如说上 面提到的又拍网yupoo.com，就采用了nginx作为反向代理。此外，现在还可以购买专业的硬件设备，比如 Plentyoffish.com(全球最大的婚介网站)就采用了网捷网络公司的Web交换器ServerIron作为硬件负载均 衡，ServerIron 能够有效地处理 16，000，000个并发连接，并且可以改善服务器负载均衡和缓冲转换，像ServerIron这类的硬件产品并非只有网捷一家提供，由于大型网站预算 充裕，因此也可以选择一些其他的硬件设备来做负载均衡。当然了，我们也别忽略了最基本的软件负载均衡——Windows Server就带有这样的功能。
负载均衡还有一个极为简单的方法，就是建立镜像站点。比如华军软件或者天空软件，都直接采用了镜像站点。这个方式很直接，省去了很多麻烦。以华军软 件园为例，登陆华军软件园的时候，我们将有多种选择，可选电信、网通等网络；而下载某一软件的时候，为了使用户得到更快的速度，天空和华军在中国各地都安 排了服务器，可以提供距离最近的下载服务。不过，也有一些麻烦，就是每一次选择都是人工手动选择。总之，这一系列负载均衡方法，都得以让大型网站的负载均 匀，不会有哪个服务器有太大的压力。
CDN：
CDN( Content Delivery Network)，内容分发网络也是大型网站必备的部署之一。CDN的原理不难理解，就是将网页内容存放到离用户更近的缓存服务器上，减少路由，从而加快 远距离的访问速度。比如说，你随意登陆一个国外小站，速度可能很慢。因为国外网站到国内的最终客户端的路径冗长，但是如果你登陆部署了CDN的网站，比如 Plentyoffish.com，你会发现速度非常快，跟国内的网站访问速度差异已经无法从感知上判断。依照Cache存放的位置不同，CDN也有一些 类别，不同的网站会根据具体需求，有不同的选择。CDN通常是由独立的CDN商提供的。举一个例子，就是网易，我的查询时间是2008年2月28日，我们 发现，同一个域名下的有很多个IP地址，这就说明了首页CDN的部署。
C:>nslookup www.163.com
Server: ns.lnpta.net.cn
Address: 202.96.64.68
Non-authoritative answer:
Name: www.cache.split.netease.com
Addresses: 202.108.9.37, 202.108.9.38, 202.108.9.39, 202.108.9.51
202.108.9.52, 202.108.9.31, 202.108.9.32, 202.108.9.33, 202.108.9.34
202.108.9.36
Aliases: www.163.com
而我们如果查询一个简单的个人网站，则不可能有CDN；另外，如果有兴趣，我们也可以仔细察看一个网站多个二级域名的CDN情况。
平台设计：
大型网站一般都有着非常复杂的与用户交互的内容，必须大量调用数据库，因此一个完善的数据库设计对于大型网站非常重要。例如上面提到的 Plentyoffish.com，这个站其实是个人网站，但流量大的惊人，该网站有一个主要的数据库，两个搜索数据库，早些时 候，plentyoffish.com的数据库设计问题频频，经常到数据库堵塞，所以站长花费时间最多的地方就是数据库优化。数据库优化没有什么特别的捷 径，其实很少有一次成型的完美数据库构建，只能是按照特定的需要来设计数据库，如有不足再去着手改进。不过大型网站还是有一些共性，比如说图片存储单独使 用图片数据库，尽量使用静态页面来减少数据库调用等等。
还有很多大型网站，都有着非常深厚的技术实力，可以开发属于自己的平台。比如说谷歌，Google.com就有着自己独特的平台，主要包括 GFS、MapReduce和 BigTable。因为海量数据存储，所以常规的数据库调用查询是非常恐怖的，每次查询都将调用百亿个页面，成千上万个并发检索足以使得谷歌系统崩溃，因 此Google File System将大量页面以独特的方法压缩之后再提供检索；整个系统一共包括超过两百个集群，再由MapReduce来协同作业。不仅仅谷歌，比如百度、中 搜等等网站也都有自己研发的独特的平台。
硬件配置：
大型网站的硬件配置一定就好吗？答案是否定的。比如说全球最大的网站谷歌，google.com的整个架构的基础是几十万台普通的PC级别服务器。 谷歌一些服务器的细节为商业机密，但是根据谷歌已经披露的资料显示，在2006年之前谷歌拥有45万台服务器，这些服务器都是非常普通的PC级服务器，甚 至硬盘接口都还是有些过时的IDE接口。这也是谷歌的独特架构决定的，而对比谷歌，维基百科则拥有非常强势的服务器，全部为SCSI硬盘，而且主要的主机 中都有多达6块硬盘，超过16GB内存。这比较容易理解，因为谷歌在全球拥有很多个数据中心，员工数量众多，完全有能力管理数以万计服务器的运行，而维基 百科则为非营利机构，主要依靠捐赠生存，员工数量非常稀少，因此必须配备强势的服务器。其实，每个网站都应该根据自己独特的情况来配置硬件，目前 1TB SATA硬盘已经步入了量产阶段，可是2年以前1TB的硬盘只能通过RAID 0来实现，可见硬件的更新速度非常惊人，所以即便预算充裕，在配置服务器的时候也应该多考虑实际用途，而不一定要拥有最好的配置。
总结：
以上只是大型网站的概括总结，其实每个网站都有自己独特的一面，所以以上的每一条规则都未必是死规定。比如说着重沟通的Twitter.com，本 质就是一个异步聊天室，因此静态页面就不见的有必要。总之，网站架构没有死定律，只要合适网站的，就是好的架构。
May
19
跟朋友聊天的时候，发现很多人对大型网站系统架构非常感兴趣，我也很感兴趣，经常会在家里2台笔记本和1台服务器组成的局域网环境里作些实验。我进 入IT行业的时间，大约是97，98年吧，那时候PC客户端软件最为盛行，做软件开发是一份很体面也很喜欢的工作。我从Win3.1上的VC1.5开始一 直到VC6.0，然后转为.Net开发，基本上都是从事客户端软件开发。本人的性格是危机意识向来严重，所以深感互联网必将盛行，传统软件必将走向没落， 于是转向了WEB开发。记得以前去某Portal网站应聘的时候，主考官就问我：你认为客户端开发和互联网开发有什么不同。我当时的回答是：互联网开发比 客户端软件开发简单多了，我再也不用考虑那么多的用户环境因素了，一点部署，何时何地都可用。
很多年过去了，我再想起当初我的回答，依然觉得那个回答是正确的。就产品开发层面来讲，互联网开发确实简单多了。这里首先澄清一个概念，我所说的互 联网开发并不是指所有的B/S应用，例如B/S方式的银行内部业务系统。我所说的互联网应用是指在互联网上服务于公众的应用。企业级的业务系统，它的特点 是业务逻辑是比较复杂的，但用户一般不太大；互联网应用则相反，业务逻辑一般很简单，但面对的是海量用户。
既然互联网应用开发的业务逻辑不复杂，但为什么大型网站都投入了那么多的技术人员呢？主要是因为运营的环境太复杂，这种复杂性形成的原因以下：
1、公开性
网站的服务是公开的，任何人都可以来访问，所以就会直接面对大量的不良用户，系统数据的安全面临很大的风险，一旦系统被攻入，结果将是灾难性的。
2、访问量大
访问量大，就意味着网站必须能够承受高并发大流量的考验，如果网站的服务能力和健壮性等达不到要求，你的系统就会被冲垮。
3、用户体验
用户体验要好，除了产品设计的因素之外，就要求访问网站的速度要快，具有高可用性，别用一会就挂。
网站各子系统如何进行部署，如何提高系统的健壮性和高可用性，如何实现网站的安全，如何提高访问速度，如何进行负载均衡，甚至于采用什么的硬件设 备，另外，网站发展的不同时期会可能会采用不同的架构，如何实现架构的平滑过渡，如何使目前的架构具有弹性，具备可扩展的能力，这都是大型网站必须解决的 问题，也是小网站成长过程中迟早会遇到的问题。我后面的文章将会逐步就这个话题展开。
网站机构包括网站的软件架构和系统架构两部分，软件架构主要是指子系统和逻辑层的划分结构；系统架构，一般是系统部署结构。
系统架构师的知识体系比较庞杂，所谓的见多识广，多数是由运维工程师成长起来的，他们开发能力不强，编码不多，但动手能力很强，脚本编写非常熟练， 经常会做各种类型的实验，密切跟踪最新技术最新产品的相关信息。当然，一个大型的网站，需要一个架构师团队，他们各自承担擅长领域的架构设计，比如安全架 构、存储架构等等。
我觉得一般的开发人员还是很难走上这条路的，这份工作需要经验，需要不断实践，但如果开发人员一旦走上了这条路，会有很大的发展，主要源于开发人员 的思考习惯和技术的深度。我的这系列文章，开发人员可以作为参考，比如如何开发可分布式部署的系统，另外很多朋友都是身兼数职，从开发到实施，到部署全部 包办。我个人深感精力有限，所以又特意找了几个朋友从Unix/Linux系统和Windows系统不同角度进行探索，以造福正在摸索中的朋友，有兴趣的 朋友也可以参与。
其实，这部分内容我一直在写，比如PHP深度探索系列，写了大量的关于apache的内容，我已经大体把apache代码阅读了一遍，很费时间，进 度缓慢，但我想这有助于我们理解apache的配置和调优。
在介绍网站架构之前，我们先介绍一些网站架构中最基础和常见的概念，以便更好的理解后面的有关负载均衡和分布式存储等技术。第一个，首先讲讲 CDN。
1、CDN是什么
CDN（Content Delivery Network），就是内容发布网或者内容分发网，它的主要目的：通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的 网络边缘，使用户可以就近取得所需的内容，从而提高用户访问网站的响应速度，提升用户体验，同时能够分散访问压力，把本来用户集中访问分散到各地去。网站 的内容提供商（比如新浪、搜狐、网易等等）使用CDN，就可以在宏观层解决一部分大流量、海量用户并发等令人头疼的问题。
2、CDN的组成
内容发布网(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理４个要件，而内容管理和全局的网络流量 管理是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务，达到用户所要求的服务距用户仅 有”一跳”(Single Hop)之遥。
我们通常的内容发布模式都是将网站数据放到一处，然后应对来自世界各地的访问，我们多数考虑的是软件部署架构，很少考虑网络硬件架构。与之形成对比 的是，CDN则强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。
内容提供商承担了他们不该干也干不好的内容发布服务。
3、互联网服务的产业链
纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革， 在这条价值链上的角色越来越多也越来越细分，出现了内容运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色 都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和 IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占 用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的 选择，这就是CDN服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择，无疑对于构建良好的互联网价值链是有价值的，也是不可或 缺的最优网站加速服务。
4、CDN服务提供商
ChinaCache是中国最大的CDN服务提供商，是不是唯一未可知也。要想成为CDN服务提供商，恐怕要摆平电信、网通、铁通等等运营商，这得 需要什么样的能力和背景不得而知。它的服务节点在全球已经超过130个，其中国内节点超过80个，覆盖全国主要6大网络（所谓6线机房，就是这么来的）的 主要省份，象各大门户网站，比如新浪、网易等等都是租用了他们的服务。所以，你无论是在南方，或者北方，还是在北美，访问这些门户网站，感觉速度都很快， 最主要的原因之一就是CDN发挥了效果。一般小网站是用不起这服务的，所以慢点就慢点了吧，可以租用互联互通的6线机房，如果网络足够宽的话，用户也可以 忍受。如果想继续提升用户体验的话，就需要做一些网站镜像，部署在具有代表性的几个大城市，比如华南可以部署在广州，华东可以部署在上海，华北可以部署在 北京，不过内容镜像的过程，就需要自己去部署和维护。还有的网站，采用内容分割的方式，比如建立针对各地的分站，业务情况不同，可能部署的策略不同。 CDN可以认为是基础网络建设的一种策略。
前面介绍了cdn的一些原理和概念，以及提供cdn基础网络服务的途径。cdn看起来对于静态内容的，比如html,js,image是非常合适 的，通过cdn的部署，用户只需要一跳就可以访问到网站的内容。那对于动态内容怎么办呢？我回答一下：
动态内容按照存在形态可以分为三类。
第一类：内容长时间不需变化，这类内容一般是通过网页静化技术，实现动态内容转换成静态内容，从而达到cdn部署，典型的就是内容类网站，比如新 浪、搜狐、网易等等的内容发布系统cms，内容的增删改等管理工作被准实时同步到各个节点。
第二类：内容可能会短时间内发生变动，但是最终会稳定。比如论坛、博客等应用，这类服务提供的内容按照一定的时间间隔，实现批量静化，当然也有实时 静化，像Mop的大杂烩、网易社区就是使用了这样的策略。
第三类：内容会实时变化，非常个性化。比如邮箱应用，这类服务提供的内容无法实现静化，只能通过实行分区域部署和负载均衡等手段进行优化。
对于提供cdn服务的厂商来讲，静态内容的cdn自然没有问题，对于第三类服务，只能从通信链路层进行相应的优化。
对于很多网站的伪静化，有的出于Seo的考虑，有的出于安全性的考虑，手段基本上是rewrite Url。它只不过是一种外在的表现形式，与Html静化是两回事，它依然是一种动态内容。
1. 负载均衡的分类
负载均衡技术在网站运营过程中应用非常普遍，技术也很成熟。负载均衡技术按照软硬件形式分为软均衡和硬均衡。软均衡就是基于软件技术的均衡，硬均衡 是基于硬件技术的均衡；
按照网络协议划分又分为四层均衡和七层均衡。四层均衡就是基于OSI网络层的数据均衡，七层均衡是基于OSI应用层的数据均衡。
各种均衡方式在大型网站中均有采用，而且大多数情况下，是多种均衡方式的组合。
2. DNS轮询均衡
这种方式，算是比较独立的一种方式，不在上述划分之列，但使用比较广泛，一般用在网站最前端。你可以做个试验，在dos命令行中运行nslook命 令。比如：nslookup www.163.com，你会看到命令给出了一堆解析后的IP地址。这些地址就是www.163.com这个域名绑定的多条A记录。我们从浏览器发起的访 问请求http://www.163.com/，那么你输入的域名首先需要经过DNS服务器进行解析，Dns服务器的解析的过程就是按照A记录的顺序，依 次分配IP地址。Dns轮询方式实现均衡就是利用这个原理，在一个域名下面绑定N个IP地址，访问请求被均衡到不同的设备。Dns轮询方式提供的IP地 址，在大型网站中往往是一个集群的地址，可能是均衡交换机也可能是均衡服务器。对于小网站的话，挂接多台服务器也没有问题。
DNS轮询均衡的优点：
1、零成本：只是在Dns服务器上绑定几个A记录，域名注册商一般都提供；
2、部署简单：就是在网络拓扑进行设备扩增，然后在Dns服务器上添加记录。
DNS轮询均衡的缺点：
1、流量分配不均：Dns解析过程其实环节很多，而且是一种层层缓存的机制，你的dns服务器虽然进行更新，但是客户机、以及网络上其它的dns服 务器不会实时更新，所以流量很难保证100%的平均。目前，dns服务器都提供了多种手段可以调整dns轮询分配的策略，但是确实无法保证很完美的均衡。
2、健康检查：Dns服务器中A记录地址中的某一台服务器宕机，DNS服务器是无法知道的，仍旧会将访问分配到此服务器。所以需要人员或者工具进行 实时检测，在某台机器宕机之后，把备份机推上生产线，如果想要从A记录地址摘除某个地址，这个通知过程需要几个小时甚至更久才能扩散到所有的客户机。
Dns轮询方式推到服务的最前端还是很有效的，它通过最原始的方式，把访问用户映射到不同的服务集群上。对于大型网站来讲，对外服务的IP地址是不 可能经常变动的，而且后端的集群一旦宕掉，可以迅速推上冗余集群。再加上，一般都是经过CDN部署，服务被拆分到各个局部，所以在运营过程中不会产生太大 的影响。
3. OSI七层模型
我们接下来讲讲七层均衡。要理解四七层均衡的原理，就先要回忆一下大学课本里学的网络七层模型(OSI)。
OSI是一个开放性的通行系统互连参考模型，他是一个定义的非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。
OSI七层模型是一个很好的理论模型，但是在实际应用中都做了裁剪。尤其是TCP/IP的盛行，把7层结构压成了4层，
所以很多人都批评OSI七层模型过于复杂，但是作为一个完整的全面的网络模型，还是被大家非常认可的。OSI的7层从上到下分别是应用层、表示层、 会话层、传输层、网络层、数据链路层、物理层。
OSI 7层的功能描述：
（1）应用层：与其他计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字 处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序员就需要实现OSI的第7层。示 例：telnet，HTTP,FTP,WWW,NFS,SMTP等。
（2）表示层：这一层的主要功能是定义数据格式及加密。例如，FTP允许你选择以二进制或ASII格式传输。如果选择二进制，那么发送方和接收方不 改变文件的内容。如果选择ASII格式，发送方将把文本从发送方的字符集转换成标准的ASII后发送数据。在接收方将标准的ASII转换成接收方计算机的 字符集。示例：加密，ASII等。
（3）会话层：他定义了如何开始、控制和结束一个会话，包括对多个双向小时的控制和管理，以便在只完成连续消息的一部分时可以通知应用，从而使表示 层看到的数据是连续的，在某些情况下，如果表示层收到了所有的数据，则用数据代表表示层。示例：RPC，SQL等。
（4）传输层：这层的功能包括是否选择差错恢复协议还是无差错恢复协议，及在同一主机上对不同应用的数据流的输入进行复用，还包括对收到的顺序不对 的数据包的重新排序功能。示例：TCP，UDP，SPX。
（5）网络层：这层对端到端的包传输进行定义，他定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。为了适应最大传输单元长 度小于包长度的传输介质，网络层还定义了如何将一个包分解成更小的包的分段方法。示例：IP,IPX等。
（6）数据链路层：他定义了在单个链路上如何传输数据。这些协议与被讨论的歌种介质有关。示例：ATM，FDDI等。
（7）物理层：OSI的物理层规范是有关传输介质的特性标准，这些规范通常也参考了其他组织制定的标准。连接头、针、针的使用、电流、电流、编码及 光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。
作者：王泽宾，系统架构师。先后供职于九城、新浪等公司，长期负责产品研发和技术管理等相关工作。
很多年过去了，我再想起当初我的回答，依然觉得那个回答是正确的。就产品开发层面来讲，互联网开发确实简单多了。这里首先澄清一个概念，我所说的互 联网开发并不是指所有的B/S应用，例如B/S方式的银行内部业务系统。我所说的互联网应用是指在互联网上服务于公众的应用。企业级的业务系统，它的特点 是业务逻辑是比较复杂的，但用户一般不太大；互联网应用则相反，业务逻辑一般很简单，但面对的是海量用户。
既然互联网应用开发的业务逻辑不复杂，但为什么大型网站都投入了那么多的技术人员呢？主要是因为运营的环境太复杂，这种复杂性形成的原因以下：
1、公开性
网站的服务是公开的，任何人都可以来访问，所以就会直接面对大量的不良用户，系统数据的安全面临很大的风险，一旦系统被攻入，结果将是灾难性的。
2、访问量大
访问量大，就意味着网站必须能够承受高并发大流量的考验，如果网站的服务能力和健壮性等达不到要求，你的系统就会被冲垮。
3、用户体验
用户体验要好，除了产品设计的因素之外，就要求访问网站的速度要快，具有高可用性，别用一会就挂。
网站各子系统如何进行部署，如何提高系统的健壮性和高可用性，如何实现网站的安全，如何提高访问速度，如何进行负载均衡，甚至于采用什么的硬件设 备，另外，网站发展的不同时期会可能会采用不同的架构，如何实现架构的平滑过渡，如何使目前的架构具有弹性，具备可扩展的能力，这都是大型网站必须解决的 问题，也是小网站成长过程中迟早会遇到的问题。我后面的文章将会逐步就这个话题展开。
网站机构包括网站的软件架构和系统架构两部分，软件架构主要是指子系统和逻辑层的划分结构；系统架构，一般是系统部署结构。
系统架构师的知识体系比较庞杂，所谓的见多识广，多数是由运维工程师成长起来的，他们开发能力不强，编码不多，但动手能力很强，脚本编写非常熟练， 经常会做各种类型的实验，密切跟踪最新技术最新产品的相关信息。当然，一个大型的网站，需要一个架构师团队，他们各自承担擅长领域的架构设计，比如安全架 构、存储架构等等。
我觉得一般的开发人员还是很难走上这条路的，这份工作需要经验，需要不断实践，但如果开发人员一旦走上了这条路，会有很大的发展，主要源于开发人员 的思考习惯和技术的深度。我的这系列文章，开发人员可以作为参考，比如如何开发可分布式部署的系统，另外很多朋友都是身兼数职，从开发到实施，到部署全部 包办。我个人深感精力有限，所以又特意找了几个朋友从Unix/Linux系统和Windows系统不同角度进行探索，以造福正在摸索中的朋友，有兴趣的 朋友也可以参与。
其实，这部分内容我一直在写，比如PHP深度探索系列，写了大量的关于apache的内容，我已经大体把apache代码阅读了一遍，很费时间，进 度缓慢，但我想这有助于我们理解apache的配置和调优。
在介绍网站架构之前，我们先介绍一些网站架构中最基础和常见的概念，以便更好的理解后面的有关负载均衡和分布式存储等技术。第一个，首先讲讲 CDN。
1、CDN是什么
CDN（Content Delivery Network），就是内容发布网或者内容分发网，它的主要目的：通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的 网络边缘，使用户可以就近取得所需的内容，从而提高用户访问网站的响应速度，提升用户体验，同时能够分散访问压力，把本来用户集中访问分散到各地去。网站 的内容提供商（比如新浪、搜狐、网易等等）使用CDN，就可以在宏观层解决一部分大流量、海量用户并发等令人头疼的问题。
2、CDN的组成
内容发布网(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理４个要件，而内容管理和全局的网络流量 管理是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务，达到用户所要求的服务距用户仅 有”一跳”(Single Hop)之遥。
我们通常的内容发布模式都是将网站数据放到一处，然后应对来自世界各地的访问，我们多数考虑的是软件部署架构，很少考虑网络硬件架构。与之形成对比 的是，CDN则强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。
内容提供商承担了他们不该干也干不好的内容发布服务。
3、互联网服务的产业链
纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革， 在这条价值链上的角色越来越多也越来越细分，出现了内容运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色 都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和 IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占 用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的 选择，这就是CDN服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择，无疑对于构建良好的互联网价值链是有价值的，也是不可或 缺的最优网站加速服务。
4、CDN服务提供商
ChinaCache是中国最大的CDN服务提供商，是不是唯一未可知也。要想成为CDN服务提供商，恐怕要摆平电信、网通、铁通等等运营商，这得 需要什么样的能力和背景不得而知。它的服务节点在全球已经超过130个，其中国内节点超过80个，覆盖全国主要6大网络（所谓6线机房，就是这么来的）的 主要省份，象各大门户网站，比如新浪、网易等等都是租用了他们的服务。所以，你无论是在南方，或者北方，还是在北美，访问这些门户网站，感觉速度都很快， 最主要的原因之一就是CDN发挥了效果。一般小网站是用不起这服务的，所以慢点就慢点了吧，可以租用互联互通的6线机房，如果网络足够宽的话，用户也可以 忍受。如果想继续提升用户体验的话，就需要做一些网站镜像，部署在具有代表性的几个大城市，比如华南可以部署在广州，华东可以部署在上海，华北可以部署在 北京，不过内容镜像的过程，就需要自己去部署和维护。还有的网站，采用内容分割的方式，比如建立针对各地的分站，业务情况不同，可能部署的策略不同。 CDN可以认为是基础网络建设的一种策略。
前面介绍了cdn的一些原理和概念，以及提供cdn基础网络服务的途径。cdn看起来对于静态内容的，比如html,js,image是非常合适 的，通过cdn的部署，用户只需要一跳就可以访问到网站的内容。那对于动态内容怎么办呢？我回答一下：
动态内容按照存在形态可以分为三类。
第一类：内容长时间不需变化，这类内容一般是通过网页静化技术，实现动态内容转换成静态内容，从而达到cdn部署，典型的就是内容类网站，比如新 浪、搜狐、网易等等的内容发布系统cms，内容的增删改等管理工作被准实时同步到各个节点。
第二类：内容可能会短时间内发生变动，但是最终会稳定。比如论坛、博客等应用，这类服务提供的内容按照一定的时间间隔，实现批量静化，当然也有实时 静化，像Mop的大杂烩、网易社区就是使用了这样的策略。
第三类：内容会实时变化，非常个性化。比如邮箱应用，这类服务提供的内容无法实现静化，只能通过实行分区域部署和负载均衡等手段进行优化。
对于提供cdn服务的厂商来讲，静态内容的cdn自然没有问题，对于第三类服务，只能从通信链路层进行相应的优化。
对于很多网站的伪静化，有的出于Seo的考虑，有的出于安全性的考虑，手段基本上是rewrite Url。它只不过是一种外在的表现形式，与Html静化是两回事，它依然是一种动态内容。
1. 负载均衡的分类
负载均衡技术在网站运营过程中应用非常普遍，技术也很成熟。负载均衡技术按照软硬件形式分为软均衡和硬均衡。软均衡就是基于软件技术的均衡，硬均衡 是基于硬件技术的均衡；
按照网络协议划分又分为四层均衡和七层均衡。四层均衡就是基于OSI网络层的数据均衡，七层均衡是基于OSI应用层的数据均衡。
各种均衡方式在大型网站中均有采用，而且大多数情况下，是多种均衡方式的组合。
2. DNS轮询均衡
这种方式，算是比较独立的一种方式，不在上述划分之列，但使用比较广泛，一般用在网站最前端。你可以做个试验，在dos命令行中运行nslook命 令。比如：nslookup www.163.com，你会看到命令给出了一堆解析后的IP地址。这些地址就是www.163.com这个域名绑定的多条A记录。我们从浏览器发起的访 问请求http://www.163.com/，那么你输入的域名首先需要经过DNS服务器进行解析，Dns服务器的解析的过程就是按照A记录的顺序，依 次分配IP地址。Dns轮询方式实现均衡就是利用这个原理，在一个域名下面绑定N个IP地址，访问请求被均衡到不同的设备。Dns轮询方式提供的IP地 址，在大型网站中往往是一个集群的地址，可能是均衡交换机也可能是均衡服务器。对于小网站的话，挂接多台服务器也没有问题。
DNS轮询均衡的优点：
1、零成本：只是在Dns服务器上绑定几个A记录，域名注册商一般都提供；
2、部署简单：就是在网络拓扑进行设备扩增，然后在Dns服务器上添加记录。
DNS轮询均衡的缺点：
1、流量分配不均：Dns解析过程其实环节很多，而且是一种层层缓存的机制，你的dns服务器虽然进行更新，但是客户机、以及网络上其它的dns服 务器不会实时更新，所以流量很难保证100%的平均。目前，dns服务器都提供了多种手段可以调整dns轮询分配的策略，但是确实无法保证很完美的均衡。
2、健康检查：Dns服务器中A记录地址中的某一台服务器宕机，DNS服务器是无法知道的，仍旧会将访问分配到此服务器。所以需要人员或者工具进行 实时检测，在某台机器宕机之后，把备份机推上生产线，如果想要从A记录地址摘除某个地址，这个通知过程需要几个小时甚至更久才能扩散到所有的客户机。
Dns轮询方式推到服务的最前端还是很有效的，它通过最原始的方式，把访问用户映射到不同的服务集群上。对于大型网站来讲，对外服务的IP地址是不 可能经常变动的，而且后端的集群一旦宕掉，可以迅速推上冗余集群。再加上，一般都是经过CDN部署，服务被拆分到各个局部，所以在运营过程中不会产生太大 的影响。
3. OSI七层模型
我们接下来讲讲七层均衡。要理解四七层均衡的原理，就先要回忆一下大学课本里学的网络七层模型(OSI)。
OSI是一个开放性的通行系统互连参考模型，他是一个定义的非常好的协议规范。OSI模型有7层结构，每层都可以有几个子层。
OSI七层模型是一个很好的理论模型，但是在实际应用中都做了裁剪。尤其是TCP/IP的盛行，把7层结构压成了4层，
所以很多人都批评OSI七层模型过于复杂，但是作为一个完整的全面的网络模型，还是被大家非常认可的。OSI的7层从上到下分别是应用层、表示层、 会话层、传输层、网络层、数据链路层、物理层。
OSI 7层的功能描述：
（1）应用层：与其他计算机进行通讯的一个应用，它是对应应用程序的通信服务的。例如，一个没有通信功能的字处理程序就不能执行通信的代码，从事字 处理工作的程序员也不关心OSI的第7层。但是，如果添加了一个传输文件的选项，那么字处理器的程序员就需要实现OSI的第7层。示 例：telnet，HTTP,FTP,WWW,NFS,SMTP等。
（2）表示层：这一层的主要功能是定义数据格式及加密。例如，FTP允许你选择以二进制或ASII格式传输。如果选择二进制，那么发送方和接收方不 改变文件的内容。如果选择ASII格式，发送方将把文本从发送方的字符集转换成标准的ASII后发送数据。在接收方将标准的ASII转换成接收方计算机的 字符集。示例：加密，ASII等。
（3）会话层：他定义了如何开始、控制和结束一个会话，包括对多个双向小时的控制和管理，以便在只完成连续消息的一部分时可以通知应用，从而使表示 层看到的数据是连续的，在某些情况下，如果表示层收到了所有的数据，则用数据代表表示层。示例：RPC，SQL等。
（4）传输层：这层的功能包括是否选择差错恢复协议还是无差错恢复协议，及在同一主机上对不同应用的数据流的输入进行复用，还包括对收到的顺序不对 的数据包的重新排序功能。示例：TCP，UDP，SPX。
（5）网络层：这层对端到端的包传输进行定义，他定义了能够标识所有结点的逻辑地址，还定义了路由实现的方式和学习的方式。为了适应最大传输单元长 度小于包长度的传输介质，网络层还定义了如何将一个包分解成更小的包的分段方法。示例：IP,IPX等。
（6）数据链路层：他定义了在单个链路上如何传输数据。这些协议与被讨论的歌种介质有关。示例：ATM，FDDI等。
（7）物理层：OSI的物理层规范是有关传输介质的特性标准，这些规范通常也参考了其他组织制定的标准。连接头、针、针的使用、电流、电流、编码及 光调制等都属于各种物理层规范中的内容。物理层常用多个规范完成对所有细节的定义。
作者：王泽宾，系统架构师。先后供职于九城、新浪等公司，长期负责产品研发和技术管理等相关工作。
May
19
之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结 果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇 文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，文 中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这 个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而 这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶 段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住 了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞 争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加， 发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策 略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等。
架构演变第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是 开始变慢，经过查找，可能会发现系 统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完 毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加 一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、 如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态 信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何 保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正 常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了 以往的速度。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、 主备技术（包括但不限于ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共 享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、 更新的这些操作的部分数据库连接的 资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普 遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很 高的要求的。
架构演变第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工 作，当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个 在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个 阶段可 能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察 和折磨，终于是将大量的数据缓存转移到分布式缓存上了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的 封装等；
架构演变第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天， 发现系统的访问又开始有变慢的趋势 了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网 络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购 买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载 集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系 统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有 更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
架构演变第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导 致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离 的方案，当然，这个方案要实现并不 容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一 些更为廉价的存储方案，例如BigTable这种。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量 了，对于大型网站而言，人气的重要毋 庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大 了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦， 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将 系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要 提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理 和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步， 差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用 其他各种各样的方法来支撑着越来越高的访问量。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作 系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。
说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不 同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及， 像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发 展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易，写 这篇文章更多的是希望能够引出更多大型网站架构演变的介绍。
原文地址：http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html
架构演变第一步：物理分离webserver和数据库
最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这 个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而 这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶 段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住 了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞 争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存
增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加， 发现系统又开始变的有些慢了，在尝 到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策 略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等。
架构演变第四步：数据缓存
在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是 开始变慢，经过查找，可能会发现系 统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完 毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
架构演变第五步： 增加webserver
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加 一台webserver，这也是为了同时解决可用性的问题，避免单台的webserver down机的话就没法使用了，在做了这些考虑后，决定增加一台webserver，增加一台webserver时，会碰到一些问题，典型的有：
1、 如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态 信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何 保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正 常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了 以往的速度。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
负载均衡技术（包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等）、 主备技术（包括但不限于ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共 享文件技术（包括但不限于NFS等）、存储技术（包括但不限于存储设备等）。
架构演变第六步：分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、 更新的这些操作的部分数据库连接的 资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普 遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；
但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很 高的要求的。
架构演变第七步：分表、DAL和分布式缓存
随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工 作，当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个 在ebay的架构中对应的就是DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个 阶段可 能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察 和折磨，终于是将大量的数据缓存转移到分布式缓存上了。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；
DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的 封装等；
架构演变第八步：增加更多的webserver
在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天， 发现系统的访问又开始有变慢的趋势 了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢，这还好办，一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添加 webserver服务器的过程，有可能会出现几种挑战：
1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网 络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购 买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载 集群中；
2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系 统等；
在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有 更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
架构演变第九步：数据读写分离和廉价存储方案
突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导 致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离 的方案，当然，这个方案要实现并不 容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一 些更为廉价的存储方案，例如BigTable这种。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
廉价存储方案要求对OS的文件存储有深入的掌握和理解，同时要求对采用的语言在文件这块的实现有深入的掌握。
架构演变第十步：进入大型分布式应用时代和廉价服务器群梦想时代
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加webserver就可以支撑越来越高的访问量 了，对于大型网站而言，人气的重要毋 庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大 了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦， 因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导 致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将 系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
1、拆成分布式后需要 提供一个高性能、稳定的通信框架，并且需要支持多种不同的通信和远程调用方式；
2、将一个庞大的应用拆分需要耗费很长的时间，需要进行业务的整理 和系统依赖关系的控制等；
3、如何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
经过这一步， 差不多系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么多次演变过程吸取的经验来采用 其他各种各样的方法来支撑着越来越高的访问量。
看看这一步完成后系统的图示：
这一步涉及到了这些知识体系：
这一步涉及的知识体系非常的多，要求对通信、远程调用、消息机制等有深入的理解和掌握，要求的都是从理论、硬件级、操作 系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也非常的多，多数情况下需要掌握分布式并行计算、报表、监控技术以及规则策略等等。
说起来确实不怎么费力，整个网站架构的经典演变过程都和上面比较的类似，当然，每步采取的方案，演变的步骤有可能有不 同，另外，由于网站的业务不同，会有不同的专业技术的需求，这篇blog更多的是从架构的角度来讲解演变的过程，当然，其中还有很多的技术也未在此提及， 像数据库集群、数据挖掘、搜索等，但在真实的演变过程中还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量，因此在真实的发 展过程中还会有很多的不同，另外一个大型网站要做到的远远不仅仅上面这些，还有像安全、运维、运营、服务、存储等，要做好一个大型的网站真的很不容易，写 这篇文章更多的是希望能够引出更多大型网站架构演变的介绍。
原文地址：http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html
May
18
一. OpenVPN 安装环境
Server 端的环境
1.CentOS, kernel版本: 2.6.18, IP 为 221.233.59.16(ADSL拨号)
2.kernel 需要支持 tun 设备, 需要加载 iptables 模块.
3.安装的 OpenVPN 的版本: 2.1.rc15.(目前最新版 可在http://openvpn.net 上下载).
Client 端的环境: 1.Windows XP SP2
2.openvpn-2.1_rc15-install.exe(此版本集成了 OpenVPN GUI 客户端)
二. OpenVPN 服务端安装过程
1.用putty登录到CentOS
2.下载LZO和OpenVPN 2.1.rc15 wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz
wget http://openvpn.net/release/openvpn-2.1_rc15.tar.gz yum install -y openssl-devel
3.安装LZO和OpenVPN tar zxvf lzo-2.03.tar.gz
cd lzo-2.03
./configure
make
make install
cd ..
tar zxvf openvpn-2.1_rc15.tar.gz
cd openvpn-2.1_rc15
./configure
make
make install
cd ..
cp /root/openvpn-2.1_rc15/easy-rsa/ -r /etc/openvpn
4.生成证书初始化PKI cd /etc/openvpn/2.0/#可以设置下OpenVPN参数(也可以修改vars文件来配置)
export D=`pwd`
export KEY_CONFIG=$D/openssl.cnf
export KEY_DIR=$D/keys
export KEY_SIZE=1024
export KEY_COUNTRY=CN
export KEY_PROVINCE=GD
export KEY_CITY=SZ
export KEY_ORG="dvdmaster"
export KEY_EMAIL="[email protected]"
#也可以不用设置直接执行下面的命令
. vars
创建证书颁发机构(CA)
./clean-all
./build-ca
Generating a 1024 bit RSA private key
................++++++
........++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [GD]:
Locality Name (eg, city) [SZ]:
Organization Name (eg, company) [dvdmaster]:
Organizational Unit Name (eg, section) []:dvdmaster
Common Name (eg, your name or your server's hostname) []:server
Email Address [[email protected]]:
建立server key
./build-key-server server
Generating a 1024 bit RSA private key
......++++++
....................++++++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [GD]:
Locality Name (eg, city) [SZ]:
Organization Name (eg, company) [dvdmaster]:
Organizational Unit Name (eg, section) []:dvdmaster
Common Name (eg, your name or your server's hostname) []:server
Email Address [[email protected]]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:abcd1234
An optional company name []:dvdmaster
Using configuration from /etc/openvpn/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CN'
stateOrProvinceName :PRINTABLE:'GD'
localityName :PRINTABLE:'SZ'
organizationName :PRINTABLE:'dvdmaster'
organizationalUnitName:PRINTABLE:'dvdmaster'
commonName :PRINTABLE:'server'
emailAddress :IA5STRING:'[email protected]'
Certificate is to be certified until Mar 19 08:15:31 2016 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
生成客户端 key
./build-key client1
Generating a 1024 bit RSA private key
.....++++++
......++++++
writing new private key to 'client1.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [GD]:
Locality Name (eg, city) [SZ]:
Organization Name (eg, company) [dvdmaster]:
Organizational Unit Name (eg, section) []:dvdmaster
Common Name (eg, your name or your server's hostname) []:client1 #重要: 每个不同的client 生成的证书, 名字必须不同.
Email Address [[email protected]]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:abcd1234
An optional company name []:dvdmaster
Using configuration from /etc/openvpn/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CN'
stateOrProvinceName :PRINTABLE:'GD'
localityName :PRINTABLE:'SZ'
organizationName :PRINTABLE:'dvdmaster'
organizationalUnitName:PRINTABLE:'dvdmaster'
commonName :PRINTABLE:'client1'
emailAddress :IA5STRING:'[email protected]'
Certificate is to be certified until Mar 19 08:22:00 2016 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
以此类推建立其他客户端 key
./build-key client2
./build-key client3
注意在进入 Common Name (eg, your name or your server’s hostname) []: 的输入时, 每个证书输入的名字必须不同.
5.生成Diffie Hellman参数 ./build-dh
6.将 keys 下的所有文件打包下载到本地(可以通过winscp,http,ftp等等……) tar zcvf yskeys.tar.gz keys/
7.创建服务端配置文件 mkdir /etc/openvpn/2.0/conf
cp /root/openvpn-2.1_rc15/sample-config-files/server.conf /etc/openvpn/2.0/conf/server.conf
服务端配置文件(server.conf)样例
port 1194
proto udp
dev tun
ca /etc/openvpn/2.0/keys/ca.crt
cert /etc/openvpn/2.0/keys/ovpnser.crt
key /etc/openvpn/2.0/keys/ovpnser.key # This file should be kept secret
dh /etc/openvpn/2.0/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 202.103.44.150" #客户端获得的DNS地址
push "dhcp-option DNS 202.103.24.68" #客户端获得的DNS地址
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
8.启动OpenVPN /usr/local/sbin/openvpn --config /etc/openvpn/2.0/conf/server.conf &
三. OpenVPN GUI For Windows客户端安装过程
1.下载 openvpn-2.1_rc15-install.exe(此版本集成 OpenVPN GUI)官方下载地址:http://openvpn.net/release/openvpn-2.1_rc15-install.exe
2.依屏幕指示安装OpenVPN GUI
3.配置 openvpn gui将上面第6步打包的yskeys.tar.gz中的下列证书文件解压到 你的OpenVPN GUI安装路径OpenVPNconfig文件夹下 ca.crt
ca.key
client1.crt
client1.csr
client1.key
4.修改client.ovpn把你的OpenVPN GUI安装路径OpenVPNsample-config下的client.ovpn文件复制到你的OpenVPN GUI安装路径OpenVPNconfig文件夹下,用记事本打开client.ovpn #找到remote my-server-1 1194,把my-server-1改成你的ip地址
remote 221.233.59.16 1194
5.双击 client.ovpn 即可启动 openvpn, 或者通过 OpenVPN GUI 的控制启动 VPN.
三. OpenVPN 访问外网的设置
1.开启CentOS 5 的路由转发功能 echo 1 > /proc/sys/net/ipv4/ip_forward
#为了使CentOS重启后仍然开启路由转发功能我们需要再执行下列命令
sysctl -w net.ipv4.ip_forward=1
2.添加iptables转发规则 #因为我那天CentOS是ADSL拨号上网,所以把出口设置成ppp0,请根据实际情况设置
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ppp0 -j MASQUERADE
3.必须保证server.conf配置中,有下面三个配置 push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 202.103.44.150" #客户端获得的DNS地址
push "dhcp-option DNS 202.103.24.68" #客户端获得的DNS地址
当 client 连接成功后, 在 cmd 下执行 ipconfig /all, 应该有这类似这样的输出:
Ethernet adapter 本地连接 2:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Win32 Adapter V9
Physical Address. . . . . . . . . : 00-FF-F2-1A-44-BD
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.8.0.6
Subnet Mask . . . . . . . . . . . : 255.255.255.252
Default Gateway . . . . . . . . . : 10.8.0.5
DHCP Server . . . . . . . . . . . : 10.8.0.5
DNS Servers . . . . . . . . . . . : 10.8.0.1
202.103.44.150
202.103.24.68
Lease Obtained. . . . . . . . . . : 2009年5月8日 23:55:06
Lease Expires . . . . . . . . . . : 2010年5月8日 23:55:06
四. 设置 OpenVPN 服务器 reboot后自动启动 openvpn
执行
vi /etc/rc.local
然后在最后面加入此行:
/usr/local/sbin/openvpn --config /etc/openvpn/2.0/conf/server.conf &
五.OpenVPN 测试
连接成功之后,去www.ip138.com上看看外网ip是多少,如果是CentOS系统的外网ip那说明测试成功了~
Server 端的环境
1.CentOS, kernel版本: 2.6.18, IP 为 221.233.59.16(ADSL拨号)
2.kernel 需要支持 tun 设备, 需要加载 iptables 模块.
3.安装的 OpenVPN 的版本: 2.1.rc15.(目前最新版 可在http://openvpn.net 上下载).
Client 端的环境: 1.Windows XP SP2
2.openvpn-2.1_rc15-install.exe(此版本集成了 OpenVPN GUI 客户端)
二. OpenVPN 服务端安装过程
1.用putty登录到CentOS
2.下载LZO和OpenVPN 2.1.rc15 wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz
wget http://openvpn.net/release/openvpn-2.1_rc15.tar.gz yum install -y openssl-devel
3.安装LZO和OpenVPN tar zxvf lzo-2.03.tar.gz
cd lzo-2.03
./configure
make
make install
cd ..
tar zxvf openvpn-2.1_rc15.tar.gz
cd openvpn-2.1_rc15
./configure
make
make install
cd ..
cp /root/openvpn-2.1_rc15/easy-rsa/ -r /etc/openvpn
4.生成证书初始化PKI cd /etc/openvpn/2.0/#可以设置下OpenVPN参数(也可以修改vars文件来配置)
export D=`pwd`
export KEY_CONFIG=$D/openssl.cnf
export KEY_DIR=$D/keys
export KEY_SIZE=1024
export KEY_COUNTRY=CN
export KEY_PROVINCE=GD
export KEY_CITY=SZ
export KEY_ORG="dvdmaster"
export KEY_EMAIL="[email protected]"
#也可以不用设置直接执行下面的命令
. vars
创建证书颁发机构(CA)
./clean-all
./build-ca
Generating a 1024 bit RSA private key
................++++++
........++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [GD]:
Locality Name (eg, city) [SZ]:
Organization Name (eg, company) [dvdmaster]:
Organizational Unit Name (eg, section) []:dvdmaster
Common Name (eg, your name or your server's hostname) []:server
Email Address [[email protected]]:
建立server key
./build-key-server server
Generating a 1024 bit RSA private key
......++++++
....................++++++
writing new private key to 'server.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [GD]:
Locality Name (eg, city) [SZ]:
Organization Name (eg, company) [dvdmaster]:
Organizational Unit Name (eg, section) []:dvdmaster
Common Name (eg, your name or your server's hostname) []:server
Email Address [[email protected]]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:abcd1234
An optional company name []:dvdmaster
Using configuration from /etc/openvpn/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CN'
stateOrProvinceName :PRINTABLE:'GD'
localityName :PRINTABLE:'SZ'
organizationName :PRINTABLE:'dvdmaster'
organizationalUnitName:PRINTABLE:'dvdmaster'
commonName :PRINTABLE:'server'
emailAddress :IA5STRING:'[email protected]'
Certificate is to be certified until Mar 19 08:15:31 2016 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
生成客户端 key
./build-key client1
Generating a 1024 bit RSA private key
.....++++++
......++++++
writing new private key to 'client1.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [CN]:
State or Province Name (full name) [GD]:
Locality Name (eg, city) [SZ]:
Organization Name (eg, company) [dvdmaster]:
Organizational Unit Name (eg, section) []:dvdmaster
Common Name (eg, your name or your server's hostname) []:client1 #重要: 每个不同的client 生成的证书, 名字必须不同.
Email Address [[email protected]]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:abcd1234
An optional company name []:dvdmaster
Using configuration from /etc/openvpn/2.0/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'CN'
stateOrProvinceName :PRINTABLE:'GD'
localityName :PRINTABLE:'SZ'
organizationName :PRINTABLE:'dvdmaster'
organizationalUnitName:PRINTABLE:'dvdmaster'
commonName :PRINTABLE:'client1'
emailAddress :IA5STRING:'[email protected]'
Certificate is to be certified until Mar 19 08:22:00 2016 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
以此类推建立其他客户端 key
./build-key client2
./build-key client3
注意在进入 Common Name (eg, your name or your server’s hostname) []: 的输入时, 每个证书输入的名字必须不同.
5.生成Diffie Hellman参数 ./build-dh
6.将 keys 下的所有文件打包下载到本地(可以通过winscp,http,ftp等等……) tar zcvf yskeys.tar.gz keys/
7.创建服务端配置文件 mkdir /etc/openvpn/2.0/conf
cp /root/openvpn-2.1_rc15/sample-config-files/server.conf /etc/openvpn/2.0/conf/server.conf
服务端配置文件(server.conf)样例
port 1194
proto udp
dev tun
ca /etc/openvpn/2.0/keys/ca.crt
cert /etc/openvpn/2.0/keys/ovpnser.crt
key /etc/openvpn/2.0/keys/ovpnser.key # This file should be kept secret
dh /etc/openvpn/2.0/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 202.103.44.150" #客户端获得的DNS地址
push "dhcp-option DNS 202.103.24.68" #客户端获得的DNS地址
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
8.启动OpenVPN /usr/local/sbin/openvpn --config /etc/openvpn/2.0/conf/server.conf &
三. OpenVPN GUI For Windows客户端安装过程
1.下载 openvpn-2.1_rc15-install.exe(此版本集成 OpenVPN GUI)官方下载地址:http://openvpn.net/release/openvpn-2.1_rc15-install.exe
2.依屏幕指示安装OpenVPN GUI
3.配置 openvpn gui将上面第6步打包的yskeys.tar.gz中的下列证书文件解压到 你的OpenVPN GUI安装路径OpenVPNconfig文件夹下 ca.crt
ca.key
client1.crt
client1.csr
client1.key
4.修改client.ovpn把你的OpenVPN GUI安装路径OpenVPNsample-config下的client.ovpn文件复制到你的OpenVPN GUI安装路径OpenVPNconfig文件夹下,用记事本打开client.ovpn #找到remote my-server-1 1194,把my-server-1改成你的ip地址
remote 221.233.59.16 1194
5.双击 client.ovpn 即可启动 openvpn, 或者通过 OpenVPN GUI 的控制启动 VPN.
三. OpenVPN 访问外网的设置
1.开启CentOS 5 的路由转发功能 echo 1 > /proc/sys/net/ipv4/ip_forward
#为了使CentOS重启后仍然开启路由转发功能我们需要再执行下列命令
sysctl -w net.ipv4.ip_forward=1
2.添加iptables转发规则 #因为我那天CentOS是ADSL拨号上网,所以把出口设置成ppp0,请根据实际情况设置
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ppp0 -j MASQUERADE
3.必须保证server.conf配置中,有下面三个配置 push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 202.103.44.150" #客户端获得的DNS地址
push "dhcp-option DNS 202.103.24.68" #客户端获得的DNS地址
当 client 连接成功后, 在 cmd 下执行 ipconfig /all, 应该有这类似这样的输出:
Ethernet adapter 本地连接 2:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Win32 Adapter V9
Physical Address. . . . . . . . . : 00-FF-F2-1A-44-BD
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.8.0.6
Subnet Mask . . . . . . . . . . . : 255.255.255.252
Default Gateway . . . . . . . . . : 10.8.0.5
DHCP Server . . . . . . . . . . . : 10.8.0.5
DNS Servers . . . . . . . . . . . : 10.8.0.1
202.103.44.150
202.103.24.68
Lease Obtained. . . . . . . . . . : 2009年5月8日 23:55:06
Lease Expires . . . . . . . . . . : 2010年5月8日 23:55:06
四. 设置 OpenVPN 服务器 reboot后自动启动 openvpn
执行
vi /etc/rc.local
然后在最后面加入此行:
/usr/local/sbin/openvpn --config /etc/openvpn/2.0/conf/server.conf &
五.OpenVPN 测试
连接成功之后,去www.ip138.com上看看外网ip是多少,如果是CentOS系统的外网ip那说明测试成功了~
May
17
[文章作者：张宴 本文版本：v1.0 最后修改：2007.08.02 转载请注明出处：http://blog.s135.com]
Squid web缓存加速软件目前已经是新浪、搜狐、网易等各大网站广泛应用。Squid会在设置的缓存目录下建立多个目录，每一个目录下又建立多个目录，然后才在最里层的目录中存放缓存文件（object）。squid会根据用户请求网页的URL进行哈希，生成缓存文件，存放在某一个目录中。squid启动之后，将在内存中建立一个哈希表，记录硬盘中缓存文件配置的情形。
对于类似http://you.video.sina.com.cn/index.html之类的网页，squid只会生成一个缓存文件。可以用squid附带的squidclient工具清除：
squidclient -m PURGE -p 80 "http://you.video.sina.com.cn/index.html"
而对于带有参数的网页，例如新浪播客的Flash播放器http://vhead.blog.sina.com.cn/player/outer_player.swf?auto=0&vid=4469852&uid=1278987704，因“?”后面的参数不同，导致URL也不同，squid会生成多个缓存文件，哈希分散存放在不同的目录。如果修改了这个outer_player.swf文件，要更新squid缓存就要去清除不同目录下及内存中的很多个缓存文件，十分麻烦，于是我编写了一个Linux下的shell脚本，去完成这件麻烦的事：
脚本文件名：clear_squid_cache.sh（8月2日修正了UC网友“城市中的寂寞”反馈的BUG）
注意：请赋予clear_squid_cache.sh可执行权限（命令：chmod +x ./clear_squid_cache.sh）。请确保脚本所在目录可写。
设置：
squidcache_path= 表示squid缓存目录的路径
squidclient_path= 表示squidclient程序所在的路径，默认为squid安装目录下的bin/squidclient
用法：
1、清除所有Flash缓存（扩展名.swf）：
./clear_squid_cache.sh swf
2、清除URL中包含sina.com.cn的所有缓存：
./clear_squid_cache.sh sina.com.cn
3、清除文件名为zhangyan.jpg的所有缓存：
./clear_squid_cache.sh zhangyan.jpg
效率：
经测试，在DELL 2950上清除26000个缓存文件用时2分钟左右。平均每秒可清除缓存文件177个。
Squid web缓存加速软件目前已经是新浪、搜狐、网易等各大网站广泛应用。Squid会在设置的缓存目录下建立多个目录，每一个目录下又建立多个目录，然后才在最里层的目录中存放缓存文件（object）。squid会根据用户请求网页的URL进行哈希，生成缓存文件，存放在某一个目录中。squid启动之后，将在内存中建立一个哈希表，记录硬盘中缓存文件配置的情形。
对于类似http://you.video.sina.com.cn/index.html之类的网页，squid只会生成一个缓存文件。可以用squid附带的squidclient工具清除：
squidclient -m PURGE -p 80 "http://you.video.sina.com.cn/index.html"
而对于带有参数的网页，例如新浪播客的Flash播放器http://vhead.blog.sina.com.cn/player/outer_player.swf?auto=0&vid=4469852&uid=1278987704，因“?”后面的参数不同，导致URL也不同，squid会生成多个缓存文件，哈希分散存放在不同的目录。如果修改了这个outer_player.swf文件，要更新squid缓存就要去清除不同目录下及内存中的很多个缓存文件，十分麻烦，于是我编写了一个Linux下的shell脚本，去完成这件麻烦的事：
脚本文件名：clear_squid_cache.sh（8月2日修正了UC网友“城市中的寂寞”反馈的BUG）
引用
#!/bin/sh
squidcache_path="/data1/squid/var/cache"
squidclient_path="/usr/local/squid/bin/squidclient"
grep -a -r $1 $squidcache_path/* | strings | grep "http:" | awk -F'http:' '{print "http:"$2;}' > cache_list.txt
for url in `cat cache_list.txt`; do
$squidclient_path -m PURGE -p 80 $url
done
squidcache_path="/data1/squid/var/cache"
squidclient_path="/usr/local/squid/bin/squidclient"
grep -a -r $1 $squidcache_path/* | strings | grep "http:" | awk -F'http:' '{print "http:"$2;}' > cache_list.txt
for url in `cat cache_list.txt`; do
$squidclient_path -m PURGE -p 80 $url
done
注意：请赋予clear_squid_cache.sh可执行权限（命令：chmod +x ./clear_squid_cache.sh）。请确保脚本所在目录可写。
设置：
squidcache_path= 表示squid缓存目录的路径
squidclient_path= 表示squidclient程序所在的路径，默认为squid安装目录下的bin/squidclient
用法：
1、清除所有Flash缓存（扩展名.swf）：
./clear_squid_cache.sh swf
2、清除URL中包含sina.com.cn的所有缓存：
./clear_squid_cache.sh sina.com.cn
3、清除文件名为zhangyan.jpg的所有缓存：
./clear_squid_cache.sh zhangyan.jpg
效率：
经测试，在DELL 2950上清除26000个缓存文件用时2分钟左右。平均每秒可清除缓存文件177个。
