qq3250845

如果说要对web站点的动态页面、web服务、动态图片等进行优化，的方法是利用缓存；一般而言，请求动态页面，我们会把重叠利用的资源缓存数据，使得请求速度加快。
说到缓存，我们所指的是由动态内容自行实现的缓存机制，这其中包括整页缓存、局部缓存、数据缓存等，除此之外，还有代码解释器缓存、缓存服务器。
本章为大家介绍缓存方式的对比与选择
这里我们几种缓存方式对应的压力测试结果汇总一下。

也许你一眼看到 APC cache的性能优势，当然，这不是APC的特权，主要归咎于它使用了本地内存来存储缓存数据。但是需要提醒的是，无论是APC还是memcache，都使用内存来存储HTML缓存，所以缓存命中率是100%，而在实际情况中，一个站点包含了大量的动态页面，如果你为缓存分配的内存空间不足以容纳所有的缓存数据，便会使得缓存命中率大幅度下降，吞吐量也会随之降低。
这并不夸张，假如你的站点有数十万个动态网页需要保存HTML缓存，假设每个缓存为100K，那么10万个缓存的总大小是1G，如果你希望为每个缓存保持较长的有效期，那么需要准备好足够的内存空间，好吧，购买更多的内存，这似乎已经成为一个经济问题。但是，一旦本地内存达到上限，这似乎又变成了一个技术问题，往往到了这时候，你的站点规模已经让你不得不考虑比性能更加重要的问题，那是如何扩展缓存存储区，显然，使用memcache已经迈开了关键的一步。
速度而言，memcache不如使用本机内存的速度快，但出于多方面的考虑，结合你的站点规模，也许你会觉得值得。首先，Web服务器特别是web应用服务器，本身的内存是相当宝贵的，它要满足HTTP进程和脚本解释器的大量开销，无法拿出大量的空间来存放HTML缓存；其次，使用本机内存不具备良好的扩展性，一旦缓存数据和站点负载大幅度增加，为了保证较高的缓存命中率，必须加大缓存空间，本机内存显然成为瓶颈，而使用独立的缓存服务器可以通过增加服务器来快速扩展，构成多台服务器构成的分布式缓存系统，这在后边我们会深入探讨。
当然，对于小规模或者初创时期的Web站点，如果需要缓存的动态网页比较少，这时候使用APC内存缓存仍然不失为一个快速有效的方案，即便是规模膨胀后，快速重构缓存机制，并且迁移缓存数据，也不是一件多么复杂的事情,只要做好充分的准备可以了。

qq3250845

想知道如何创建集群服务器，首先要了解什么是集群服务器。在这里我不拿比较专业的知识来解释集群服务器，集群服务器类似于云服务器，都是为了使您的服务器更快，更安全。最近景安退出了一款云服务器免单公测，想了解的可以去测测。下面为大家分享干货。
如何创建集群服务器？
创建群集服务器
在服务器群集产品中含有用来在服务器上安装群集软件和创建新群集的群集安装实用工具。创建新群集时，首先在选择作为群集的个成员的计算机上运行该实用工具。
步是确定群集名称并创建群集数据库和初始的群集成员列表来定义新群集。 Windows server 2003 群集新增了一个群集管理设置向导以及使用 cluster.exe 命令行界面创建（ 包括从远程创建 ）群集的功能。 　　
创建群集的第二步是，添加可供所有群集成员使用的共用数据存储设备。这样，创建的新群集将带有一个节点、自己的本地数据存储设备以及群集共用资源 —— 通常是磁盘或数据存储和连接介质资源。 　　
创建群集的一步是，在另外将要成为群集成员的每一台计算机上运行安装实用工具。每当将新节点添加到群集中时，新节点都会自动从群集的原始成员获得现有群集数据库的副本。当节点加入或形成群集时，群集服务会更新该节点私有的配置数据库副本。 　　
形成群集服务器　
如果服务器运行了群集服务并且无法找到群集中的其它节点，它自己可以形成一个群集。要形成群集，节点必须能够获得对仲裁资源的独占权。当最初形成群集时，群集中的个节点将包括群集配置数据库。每当有新节点加入群集时，新节点都会在本地获得并保持群集配置数据库的副本。仲裁资源用恢复日志（其中含有同节点无关的群集配置和状态数据）的形式存储配置数据库的版本。 　　
在群集运行中，群集服务使用仲裁恢复日志执行以下操作：保证只有一组活动、可相互通讯的节点才能形成群集 　　仅当某个节点可以获得对仲裁资源的控制权时才允许它形成群集，仅当某个节点可以同控制仲裁资源的节点通讯时，才允许它加入或留在现有群集中从群集中的其它节点和群集服务管理接口的角度看，当形成群集时，群集中的每个节点可能处于三种不同状态中的一种。事件处理器会记录这些状态，而事件日志管理器会将这些状态复制到群集的其它节点。
群集服务状态包括：脱机。此时的节点不是完全有效的群集成员。该节点及其群集服务器可能在运行，也可能未运行。
联机。此时的节点是完全有效的群集成员。它遵从群集数据库的更新、对仲裁算法施加自己的影响、维护心跳通讯，并可以拥有和运行资源组。 暂停。此时的节点是完全有效的群集成员。它遵从群集数据库的更新、对仲裁算法施加自己的影响、维护心跳通讯，但它无法接受资源组。它只能支持它当前已拥有的那些资源组。之所以提供暂停状态，是为了允许执行某些维护。大多数服务器群集组件会将联机和暂停视为等价的状态　
加入群集服务器
如果一个服务器要加入现有群集，则它必须运行群集服务并且必须成功找到群集中的其它节点。在找到其它节点后，加入的服务器必须接受群集成员资格验证，并获得群集配置数据库的副本。加入现有群集的过程开始于Windows Server 2003 或 Windows 2000 Service Control Manager 在节点上启动群集服务之时。在启动过程中，群集服务会配置并装入该节点的本地数据设备。它并不会试图将共用的群集数据设备作为节点联机，因为现有群集可能正在使用这些设备。为了查找其它节点，会启动一个发现过程。当节点发现任何群集成员时，它将执行身份验证序列。个群集成员会对新加入者进行身份验证，并且在新服务器得到成功验证后返回成功状态。如果验证不成功（未能识别待加入节点的群集成员身份，或者它使用了无效的帐户密码），则加入群集的请求会被拒绝。 进行成功验证后，首先联机的群集节点会检查加入节点上的配置数据库副本。如果该副本已过时，对加入服务器进行验证的群集节点会为加入的服务器发送该数据库的更新副本。刚加入群集的节点在收到复制的数据库后，可以用它查找共享资源并根据需要将它们联机。 　　
脱离群集服务器　　
当节点关闭或群集服务被停止时，节点可能脱离群集。但当节点不执行群集操作（比如不向群集配置数据库提交更新）时，节点也可能被迫脱离（被逐出）群集。如果节点根据预先的计划脱离群集，它会向其它所有节点成员发送 ClusterExit 消息，通知它们它将脱离群集。该节点不等待任何响应会立即进行关闭资源和所有群集连接的操作。由于其余节点收到了退出消息，因此它们不会执行在节点意外失效或网络通讯停止时发生的重新分组过程以重新确立群集成员身份。

