openstack 之~keystone之网关协议

第一：静态页面和动态页面

上一篇博客介绍了HTTP后，咱们知道一个web server的本质就是

1. 浏览器发送一个HTTP请求；

2. 服务器收到请求，生成一个HTML文档；

3. 服务器把HTML文档做为HTTP响应的Body发送给浏览器；

4. 浏览器收到HTTP响应，从HTTP Body取出HTML文档并显示。

用户的请求的结果可分为静态页面和动态页面两种

静态页面：是实实在在保存在服务器上写死了的html代码，每一个网页都是一个独立的文件，全部的访问者看到的内容都同样

动态页面：动态的概念意味着变，程序中体现'变'的概念就是变量，于是在html代码中须要嵌入变量，变量的值的来源须要用一段代码动态生成，这样不一样的用户会提交不一样的数据给服务端，服务端分析用户提交过来的数据而后执行这段代码，动态生成值后赋值html中变量，而后返回html给用户，这样对每一个用户来讲收到的页面都是不同的。

第二：什么是Web Server

Web Service也叫XML Web Service WebService是一种能够接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通信技术。是:经过SOAP在Web上提供的软件服务，使用WSDL文件进行说明，并经过UDDI进行注册。

通俗来讲：用户上网的本质就是在本身这端启动socket client（浏览器），服务的启动socket server（web server）。基于http协议的学习咱们知道，web server主要是用来响应用户的http请求而后返回html页面给用户。

如今主流的web server：nginx，apache，tomcat等等

第三：什么是网关协议

 引言:

因web server好比apache只能处理静态请求，因此对于动态请求，你须要编写专门的程序来处理

随着互联网的发展，愈来愈多的用户数据须要永久保存下来，文件是能够永久保存，可是文件的数据处理性能过低，因而引入了数据库，并慢慢成为了网站大后端的主流

apache没法处理动态请求，因此咱们须要本身编写一个个的功能来处理这些动态请求（注意：这些动态请求有的须要查询数据库有的则不须要）

举例说明：

处理动态请求的伪代码，能够称之为web application，或者简web app
一：接收apache提交过来的用户请求，触发函数运行
二：链接数据库
三：操做数据库（增删改查）
四：根据获取的数据进行其余逻辑处理
五：返回给apache数据
六：关闭数据库
以下图：

问题一：编写web app时，须要深刻研究apache工做的协议HTTP，这会严重影响了开发效率。

咱们迫切须要在web server与web app之间定义一种标准，用来明细分工，web server对外提供一种标准，web app开发者只要遵循这个标准，那么后者就无需考虑web server究竟是如何实现的了而能够专一web app的开发，这个标准就是网关协议

问题二：针对apache这款web server定制的代码，换成了另外的web server你的程序没法重用

在web server与web app之间定义了标准，那么只要个人web app是遵循这个标准的，换另一个也遵循该标准的web server，一样能够运行

问题三：针对一种动态请求的代码实现，对于其余的动态请求呢，你仍然须要写重复的代码去处理

这里须要引入一个概念叫：web app开发框架(也称web 框架)

web app开发框架用来为web app开发者提供一套现成的开发工具与开发模式，web app开发者再也不须要写重复代码了，只须要使用某种现成的web开发框架，一些重复的功能就不用再去重复造轮子了，这极大的提升了开发效率

好比web app开发框架通常本事都是基于网关协议标准实现的，由于你用web app开发框架去开发web app，天然就是遵循某种网关协议标准的，你甚至连这个协议具体是什么都无需知道。

第四：网关协议CGI、FastCGI、WSGI、UWSGI

CGI

CGI 即通用网关接口(Common Gateway Interface)， 是一种服务器和后端可执行程序之间的交互标准，或者说是web app应用程序（CGI程序）与Web服务器之间的接口标准。

原理：最原始的服务器，简单到就是访问文件目录，每次的请求都是请求加载目录下的文件。好比文档放在/var/www/html 目录下，访问 http://domain/index.html 其实就是请求 /var/www/html/index.html 文件。

CGI 经过服务器脚本（或者二进制文件），扩展了这个基础的『访问过程』。它利用程序的标准输入输出流，完成 HTTP 通讯。每次请求的文本以标准输入流的形式进入服务器端的 CGI 程序，建立进程并执行，而后将运行结果经过进程的标准输出流输出做为响应。
eg：/usr/local/apache/htdocs/cgi-bin 是咱们的 CGI 目录，当请求了 CGI 目录里的文件的时候（好比访问 http://domain/cgi-bin/printenv.pl ），服务器并不会返回这个文件，而会运行这个程序，而后将生成的内容返回给客户端。因此理论上，任何有输入输出能力的语言均可以用来写 CGI。