qq3250845

如今已进入高速发展的互联网时代，各种互联网的Web应用程序如雨后春笋般出现。那么作为一名Web应用开发人员，怎样去开发一款的Web应用程序呢？这个问题没有一个简单的答案，甚至那些教育机构都未必能清楚的知道。所以，像大多数在这个领域里的web应用开发人员一样，我们只是通过去做，去实验才学会了这些。没有人告诉我们如何去做，我们从给自己做点什么东西开始，学会如何开发web应用程序是在这个过程中的一个副产品。这是学习任何语言的一个非常有效的方法。
Web应用程序与网站之间的区别
首先，我要说明，开发一个web应用程序跟开发一个网站是不一样的。虽然在总体上有很大相似之处，但开发它们所需要的时间有巨大的差别。那究竟web应用程序和网站有什么不同呢？通常，维基百科能帮助我们解释这个问题，让我们来看看维基百科是如何定义应用软件的：
应用软件，通常也被称作应用，指的是专门为帮助用户去执行一个或多个相关特定任务而设计的计算机软件。企业软件，会计软件，办公套件，绘图软件，媒体播放器等都属于这种软件。
跟应用软件相对照的是系统软件和中间件，它们管理计算机效能，管理如何跟计算机集成，但通常这些工作并不会直接反映到使用户受益的任务执行上。举个例子，一个不是很恰当的实体类比，应用软件跟系统软件之间的关系好比一个电灯泡和一个发电厂之间的关系，发电厂(系统软件)只是产生电能，它自己没有任何真正的用途，除非利用一个电灯泡这样的应用工具才能为用户提供服务。
Web应用开发技术的步骤
Web应用开发过程
现在特征已经弄清楚了，我们可以开始定义开发一个web应用程序的整个过程了。当然，这依赖于工程的大小，过程中的某些步骤可能很小，在你的脑海里能完成这种工作，但把事情整个的了解一下总是有好处的。同时还有一点很重要的你要明白，这篇文章并不会对每个步骤进行深层次的描述。
步骤一：分析
开发一个web应用的步是分析你的需求。你此时应该定义出一个尽量周全的你的应用应该提供的功能清单。如果是你为一个客户做这些工作，你需要明白他们想要什么(要确保你们对方都知道对方在说些什么)。从你们的讨论中，你能总结出需求和软件规格。你即使是为自己开发，我也建议你把希望这个web应用能够做的功能写下来。
步骤二：设计
一旦你弄清楚了这个web应用需要做哪些事情，你可以开始设计了。这个步骤通常会反反复复进行很多次，每一次都把设计细化一些。你要做的是画出页面流程图(画在纸上，或使用软件工具，凭各自所好吧。我喜欢用纸，这样我可以做更快速的改变)。页面流程图通常是很抽象的黑白绘画，画出你将要实现的web应用的样子(你可以加一些色彩，但尽量保持简单)。
这个步骤能够让你知道你的应用最终会是个什么样子。跟37signals倡导的相反，我建议使用一些词语描述，适度细化。当我想到一个很好的想法时，或想到事情该如何做时，我会把它标注到纸上(例如，当点击这个按钮时应该使另外一个元素改变或隐藏，我会把这写在流程图上)。
当你对做出的草图满意后，你可以开始制作实体模型了。
实体模型仍然是些图案，但有色彩和细节。最终的实体模型看起来应该像你将要实现的web应用的一个截屏图。如果你为一个客户开发，他会看看这些东西，并给你他的认可。然而，很多人都喜欢跳过这一步(大多数都是非设计人员)，他们喜欢直接奔向网页原型。
原型是用HTML开发出来，使用CSS渲染(有时也是有Javascript)。页面布局要做出来，链接能够点，颜色，字体，字体大小要设定好(如果你做了实体模型，这个会很容易)。这一步非常的重要，因为这里所有的东西都能用于你最终的应用中。如果允许的话，在你的原型上做一些可用性测试，从长期的效果来看，这能使你避免大量的失误。
在这个步骤的，你基本上知道了你的web应用是如何组织到一起的了。登录页面有些什么，用户如何从主页转向到各个页面。
步骤三：实现 选择一个框架
现在我们已经知道了要去开发什么东西，那要把它做出来。这一部分的工作很多，你大部分的时间都要花在这个上面。你个要做的决定是如何着手，采用什么样的技术，什么框架。你有很多选择的余地，你需要选出一个适合你的。下面是一个最常用的框架的列表:
ASP.NET
PHP 上的任何一个流程的框架
Python with Django
Ruby on Rails
没有一个明确的标准说哪个框架。它们都各有不同，每个都有自己的长处。最重要的是你要知道它们任何一个都能让你开发出好用的web应用。
开发
一旦你知道了如何去开发，那要甩开臂膀开干了。这个开发工作可以看作有很多块，但说到底，这都是标准的编程活动了。在后台，你要创建类，对象，服务，过程，以及持久层来把这些对象保存到数据库中。后台是整个应用的核心，对任何应用来说，它跟普通的编程没有什么区别。接着是前台的开发，你现在编写的代码才是真正给用户使用的操作界面。你把后台的程序和原型界面集成到一起，把系统各部分集成到一起。你还可以把你在开发过程中想到的一些很炫的小功能用JavaScript实现。
再说一次，有很多种途径可以实现后台程序。建议你去读一读跟你选择的框架相关的资料，弄清楚如何实现这一部分的工作。通常，这些知识会跟面向对象编程有关，但有些框架正在慢慢的向领域驱动设计发展。
步骤四：打磨抛光
现在应用程序已经开发出来，各个独立的模块也集成到了一起。你需要通过测试来确保你在步骤一中定义的需求和软件规格是否被实现(这个问题在你开发的整个过程中都要记在脑中)。你要确保那些愚蠢的用户不能通过试图做一些你还没有实现的操作而把你的应用弄坏(参考白盒和黑盒测试)。你同时还要确保你的程序能够在各种浏览器里(希望不是IE6)都能正确的运行。
现在也是你做一些小的调整，改进你的应用程序给人的感觉的时候，让它趋于完美。
步骤五：发布和后续工作
这一步(但不是此完结)是发布你的应用，让用户能够真正使用它(如果这个应用是个公众开发的应用，别忘了做新闻宣传)。如果你愿意，先发布一个Beta版，这样只有一小部分用户能够发现你的应用里的大问题(因为你的程序里肯定会有bug)，他们会帮助你改进程序的质量。不要忙着增加功能，要专注于把你目前的程序变的稳固。
当经过了beta阶段，你的程序已经变得十分的稳固，听取用户反馈的意见，自己试用一下自己的应用，你可以开始思考如何使应用变的更好。找出不和谐的地方，消除掉。以后每次的迭代都要经过上面所说的五个步骤，但像我最初说的，你现在已经有了一个可以运行的应用程序，你很容易直接在心里完成这些步骤，直接奔向在代码里测试你的功能。
恭喜，你已经自豪的成为一个web应用开发的人员了。

qq3250845

服务器集群在设计上是由连同操作系统一起工作的组件构成的单独的、隔离的服务器的集合。这种设计避免了在服务器集群和操作系统之间引入复杂的处理系统。但为了实现集群功能，仍将要求对基础操作系统进行某些更改。这些更改包括：
支持动态地创建、产出网络名称和地址；
修改了文件系统，以便在磁盘驱动器卸载期间可以关闭打开的文件；
修改了输入输出（I/O）子系统，以便实现在多个节点之间共享磁盘和卷集。
如果抛开上述变化和其他细微修改不论，可以说集群功能建立在Windows Server 2003和Windows 2000操作系统的现有基础之上。
服务器集群的核心正是集群服务，该服务包括几个功能单元，它们是节点管理器、故障转移管理器、数据库管理器、全局更新管理器、检查点管理器、日志管理器、事件日志复制管理器以及备份/恢复管理器

qq3250845

设计Web应用程序时，有时需要在数据库中存放一些用户注册信息，如果没有设计任何保密措施，对于一些桌面数据库（如Acess等）而言，如果有人得到这个数据库文件，那么所有的用户资料都将会泄露。为了增加安全性，有必要对数据库中的用户资料进行加密，这样即使有人得到了整个数据库，如果没有解密算法，也不能查看到数据库中的用户注册信息。本实例将MD5加密用户名称和密码，如图20.6所示。
MD5加密解密技术
技术要点：
加密一般有两种：双向密码和单向加密。双向加密码是最常用的，它既能加密又能解密；单向加密只能对数据进行加密，不能对其解密，MD5加密是单向加密。
下面介绍MD5加密的方法。
MD5加密是根据指定的密码和哈希算法生成一个适合于存储在配置文件中的哈希密码。命名空间：System.Web.Security。
语法：
public static string HashPasswordForStoringInConfigFile
(
string password，
string passwordFormat
)
参数说明如下。
.passwprd:要进行哈希运算的密码。
.passwordFormat:要使用的哈希算法。passwordFormat是一个String，表示FormsAuth passwordFormat枚举值之一。
返回值：经过哈希运算的密码。
实现过程
（1）新建一个ASP.NET网站，命名为Ex20_06，Web页默认名为Default.aspx，用于登录页面。
（2）在Default.aspx中分别添加一个Table表格、2个TextBox控件及2个Button控件，分别用于布局Web页面、输入用户名称和密码、执行登录和清空命令。

qq3250845

对于Windows系统管理员来说，远程管理服务器的方式正在发生改变。10或15年前，我们还需要逐台部署第三方远程控制软件。而，自动化和集中化已成为主流。Windows Server 2012让这一切又向前迈进了一步，系统管理员可以不用登录到服务器的控制台可以远程集中管理。
对于那些经常要与服务器桌面进行交互的管理员来说，Windows Server 2012的五个服务器远程管理工具或许能让他们受益匪浅：
Windows Server 2012远程管理方式一：服务器管理器仪表板
服务器管理器已经不再是以前的Microsoft管理控制台（MMC）管理单元，它经过彻底的改写后，将多个服务器的管理整合到一个单一窗格中。磁贴的界面风格来自于Windows 8，但它又不完全是为了触控。这些磁贴，它们被分成很多图标放置在服务器的对象下方，可以将仪表盘和功能进行区分。
服务器管理器会自动确定安装在服务器上的角色，这样无需打开MMC管理单元，直接在一个控制台下管理打印服务器、DHCP服务器和域控制器。它可以将所有DNS服务器的健康状态整合到一张视图中。这些视图平铺在一起，让管理员对环境状态一目了然。
在这里，你可以快速查看服务器的性能和故障情况。当你点击一台服务器，可以立即看到这台服务器在过去24小时内的性能表现，事件日志中的记录以及实践分析器的结果。其上安装的所有角色和功能，以及各服务的状态也一并展现出来。相比以前通过MMC获取信息的方式，这简直是太方便了。
这其中也包含互动信息栏，可以设立实践分析器的扫描，以及进行事件查询或性能告警等。
Windows Server 2012远程管理方式二：建立服务器组
对于那些拥有多台服务器的公司，肯定希望按照服务器组进行划分，然后通过Windows Server 2012的服务器管理器进行远程管理。许多IT部门开始时都是使用活动目录中的组织结构来进行编组，但管理员往往会忽略这种模式，因为日常的管理与活动目录的组织模型并不一定相匹配。服务器组的创建方式是点击“管理”菜单，然后单击“创建服务器组”。
对于如何组织服务器组，可以按照功能、应用类型，地理位置甚至可以日期划分。这其实并不重要，重要的是它能够提高工作效率。
Windows Server 2012远程管理方式三：定位你的工具
在Windows Server 2012中常用的远程管理工具，都已经从“开始”菜单项移到了“服务器管理器”的工具菜单中。像“Active Directory用户和计算机”、“DNS”以及“IIS”等这些典型的管理工具都可以从屏幕右上角的服务器管理器菜单中找到。
简单地用鼠标右击服务器你便可以访问到与其相关的工具。例如，右键点击一台DNS服务器，会出现与DNS管理相关的菜单，比如打开DNS管理器。Hyper-V服务器是否也可以这样？答案是肯定的。Active Directory服务器也是如此。如果它是一个Windows服务器的角色，相关的工具会出现。
Windows Server 2012远程管理方式四：远程配置服务器
你不单单可以管理服务器现有的角色，也可以使用服务器管理器来部署服务器和服务。远程添加服务器角色的功能不但好看，而且好用。只要有一个带图形界面的服务器，不必使用命令行为那些远程的Server Core服务器添加和配置角色。服务器管理器甚至强大到可以在脱机的虚拟硬盘上执行这个功能。
但是有一点需要额外说明：对于群集服务器的角色和功能安装只能采用本地安装的方式，不能远程安装。
Windows Server 2012远程管理方式五：更强大的PowerShell
PowerShell v3原生是为Windows Server 2012设计的，远程自动运行也能保证全速。跟原来的PowerShell所不同的是，PowerShell v3的远程管理和远程访问都是默认开启的。使用命令Install-WindowsFeature所能起到的作用与使用服务器管理器对服务器进行远程安装和配置的效果完全相同。
在整个环境中即使不是所有的服务器都部署有正确版本的PowerShell，你也可以在其中的一台服务器上建立一个PowerShell Web访问以允许IIS作为网关来管理远程的服务器。这为用户营造了一个独立的运行在浏览器中的PowerShell环境。
对于远程管理，你还在犹豫什么？
远程管理、部署和快速访问代表了当今服务器环境管理的新标准，微软也不断地加快步伐使Windows Server 2012可以满足这些新环境的管理需求。当许多组织都开始搭建私有云环境的时候，他们不会乐意采用逐个RDP远程连接到控制台的管理方式，而是希望能够快速得到需要的信息并完成配置。另外，在Windows中这项功能是完全免费的，所以远程部署对于用户来说不会有任何额外的费用。