CGI脚本工做原理：

1. 浏览器发送动态请求（经过HTML表单或者超连接）
2. 服务端接收该请求，调用CGI脚本，产生一个CGI进程来处理该动态请求，结果返回给服务器
3. 服务器将html返回给浏览器

CGI工做原理图：

优势
CGI 程序提供了不少静态网页没法实现的功能，好比加载数据、数据运算等等。早期的动态网页基本都是基于 CGI 实现的。

缺点
在 CGI 协议下，解析器的反复加载是性能低下的主要缘由。每一个发送到服务器的请求，都须要通过『启动进程、处理请求、结束进程』三个步骤，因此当访问量增大时，系统资源的开销也会增大，致使服务器性能降低甚至服务中断。
更甚至是，这种『一个请求一个进程』的模式意味着没有『状态』可言，致使不少资源没法复用，好比链接数据库、内存缓存、cpu消耗等等。

FastCGI：

FastCGI 是 CGI 的加强版本，用于减小 Server 与 CGI 应用之间的交互开销，从而使 Server能够同时处理更多的请求。

FastCGI与CGI 的 fork-and-execute 模式不一样的是，FastCGI 以 Daemon 的形式运行，在初始化的时候会启动一个 FastCGI Server 而后长驻内存，处理一系列的请求。

FastCGI是一个可伸缩地、高速地在HTTP server和动态脚本语言间通讯的接口。多数流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等，同时，FastCGI也被许多脚本语言所支持，其中就有PHP。

FastCGI是从CGI发展改进而来的。传统CGI接口方式的主要缺点是性能不好，由于每次HTTP服务器遇到动态程序时都须要从新启动脚本解析器来执行解析，而后结果被返回给HTTP服务器。这在处理高并发访问时，几乎是不可用的。FastCGI像是一个常驻(long-live)型的CGI，它能够一直执行着，只要激活后，不会每次都要花费时间去fork一次(这是CGI最为人诟病的fork-and-execute 模式)。CGI 就是所谓的短生存期应用程序，FastCGI 就是所谓的长生存期应用程序。因为 FastCGI 程序并不须要不断的产生新进程，能够大大下降服务器的压力而且产生较高的应用效率。它的速度效率最少要比CGI 技术提升 5 倍以上。它还支持分布式的运算, 即 FastCGI 程序能够在网站服务器之外的主机上执行而且接受来自其它网站服务器来的请求。
FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并所以得到较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要缘由，若是CGI解释器保持在内存中并接受FastCGI进程管理器调度，则能够提供良好的性能、伸缩性、Fail-Over特性等等。FastCGI接口方式采用C/S结构，能够将HTTP服务器和脚本解析服务器分开，同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HTTP服务器每次遇到动态程序时，能够将其直接交付给FastCGI进程来执行，而后将获得的结果返回给浏览器。这种方式可让HTTP服务器专注地处理静态请求或者将动态脚本服务器的结果返回给客户端，这在很大程度上提升了整个应用系统的性能。

FastCGI的工做流程:

Web Server启动时载入FastCGI进程管理器（PHP-CGI或者PHP-FPM或者spawn-cgi)
FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的链接。
当客户端请求到达Web Server时，FastCGI进程管理器选择并链接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
FastCGI子进程完成处理后将标准输出和错误信息从同一链接返回Web Server。当FastCGI子进程关闭链接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个链接。 在CGI模式中，php-cgi在此便退出。

优势

除了继承 CGI 原有的优势以外， FastCGI 还有如下特色：

• 业务分离：FastCGI 后端和 Web Server 运行在不一样的进程中，后端的故障不会致使 Web Server 中止服务。
• 分布式计算：因为 FastCGI 服务器是能够独立运行的，因此 FastCGI 程序能够在服务器之外的主机上执行，而且接受来自其它服务器的请求。
• 多个可扩展角色：在 FastCGI 中，程序被赋予明确的角色，例如响应器角色、认证器角色、过滤器角色等等。

举例说明fastcgi工做原理：（依据nginx为例）

Nginx+FastCGI 的工做流程是这样的：

• 初始化 FastCGI 进程管理器，启动主进程和多个 CGI 子进程。主进程主要是管理子进程，同时还须要监听端口（例如9000端口）；子进程则是处于等待链接的状态。
• 当请求到达服务器时，Nginx 经过 location 指令，将请求（例如以 php 为后缀的文件）分配到指定端口（例如9000端口）来处理。
• FastCGI 进程管理器选择并链接到一个子进程，服务器将环境变量和标准输入发送给子进程。
• 子进程接受请求并完成处理后，将标准输出和错误信息从同一链接返回给服务器。
• 子进程关闭链接，继续等待下一个请求。