qq3250845

在安装Linux操作系统时，一些不必要的数据包和应用程序会在用户不注意的情况下自动安装。在本文中，我们将讨论如何将Linux系统中一些不必要的应用程序和服务禁用，以保护你的系统资源。

首先让我们来看看系统中正在运行哪些服务。使用以下命令：

Linux服务管理(关闭或禁用不需要的服务)

输出结果

Linux服务管理(关闭或禁用不需要的服务)

现在让我们使用下面的netstat命令快速浏览接受连接的进程（端口）。

Linux服务管理(关闭或禁用不需要的服务)

输出结果

Linux服务管理(关闭或禁用不需要的服务)

从上面的输出结果中，你会发现一些不需要在服务器上运行的应用程序，如：

1. smbd and nmbd

smbd和nmbd是Samba的后台进程。你真的需要在Windows或其他机器上输出smb分享吗？如果不是，为什么运行这些进程呢？

你可以在下一次机器启动时关闭开机启动设置，这样能安全地关闭或禁用这些进程。

2. Telnet

你需要通过互联网或者局域网进行适合文本形式的通讯吗？如果不是的话，在机器启动时关闭这个进程吧。

3. rlogin

你需要通过网络登录到另一个主机吗？如果不需要的话，那么在机器启动时关闭这个进程的开启启动功能。

4. rexec

远程进程执行rexec允许你在远程计算机上执行shell命令。如果你不需要在远程机器上执行shell命令，请关闭该进程。

5. FTP

你需要将一个主机上的文件通过网络转移到另一个主机上吗？如果不需要，你可以停止FTP服务。

6. automount

你需要自动挂载不同的文件系统，弹出网络文件系统吗？如果不是，为什么要运行这个进程，为什么要让这个应用程序占用你的资源呢？关闭它的自动启动功能吧。

7. named

你需要运行域名服务器（DNS）吗？如果不是，你应该关掉这个进程，释放你的资源。先关闭正在运行的进程，然后关闭开机启动设置。

8. lpd

lpd是打印机的后台进程。如果你不需要从服务器打印，该进程会消耗你的系统资源。

9. Inetd

你运行inetd服务吗？如果你正在运行独立应用程序，如ssh，ssh会使用其他独立的应用程序，比如Mysql、Apache等。如果你不需要inetd，在下次自动启动时关闭掉。

10. portmap

Portmap是一个开放网络计算远程过程调用（ONC RPC），启用后台进程rpc.portmap和rpcbind。如果这些进行运行，意味着你正在运行NFS服务器。如果你没有注意到NFS服务器运行的话，意味着你的系统资源正在消耗。

如何在Linux系统中杀死一个进程

可以使用“Kill PID”命令杀死一个在Linux中运行的进程。但是在运行Kill命令之前，我们必须了解进程的PID。例如，我想找“cupsd”进程的PID。

Linux服务管理(关闭或禁用不需要的服务)

那么“cupsd”进程的PID是1511。运行下面的命令杀死该PID。

Linux服务管理(关闭或禁用不需要的服务)

如何禁用Linux服务

对于红帽发行版如Fedora和CentOS，利用“chkconfig”脚本来启用和禁用Linux系统中运行的服务。　　

例如，在系统启动时禁用Apache web服务器。

Linux服务管理(关闭或禁用不需要的服务)

对于基于Debain的发行版如Ubuntu、Linux Mint和其他Debian发行版，使用一个叫做update-rc.d的脚本。

例如，在系统启用时使用下面的命令禁用Apache服务。这里“- f”选项代表强制性。

Linux服务管理(关闭或禁用不需要的服务)

做了这些变更之后，系统下次启动时不会再运行这些没有必要的进程，从而为我们节约了系统资源。服务器将会更实用、快速、安全。

qq3250845

Hadoop与Kubernetes就好像江湖里的两大绝世高手，一个是成名已久的长者，至今仍然名声远扬，一个则是初出茅庐的青涩少年，骨骼惊奇，不走寻常路，一出手便惊诧了整个武林。Hadoop与Kubernetes之间有很深的渊源，因为都出自IT豪门——Google，只不过，后者是亲儿子，正因为有大佬背书，所以Kubernetes一出山，江湖各路门派便都蜂拥而至，拥护称王。

不知道是因为Hadoop是干儿子的缘故还是因为“廉颇老矣”，总之，Hadoop朋友圈的后辈们如Spark、Storm等早都有了在Kubernetes上部署运行的各种资料和案例，但Hadoop却一直游离于Kubernetes体系之外，本文我们给出Hadoop在Kubernetes上的实践案例，以弥补这种缺憾。

Hadoop容器化的资料不少，但Hadoop部署在Kubernetes上的资料几乎没有，这主要是以下几个原因导致的：

第一， Hadoop集群重度依赖DNS机制，一些组件还使用了反向域名解析，以确定集群中的节点身份，这对Hadoop在Kubernetes上的建模和运行带来极大挑战，需要深入了解Hadoop集群工作原理并且精通Kubernetes，才能很好解决这一难题。
第二， Hadoop新的Map-Reduce计算框架Yarn的模型出现的比较晚，它的集群机制要比HDFS复杂，资料也相对较少，增加了Hadoop整体建模与迁移Kubernetes平台的难度。
第三， Hadoop与Kubernetes分别属于两个不同的领域，一个是传统的大数据领域，一个是新兴的容器与微服务架构领域，这两个领域之间交集本来很小，加之Hadoop最近几年已经失去焦点(这点从百度搜索关键词就能发现)，所以，没有多少人关注和研究Hadoop在Kubernetes的部署问题，也是情理之中的事情。
Hadoop 2.0其实是由两套完整的集群所组成，一个是基本的HDFS文件集群，一个是YARN资源调度集群，如下图所示：



因此在Kubernetes建模之前，我们需要分别对这两种集群的工作机制和运行原理做出深入的分析，下图是HDFS集群的架构图：

Hadoop 运行在 Kubernetes平台实践

我们看到，HDFS集群是由NameNode(Master节点)和Datanode(数据节点)等两类节点所组成，其中，客户端程序(Client)以及DataNode节点会访问NameNode，因此，NameNode节点需要建模为Kubernetes Service以提供服务，以下是对应的Service定义文件：

apiVersion: v1
kind: Service
metadata:
name: k8s-hadoop-master
spec:
type: NodePort
selector:
app: k8s-hadoop-master
ports:
- name: rpc
  port: 9000
  targetPort: 9000
- name: http
  port: 50070
  targetPort: 50070
  nodePort: 32007
其中，NameNode节点暴露2个服务端口：

9000端口用于内部IPC通信，主要用于获取文件的元数据
50070端口用于HTTP服务，为Hadoop 的Web管理使用
为了减少Hadoop镜像的数量，我们构建了一个镜像，并且通过容器的环境变量HADOOP_NODE_TYPE来区分不同的节点类型，从而启动不同的Hadoop组件，下面是镜像里的启动脚本startnode.sh的内容：

#!/usr/bin/env bash
sed -i "s/@HDFS_MASTER_SERVICE@/$HDFS_MASTER_SERVICE/g" $HADOOP_HOME/etc/hadoop/core-site.xml
sed -i "s/@HDOOP_YARN_MASTER@/$HDOOP_YARN_MASTER/g" $HADOOP_HOME/etc/hadoop/yarn-site.xml
yarn-master
HADOOP_NODE="${HADOOP_NODE_TYPE}"
if [ $HADOOP_NODE = "datanode" ]; then
    echo "Start DataNode ..."
    hdfs datanode  -regular

else
if [  $HADOOP_NODE = "namenode" ]; then
    echo "Start NameNode ..."
    hdfs namenode
else
    if [ $HADOOP_NODE = "resourceman" ]; then
        echo "Start Yarn Resource Manager ..."
        yarn resourcemanager
    else

         if [ $HADOOP_NODE = "yarnnode" ]; then
             echo "Start Yarn Resource Node  ..."
             yarn nodemanager   
         else               
            echo "not recoginized nodetype "
         fi
    fi
fi   

fi
我们注意到，启动命令里把Hadoop配置文件(core-site.xml与yarn-site.xml)中的HDFS Master节点地址用环境变量中的参数HDFS_MASTER_SERVICE来替换，YARN Master节点地址则用HDOOP_YARN_MASTER来替换。下图是Hadoop HDFS 2节点集群的完整建模示意图：

Hadoop 运行在 Kubernetes平台实践

图中的圆圈表示Pod，可以看到，Datanode并没有建模Kubernetes Service，而是建模为独立的Pod，这是因为Datanode并不直接被客户端所访问，因此无需建模Service。当Datanode运行在Pod容器里的时候，我们需要修改配置文件中的以下参数，取消DataNode节点所在主机的主机名(DNS)与对应IP地址的检查机制：

dfs.namenode.datanode.registration.ip-hostname-check=false
如果上述参数没有修改，就会出现DataNode集群“分裂”的假象，因为Pod的主机名无法对应Pod的IP地址，因此界面会显示2个节点，这两个节点都状态都为异常状态。

下面是HDFS Master节点Service对应的Pod定义：

apiVersion: v1
kind: Pod
metadata:
name: k8s-hadoop-master
labels:
app: k8s-hadoop-master
spec:
containers:
- name: k8s-hadoop-master
  image: kubeguide/hadoop
  imagePullPolicy: IfNotPresent
  ports:
    - containerPort: 9000
    - containerPort: 50070     
  env:
    - name: HADOOP_NODE_TYPE
      value: namenode
    - name: HDFS_MASTER_SERVICE
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDFS_MASTER_SERVICE
    - name: HDOOP_YARN_MASTER
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDOOP_YARN_MASTER
restartPolicy: Always
下面是HDFS的Datanode的节点定义(hadoop-datanode-1)：

apiVersion: v1
kind: Pod
metadata:
name: hadoop-datanode-1
labels:
  app: hadoop-datanode-1
spec:
containers:
- name: hadoop-datanode-1
  image: kubeguide/hadoop
  imagePullPolicy: IfNotPresent
  ports:
    - containerPort: 9000
    - containerPort: 50070     
  env:
    - name: HADOOP_NODE_TYPE
      value: datanode
    - name: HDFS_MASTER_SERVICE
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDFS_MASTER_SERVICE
    - name: HDOOP_YARN_MASTER
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDOOP_YARN_MASTER         
restartPolicy: Always
实际上，Datanode可以用DaemonSet方式在每个Kubernerntes节点上部署一个，在这里为了清晰起见，就没有用这个方式 定义。接下来，我们来看看Yarn框架如何建模，下图是Yarn框架的集群架构图：

Hadoop 运行在 Kubernetes平台实践

我们看到，Yarn集群中存在两种角色的节点：ResourceManager以及NodeManger，前者属于Yarn集群的头脑(Master)，后者是工作承载节点(Work Node)，这个架构虽然与HDFS很相似，但因为一个重要细节的差别，无法沿用HDFS的建模方式，这个细节就是Yarn集群中的ResourceManager要对NodeManger节点进行严格验证，即NodeManger节点的节点所在主机的主机名(DNS)与对应IP地址严格匹配，简单来说，就是要符合如下规则：

NodeManger建立TCP连接时所用的IP地址，必须是该节点主机名对应的IP地址，即主机DNS名称解析后返回节点的IP地址。

所以我们采用了Kubernetes里较为特殊的一种Service——Headless Service来解决这个问题，即为每个NodeManger节点建模一个Headless Service与对应的Pod，下面是一个ResourceManager与两个NodeManger节点所组成的Yarn集群的建模示意图：