工做原理图：

 

PHP-CGI是PHP自带的FastCGI管理器。PHP-CGI的不足：
php-cgi变动php.ini配置后需重启php-cgi才能让新的php-ini生效，不能够平滑重启
直接杀死php-cgi进程php就不能运行了。(PHP-FPM和Spawn-FCGI就没有这个问题,守护进程会平滑重新生成新的子进程。）

Spawn-FCGI是一个通用的FastCGI管理服务器，它是lighttpd中的一部份，不少人都用Lighttpd的Spawn-FCGI进行FastCGI模式下的管理工做，不过有很多缺点。而PHP-FPM的出现多少缓解了一些问题，但PHP-FPM有个缺点就是要从新编译，这对于一些已经运行的环境可能有不小的风险)，在php 5.3.3中能够直接使用PHP-FPM了。Spawn-FCGI的代码不多，所有才630行，用c语言编写，最近一次提交是5年前。代码主页：https://github.com/lighttpd/spawn-fcgi
Spawn-FCGI代码分析以下：
1.spawn-fcgi 首先create socket,bind,listen 3步建立服务器socket,(把这个socket叫作 fcgi_fd)
2.用dup2，把fcgi_fd 交换给 FCGI_LISTENSOCK_FILENO （FCGI_LISTENSOCK_FILENO数值上等于0，这是fastcgi协议当中指定用来listen的socket id）
3.执行execl ,replaces the current process image with a new process image. process image 进程在运行空间的代码段
很显然，Spawn-FCGI也是 pre-fork 模型，只是用了上古C语言编写，充满了N多 unix下暗黑编程技巧。
Spawn-FCGI功能很单一：
1.只管fork进程，子进程挂了，主进程仅仅log记录一次，根本不会从新fork。在2009年一段时间内，我曾经用spawn-fcgi部署php-cgi，当跑一段时间就会全挂掉，只能用crontab定时重启spawn-fcgi
不负责子进程中的网络IO，把socket放到指定位置就完了，接下来的事情由被spawn的程序处理
2.Spawn-FCGI是一个很早期的程序，瞻仰一下便可。另外有：1996年的一段代码:http://www.fastcgi.com/om_archive/kit/cgi-fcgi/cgi-fcgi.c，和spawn-fcgi一个风格

PHP-FPM是一个PHP FastCGI管理器，是只用于PHP的,能够在 http://php-fpm.org/download下载获得。PHP-FPM实际上是PHP源代码的一个补丁，旨在将FastCGI进程管理整合进PHP包中。必须将它patch到你的PHP源代码中，在编译安装PHP后才可使用。FPM（FastCGI 进程管理器）用于替换 PHP-CGI 的大部分附加功能，对于高负载网站是很是有用的。它的功能包括：
1.支持平滑中止/启动的高级进程管理功能；
2.能够工做于不一样的 uid/gid/chroot 环境下，并监听不一样的端口和使用不一样的 php.ini 配置文件（可取代 safe_mode 的设置）；
3.stdout 和 stderr 日志记录;
4.在发生意外状况的时候可以从新启动并缓存被破坏的 opcode;
5.文件上传优化支持;
6.“慢日志” – 记录脚本（不只记录文件名，还记录 PHP backtrace 信息，可使用 ptrace或者相似工具读取和分析远程进程的运行数据）运行所致使的异常缓慢;
7.fastcgi_finish_request() – 特殊功能：用于在请求完成和刷新数据后，继续在后台执行耗时的工做（录入视频转换、统计处理等）；
8.动态／静态子进程产生；
9.基本 SAPI 运行状态信息（相似Apache的 mod_status）；
10.基于 php.ini 的配置文件。

WSGI:

 什么是WSGI？

Web服务器网关接口（Python Web Server Gateway Interface，缩写为WSGI）是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口，最初是为 Python 量身定作。

自从WSGI被开发出来之后，许多其它语言中也出现了相似接口。WSGI是做为Web服务器与Web应用程序或应用框架之间的一种低级别的接口，以提高可移植Web应用开发的共同点。WSGI是基于现存的CGI标准而设计的。

有了WSGI，你就不用去考虑，服务器程序的具体实现，应用程序得到了很好的适用性。好比一个云平台提供了对 WSGI 接口的支持，那么，只要应用是基于 WSGI 的，就能够直接跑起来。其实keystone就是一款python开发的基于WSGI标准的app。

 

什么是WSGI中间件？