Hadoop 运行在 Kubernetes平台实践

Headless Service的特殊之处在于这种Service没有分配Cluster IP，在Kuberntes DNS里Ping这种Service的名称时，会返回后面对应的Pod的IP地址，如果后面有多个Pod实例，则会随机轮询返回其中一个的Pod地址，我们用Headless Service建模NodeManger的时候，还有一个细节需要注意，即Pod的名字(容器的主机名)必须与对应的Headless Service的名字一样，这样一来，当运行在容器里的NodeManger进程向ResourceManager发起TCP连接的过程中会用到容器的主机名，而这个主机名恰好是NodeManger Service的服务名，而这个服务名解析出来的IP地址又刚好是容器的IP地址，这样一来，就巧妙的解决了Yarn集群的DNS限制问题。

下面以yarn-node-1为例，给出对应的Service与Pod的YAM文件，首先是yarn-node-1对应的Headless Service的YAM定义：

apiVersion: v1
kind: Service
metadata:
name: yarn-node-1
spec:
clusterIP: None
selector:
app: yarn-node-1
ports:
- port: 8040
注意到定义中“clusterIP:None”这句话，表明这是一个Headless Service，没有自己的Cluster IP地址，下面给出YAM文件定义：

apiVersion: v1
kind: Pod
metadata:
name: yarn-node-1
labels:
app: yarn-node-1
spec:
containers:
- name: yarn-node-1
  image: kubeguide/hadoop
  imagePullPolicy: IfNotPresent
  ports:
    - containerPort: 8040
    - containerPort: 8041   
    - containerPort: 8042         
  env:
    - name: HADOOP_NODE_TYPE
      value: yarnnode
    - name: HDFS_MASTER_SERVICE
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDFS_MASTER_SERVICE
    - name: HDOOP_YARN_MASTER
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDOOP_YARN_MASTER           
restartPolicy: Always
ResourceManager的YAML定义没有什么特殊的地方，其中Service定义如下：

apiVersion: v1
kind: Service
metadata:
name: ku8-yarn-master
spec:
type: NodePort
selector:
app: yarn-master
ports:
- name: "8030"        
   port: 8030
- name: "8031"      
   port: 8031
- name: "8032"
   port: 8032      
- name: http
   port: 8088
   targetPort: 8088
   nodePort: 32088
对应的Pod定义如下：

apiVersion: v1
kind: Pod
metadata:
name: yarn-master
labels:
app: yarn-master
spec:
containers:
- name: yarn-master
  image: kubeguide/hadoop
  imagePullPolicy: IfNotPresent
  ports:
    - containerPort: 9000
    - containerPort: 50070     
  env:
    - name: HADOOP_NODE_TYPE
      value: resourceman
    - name: HDFS_MASTER_SERVICE
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDFS_MASTER_SERVICE
    - name: HDOOP_YARN_MASTER
      valueFrom:
        configMapKeyRef:
          name: ku8-hadoop-conf
          key: HDOOP_YARN_MASTER           
restartPolicy: Always
目前这个方案，还遗留了一个问题有待解决：HDFS NameNode节点重启后的文件系统格式化问题，这个问题可以通过启动脚本来解决，即判断HDFS文件系统是否已经格式化过，如果没有，就启动时候执行格式化命令，否则跳过格式化命令。

安装完毕后，我们可以通过浏览器访问Hadoop的HDFS管理界面，点击主页上的Overview页签会显示我们熟悉的HDFS界面：

Hadoop 运行在 Kubernetes平台实践

切换到Datanodes页签，可以看到每个Datanodes的的信息以及当前状态：

Hadoop 运行在 Kubernetes平台实践

接下来，我们可以登录到NameNode所在的Pod里并执行HDSF命令进行功能性验证，下面的命令执行结果是建立一个HDFS目录，并且上传一个文件到此目录中：

root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -ls  /
root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -mkdir /leader-us
root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -ls /
Found 1 items
drwxr-xr-x   - root supergroup          0 2017-02-17 07:32 /leader-us
root@hadoop-master:/usr/local/hadoop/bin# hadoop fs -put hdfs.cmd /leader-us
然后，我们可以在HDFS管理界面中浏览HDFS文件系统，验证刚才的操作结果：

Hadoop 运行在 Kubernetes平台实践

接下来，我们再登录到hadoop-master对应的Pod上，启动一个Map-Reduce测试作业——wordcount，作业启动后，我们可以在Yarn的管理界面中看到作业的执行信息，如下图所示：

Hadoop 运行在 Kubernetes平台实践

当作业执行完成后，可以通过界面看到详细的统计信息，比如wordcount的执行结果如下图所示：

Hadoop 运行在 Kubernetes平台实践

最后，我们进行了裸机版Hadoop集群与Kubernetes之上的Hadoop集群的性能对比测试，测试环境为十台服务器组成的集群，具体参数如下：

硬件：

CPU：2*E5-2640v3-8Core
内存：16*16G DDR4
网卡：2*10GE多模光口
硬盘：12*3T SATA
软件：

BigCloud Enterprise Linux 7(GNU/Linux 3.10.0-514.el7.x86_64 x86_64)
Hadoop2.7.2
Kubernetes 1.7.4+ Calico V3.0.1
我们执行了以下这些标准测试项：

TestDFSIO：分布式系统读写测试
NNBench：NameNode测试
MRBench：MapReduce测试
WordCount：单词频率统计任务测试
TeraSort：TeraSort任务测试
综合测试下来，Hadoop跑在Kuberntes集群上时，性能有所下降，以TestDFSIO的测试为例，下面是Hadoop集群文件读取的性能测试对比：

Hadoop 运行在 Kubernetes平台实践

我们看到，Kubernetes集群上的文件读性能与物理机相比，下降了差不多30%左右，并且任务执行时间也增加不少，再来对比文件写入的性能，测试结果如下下图所示：

Hadoop 运行在 Kubernetes平台实践

我们看到，写文件性能的差距并不大，这里的主要原因是在测试过程中，HDFS写磁盘的速度远远低于读磁盘的速度，因此无法拉开差距。

之所以部署在Kuberntes上的Hadoop集群的性能会有所下降，主要一个原因是容器虚拟网络所带来的性能损耗，如果用Host Only模型，则两者之间的差距会进一步缩小，下图是TestDFSIO测试中Hadoop集群文件读取的性能测试对比：

Hadoop 运行在 Kubernetes平台实践

因此我们建议在生产环境中采用Host Only的网络模型，以提升Hadoop的集群性能。

攻下Hadoop在Kubernetes上的部署，并且在生产中加以验证，我们可以很自豪的说，现在没有什么能够难倒应用向Kubernetes的迁移的步伐，采用统一的PaaS构建企业的应用集群和大数据集群，实现资源的共享和服务的统一管理将会大大的提升企业的业务部署速度和管理的效率。

qq3250845

........................

qq3250845

抽象来说，将 Nginx 配置为 Web 服务器就是定义处理哪些 URLS 和如何处理这些URLS 对应的请求。具体来说，就是定义一些虚拟服务器（Virtual Servers），控制具有特定 IP 和域名的请求。

更具体的来说， Nginx 通过定义一系列 locations 来控制对 URIS 的选择。每一个 location 定义了对映射到自己的请求的处理场景：返回一个文件或者代理请求，或者根据不同的错误代码返回不同的错误页面。另外，根据 URI 的不同，请求也可以被重定向到其它 server 或者 location 。



设置虚拟服务器

listen：

Nginx 配置文件至少包含一个 server 命令 ，用来定义虚拟服务器。当请求到来时， Nginx 会首先选择一个虚拟服务器来处理该请求。

虚拟服务器定义在 http 上下文中的 server 中：

http { server { # Server configuration
}
}
注意： http 中可以定义多个 server

server 配置块使用 listen 命令监听本机 IP 和端口号（包括 Unix domain socket and path），支持 IPv4、IPv6，IPv6地址需要用方括号括起来：