基于WSGI 的设计哲学，咱们能够写一些对 server 和 application 都兼容的模块，即WSGI中间件（middleware）。所谓的 WSGI 中间件同时实现了API的两方，所以能够在WSGI服务和WSGI应用之间起调解做用：从WSGI服务器的角度来讲，中间件扮演应用程序，而从应用程序的角度来讲，中间件扮演服务器。

 

WSGI中间件的功能与好处？

WSGI中间件能够完成好比缓存、字符编码转换、根据 url 作应用 routing 等功能。

这种设计模式，是 WSGI 下降了 server 和 application 耦合度以后的产物，同时，它从另外一个角度大大提高了设计的灵活性。

 

WSGI的处理模式

WSGI将 web 组件分为三类： web服务器，web中间件,web应用程序

wsgi基本处理模式为 ： WSGI Server -> (WSGI Middleware)* -> WSGI Application 。

在处理一个WSGI请求时，服务器会为应用程序提供环境资讯及一个回呼函数（Callback Function）。当应用程序完成处理请求后，透过前述的回呼函数，将结果回传给服务器。

 

wsgi server能够理解为一个符合wsgi规范的web server，接收request请求，封装一系列环境变量，按照wsgi规范调用注册的wsgi app，最后将response返回给客户端。文字很难解释清楚wsgi server究竟是什么东西，以及作些什么事情，最直观的方式仍是看wsgi server的实现代码。以python自带的wsgiref为例，wsgiref是按照wsgi规范实现的一个简单wsgi server。它的代码也不复杂。

1. 服务器建立socket，监听端口，等待客户端链接。
2. 当有请求来时，服务器解析客户端信息放到环境变量environ中，并调用绑定的handler来处理请求。
3. handler解析这个http请求，将请求信息例如method，path等放到environ中。
4. wsgi handler再将一些服务器端信息也放到environ中，最后服务器信息，客户端信息，本次请求信息所有都保存到了环境变量environ中。
5. wsgi handler 调用注册的wsgi app，并将environ和回调函数传给wsgi app
6. wsgi app 将reponse header/status/body 回传给wsgi handler
7. 最终handler仍是经过socket将response信息塞回给客户端。

中间件：

Middleware 是一个比较特殊的存在，它是夹在两者之间的，对于 Server 端而言它是个 Application ，而对于 Application 而言它就是 Server 端。

它能够实现如下功能：

• 重写环境变量，根据目标 URL，将请求消息路由到不一样的应用对象。
• 容许在一个进程中同时运行多个应用程序或应用框架。
• 负载均衡和远程处理，经过在网络上转发请求和响应消息。
• 进行内容后处理，例如应用 XSLT 样式表。

优势

WSGI 将请求的工做经过异步回调进行拆解，能够很方便的在一个线程空间里同时处理多个请求。

另外，方便进行负载均衡和请求转发，不会形成后端应用阻塞。

 

Application

Application 会处理请求并经过回调函数将结果返回给 Server。

和 Serve 对应，一个标准的 Application 接受两个参数：

• environ：一个包含全部 HTTP 请求信息的 dict 对象
• start_response：一个发送 HTTP 响应的函数

Server

Server 端从规定的输入中获取 Request 数据，而后把环境变量（environ）和回调函数（start_response）传给 Application 

 

uWSGI

uWSGI 项目旨在为部署分布式集群的网络应用开发一套完整的解决方案。uWSGI主要面向web及其标准服务，已经成功的应用于多种不一样的语言。因为uWSGI的可扩展架构，它可以被无限制的扩展用来支持更多的平台和语言。目前，你可使用C，C++和Objective-C来编写插件。项目名称中的“WSGI”是为了向同名的Python Web标准表示感谢，由于WSGI为该项目开发了第一个插件。uWSGI是一个Web服务器，它实现了WSGI协议、uwsgi、http等协议。uWSGI，既不用wsgi协议也不用FastCGI协议，而是自创了一个uwsgi的协议，uwsgi协议是一个uWSGI服务器自有的协议，它用于定义传输信息的类型（type of information），每个uwsgi packet前4byte为传输信息类型描述，它与WSGI相比是两样东西。听说该协议大约是fcgi协议的10倍那么快。

1. uWSGI的主要特色以下：
2. 超快的性能。
3. 低内存占用（实测为apache2的mod_wsgi的一半左右）。
4. 多app管理。
5. 详尽的日志功能（能够用来分析app性能和瓶颈）。
6. 高度可定制（内存大小限制，服务必定次数后重启等）。

第五：网关协议与keystone

keystone本质就是python开发的一款基于wsgi的app，社区提倡的部署方法：

apache(wsgi)+keystone

nginx(uwsgi)+keystone