server { listen 127.0.0.1:8080; # IPv4地址，8080端口

# listen [2001:3CA1:10F:1A:121B:0:0:10]:80; # IPv6地址，80端口

# listen [::]:80; # 听本机的所有IPv4与IPv6地址，80端口

# The rest of server configuration}

上述配置，如果不写端口号，默认使用80端口，如果不写 IP ，则监听本机所有 IP。

server_name：

如果多个 server 的 listen IP 和端口号一模一样， Nginx 通过请求头中的 Host

你真的了解如何将 Nginx 配置为Web服务器吗

与 server_name 定义的主机名进行比较，来选择合适的虚拟服务器处理请求：

server { listen 80;

server_name lufficc.com www.lufficc.com;

...

}
server_name 的参数可以为：

完整的主机名，如：api.lufficc.com 。
含有通配符（含有 *），如：*.lufficc.com 或 api.* 。
正则表达式，以 ~ 开头。
通配符只能在开头或结尾，而且只能与一个 . 相邻。www.*.example.org 和 w*.example.org均无效。 但是，可以使用正则表达式匹配这些名称，例如 ~^www..+.example.org$ 和~^w.*.example.org$ 。 而且 * 可以匹配多个部分。 名称 * .example.org 不仅匹配www.example.org，还匹配www.sub.example.org。

对于正则表达式：Nginx 使用的正则表达式与 Perl 编程语言（PCRE）使用的正则表达式兼容。 要使用正则表达式，且必须以 ~ 开头。

命名的正则表达式可以捕获变量，然后使用：

server { server_name ~^(www.)?(?<domain>.+)$; location / { root /sites/$domain;  
}  
}
小括号 () 之间匹配的内容，也可以在后面通过 $1 来引用，$2 表示的是前面第二个 () 里的内容。因此上述内容也可写为：

server { server_name ~^(www.)?(.+)$; location / { root /sites/$2;
}
}
一个 server_name 示例：

server { listen 80;
server_name api.lufficc.com *.lufficc.com;
...
}
同样，如果多个名称匹配 Host 头部， Nginx 采用下列顺序选择：

完整的主机名，如 api.lufficc.com。
最长的，且以 * 开头的通配名，如：*.lufficc.com。
最长的，且以 * 结尾的通配名，如：api.* 。
第一个匹配的正则表达式。（按照配置文件中的顺序）
即优先级：api.lufficc.com > *.lufficc.com > api.* > 正则。

如果 Host 头部不匹配任何一个 server_name ,Nginx 将请求路由到默认虚拟服务器。默认虚拟服务器是指：nginx.conf 文件中第一个 server 或者 显式用 default_server 声明：

server { server_name ~^(www.)?(.+)$; location / { root /sites/$2;
}
}
配置 location

URI 与 location 参数的匹配

当选择好 server 之后，Nginx 会根据 URIs 选择合适的 location 来决定代理请求或者返回文件。

location 指令接受两种类型的参数：

前缀字符串（路径名称）
正则表达式
对于前缀字符串参数， URIs 必须严格的以它开头。例如对于 /some/path/ 参数，可以匹配/some/path/document.html ，但是不匹配 /my-site/some/path，因为 /my-site/some/path 不以/some/path/ 开头。

location /some/path/ {  
...  
}
对于正则表达式，以 ~ 开头表示大小写敏感，以 ~* 开头表示大小写不敏感。注意路径中的 . 要写成 . 。例如一个匹配以 .html 或者 .htm 结尾的 URI 的 location：

location ~ .html? {
...
}
正则表达式的优先级大于前缀字符串。如果找到匹配的前缀字符串，仍继续搜索正则表达式，但如果前缀字符串以 ^~ 开头，则不再检查正则表达式。

具体的搜索匹配流程如下：

将 URI 与所有的前缀字符串进行比较。
= 修饰符表明 URI 必须与前缀字符串相等（不是开始，而是相等），如果找到，则搜索停止。
如果找到的最长前缀匹配字符串以 ^~ 开头，则不再搜索正则表达式是否匹配。
存储匹配的最长前缀字符串。
测试对比 URI 与正则表达式。
找到第一个匹配的正则表达式后停止。
如果没有正则表达式匹配，使用 4 存储的前缀字符串对应的 location。
= 修饰符拥有最高的优先级。如网站首页访问频繁，我们可以专门定义一个 location 来减少搜索匹配次数（因为搜索到 = 修饰的匹配的 location 将停止搜索），提高速度：

location = / {
...
}
静态文件和代理

location 也定义了如何处理匹配的请求：返回静态文件 或者 交给代理服务器处理。下面的例子中，第一个 location 返回 /data 目录中的静态文件，第二个 location 则将请求传递给https://lufficc.com 域名的服务器处理：

server { location /images/ { root /data;
} location / { proxy_pass https://lufficc.com;
}
}
root 指令定义了静态文件的根目录，并且和 URI 拼接形成最终的本地文件路径。如请求/images/example.png，则拼接后返回本地服务器文件 /data/images/example.png 。

proxy_pass 指令将请求传递到 URL 指向的代理服务器。让后将来自代理服务器的响应转发给客户端。 在上面的示例中，所有不以 /images / 开头的 URI 的请求都将传递给代理服务器处理。

比如我把 proxy_pass 设置为 https://www.baidu.com/，那么访问 http://search.lufficc.com/ 将得到百度首页一样的响应（页面）（感兴趣的童鞋可以自己试一试搜索功能，和百度没差别呢）：

server{

listen 80;

server_name search.lufficc.com;

location / {

proxy_pass https://www.baidu.com;

}

}
使用变量（Variables）

你可以使用变量来使 Nginx 在不同的请求下采用不同的处理方式。变量是在运行时计算的，用作指令的参数。 变量由 $ 开头的符号表示。 变量基于 Nginx 的状态定义信息，例如当前处理的请求的属性。

有很多预定义变量，例如核心的 HTTP 变量，你也可以使用 set，map 和 geo 指令定义自定义变量。 大多数变量在运行时计算，并包含与特定请求相关的信息。 例如，$remote_addr 包含客户端 IP 地址，$uri 保存当前URI值。

一些常用的变量如下：

server{  一个简单的应用就是从 http 重定向到 https 时带上路径信息：

... return 301 https://lufficc.com$request_uri;  
...  
}
返回特定状态码

如果你的网站上的一些资源永久移除了，最快最简洁的方法就是使用 return 指令直接返回：

location /wrong/url { return 404;  
}
return 的第一个参数是响应代码。可选的第二个参数可以是重定向（对应于代码301，302，303和307）的 URL 或在响应正文中返回的文本。 例如：

location /permanently/moved/url { return 301 http://www.example.com/moved/here;

}
return 指令可以包含在 location 和 server 上下文中：

server{
location / { return 404;
}
}
或者：

server{
... return 404;
location / {
...  
}  
}
错误处理

error_page 命令可以配置特定错误码的错误页面，或者重定向到其他的页面。下面的示例将在 404 错误发生时返回 /404.html 页面。

error_page 404 /404.html;

error_page 命令定义了如何处理错误，因此不会直接返回，而 return 确实会立即返回。当代理服务器或者 Nginx 处理时产生相应的错误的代码，均会返回相应的错误页面。

在下面的示例中，当 Nginx 找不到页面时，它将使用代码301替换代码404，并将客户端重定向到http://example.com/new/path.html 。 此配置很有用，比如当客户端仍尝试用旧的 URI 访问页面时，301代码通知浏览器页面已永久移除，并且需要自动替换为返回的新地址。

location /old/path.html { error_page 404 =301 http:/example.com/new/path.html;

}
重写 URIs

rewrite 指令可以多次修改请求的 URI。rewrite 的第一个参数是 URI需要匹配的正则表达式，第二个参数是将要替换的 URI。第三个参数可选，指示是否继续可以重写或者返回重定向代码（301或302）。例如：

location /users/ { rewrite ^/users/(.*)$ /show?user=$1 break;

}
您可以在 server 和 location 上下文中包括多个 rewrite 指令。 Nginx 按照它们发生的顺序一个一个地执行指令。 当选择 server 时，server 中的 rewrite 指令将执行一次。

在 Nginx 处理一组 rewrite 指令之后，它根据新的 URI 选择 location 。 如果所选 location 仍旧包含 rewrite 指令，它们将依次执行。 如果 URI 匹配所有，则在处理完所有定义的 rewrite 指令后，搜索新的 location 。

以下示例将 rewrite 指令与 return 指令结合使用：

server {

...

rewrite ^(/download/.*)/media/(.*)..*$ $1/mp3/$2.mp3 last;

rewrite ^(/download/.*)/audio/(.*)..*$ $1/mp3/$2.ra last; return 403;

...

}
诸如 /download/some/media/file 的 URI 被改为 /download/some/mp3/file.mp3 。 由于 last 标志，后续指令（第二个 rewrite 指令和 return 指令）被跳过，但 Nginx 继续以更改后的 URI 处理请求。 类似地，诸如 /download/some/audio/file 的 URI 被替换为/download/some/mp3/file.ra。 如果 URI 不匹配 rewrite 指令，Nginx 将403 错误代码返回给客户端。

last 与 break的区别是：

last ： 在当前 server 或 location 上下文中停止执行 rewrite 指令，但是 Nginx 继续搜索与重写的URI匹配的 location，并应用新 location 中的任何 rewrite 指令（这意味着 URI 可能再次改变）。
break ：停止当前上下文中 rewrite 指令的处理，并取消搜索与新 URI 匹配的 location。 不会执行新 location中的 rewrite 指令。
附录

常用正则

. ： 匹配除换行符以外的任意字符
? ： 重复0次或1次
+ ： 重复1次或更多次
*： 重复0次或更多次
d ：匹配数字
^ ： 匹配字符串的开始
$ ： 匹配字符串的介绍
{n} ： 重复n次
{n,} ： 重复n次或更多次
[c] ： 匹配单个字符c
[a-z]： 匹配a-z小写字母的任意一个
全局变量

$args ： #这个变量等于请求行中的参数，同$query_string
$content_length ： 请求头中的Content-length字段。
$content_type ： 请求头中的Content-Type字段。
$document_root ： 当前请求在root指令中指定的值。
$host ： 请求主机头字段，否则为服务器名称。
$http_user_agent ： 客户端agent信息
$http_cookie ： 客户端cookie信息
$limit_rate ： 这个变量可以限制连接速率。
$request_method ： 客户端请求的动作，通常为GET或POST。
$remote_addr ： 客户端的IP地址。
$remote_port ： 客户端的端口。
$remote_user ： 已经经过Auth Basic Module验证的用户名。
$request_filename ： 当前请求的文件路径，由root或alias指令与URI请求生成。
$scheme ： HTTP方法（如http，https）。
$server_protocol ： 请求使用的协议，通常是HTTP/1.0或HTTP/1.1。
$server_addr ： 服务器地址，在完成一次系统调用后可以确定这个值。
$server_name ： 服务器名称。
$server_port ： 请求到达服务器的端口号。
$request_uri ： 包含请求参数的原始URI，不包含主机名，如：/foo/bar.php?arg=baz。
$uri ： 不带请求参数的当前URI，$uri不包含主机名，如/foo/bar.html。
$document_uri ： 与$uri相同。
例如请求：http://localhost:88/test1/test2/test.php

$host：localhost
$server_port：88
$request_uri：http://localhost:88/test1/test2/test.php
$document_uri：/test1/test2/test.php
$document_root：/var/www/html
$request_filename：/var/www/html/test1/test2/test.php