一：关于Nginx：
Nginx 是什么玩意？
Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx，它的发音为“engine X”， 是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器．Nginx是由俄罗斯人 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发的，它已经在该站点运行超过两年半了。Igor Sysoev在建立的项目时,使用基于BSD许可。
据说他当初是F5的成员之一，英文主页：http://nginx.net 。
它的影响：
直到2007年4月，俄罗 斯大约有20%左右的虚拟主机是由nignx服务或代理的。Google在线安全博客中统计nginx服务或代理了大约所有Internet虚拟主机的4%。而netcraft的统计显示，nginx服务的主机在过去的一年里以四倍的速度增长。短短的几年里，它的排名已跃进第9。
它的特点：
1、Nginx以事件驱动的方式编写，所以有非常好的性能，同时也是一个非常高效的反向代理、负载平衡。其拥有匹配 Lighttpd的性能。
2、同时还没有Lighttpd的内存泄漏问题，而且Lighttpd的mod_proxy也有一些问题并且很久没有更新。
3、但是Nginx并不支持cgi方式运行，原因是可以减少因此带来的一些程序上的漏洞。执行PHP程序必须使用FastCGI方式来。
4、 nginx做为HTTP服务器，有以下几项基本特性：
1）处理静态文件，索引文件以及自动索引；打开文件描述符缓冲．
2）无缓存的反向代理加速，简单的负载均衡和容错．
3）astCGI，简单的负载均衡和容错．
4) 模块化的结构。包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter。如果由FastCGI或其它代理服务器处理单页中存在的多个SSI，则这项处理可以并行运行，而不需要相互等待。
5) 支持SSL 和 TLSSNI．
其他特点：
Nginx专为性能优化而开发，性能是其最重要的考量,实现上非常注重效率 。它支持内核Poll模型，能经受高负载的考验,有报告表明能支持高达 50,000个并发连接数。
Nginx具有很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速连接时，也很可能会导致服务器物理内存耗尽频繁交换，失去响应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显非常缓慢了。而Nginx采取了分阶段资源分配技术，使得它的CPU与内存占用率非常低。nginx官方表示保持10,000个没有活动的连接，它只占2.5M内存，所以类似DOS这样的攻击对nginx来说基本上是毫无用处的。就稳定性而言,nginx比lighthttpd更胜一筹。
Nginx支持热部署。它的启动特别容易, 并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下，对软件版本进行进行升级。
Nginx采用master-slave模型,能够充分利用SMP的优势，且能够减少工作进程在磁盘I/O的阻塞延迟。当采用select()/poll()调用时，还可以限制每个进程的连接数。
Nginx代码质量非常高，代码很规范，手法成熟， 模块扩展也很容易。特别值得一提的是强大的Upstream与Filter链。 Upstream为诸如reverse proxy,与其他服务器通信模块的编写奠定了很好的基础。而Filter链最酷的部分就是各个filter不必等待前一个filter执行完毕。它可以把前一个filter的输出做为当前filter的输入，这有点像Unix的管线。这意味着，一个模块可以开始压缩从后端服务器发送过来的请求，且可以在模块接收完后端服务器的整个请求之前把压缩流转向客户端。
Nginx采用了一些os提供的最新特性如对sendfile (Linux2.2+)，accept-filter (FreeBSD4.1+)，TCP_DEFER_ACCEPT (Linux 2.4+)的支持，从而大大提高了性能。
当然，nginx还很年轻，多多少少存在一些问题，比如：Nginx是俄罗斯人创建，目前文档方面还不是很完善．因为文档大多是俄语，所以文档方面这也是个障碍．尽管nignx的模块比较多，但它们还不够完善。对脚本的支持力度不够。
它的配置方法:
配置文件
worker_processes 1;
events {
worker_connections 1024;
}
http{
upstream myproject {
#这里指定多个源服务器，ip:端口,80端口（默认）
server 192.168.43.158:80;
server 192.168.41.167;
}
server {
listen 8080;
location / {
proxy_pass http://myproject;
}
}
}
nginx的负载均衡有哪些功能呢？
[list]
[*]如果后面的服务器其中一台坏了，它能自动识别并跳转另一台服务器，等它好了之后nginx可以马上识别
[*]服务器A和B，如果A的响应时间为3，B的响应时间为1，那么nginx会自动调整访问B的概率是A的3倍，真正做到负载均衡
[/list]
在这里还是想说说nginx的安装及运行
先到http://www.nginx.net/下载最新的源码包。
我下载到的是nginx-0.5.33.tar.gz
解压：tar zxvf nginx-0.5.33.tar.gz
接着：./configure
再接着：make
最后：make install
好的，安装完成了。我在make的时候报了个错，说HTTP Rewrite 模块 有问题，我就./configure --without-http_rewrite_module
然后再make,make install就可以了。
安装好了之后新建一个配置文件，把上面的配置文件内容拷进去，当然要修改你的IP，保存为比如 load_balance.conf
然后启动：
/usr/local/nginx/sbin/nginx -c load_balence.conf
如果上面的步骤走下来有问题的话，可以参考：
nginx的中文维基
http://wiki.codemongers.com/NginxChs
当然也可以到官方网站
www.nginx.net
http://www.nginx.com/
后话：最近本人调查发现，国内很多大网站也使用了。
接下文：
二、关于单点登录
最近做了调查，针对搜狐网的，记录下，
先看网上一哥们的
Code
问题描述：在一个比较复杂的网站环境下。有多个产品向外提供服务。每个产品下都有自己的用户登录界面。现在需要设计一个统一的登录界面。当用户在这个界面登录后就可以自由的使用各个产品和服务。同时意味着用户用一个帐号可以在不同服务里登录，另一方面就是在一个服务里面登录后可以无障碍的漫游到其他服务里面去。
实际应用：Sohu的Passport将focus.cn，17173.com，sogou.com，chinaren.com这四个域名下的产品全部整合在一起了。用户在这四个站点中任何一个地方都可以登录。当用户登录后可以自由的使用其他域名下的服务。现在很多网站上都有bbs blog album服务。这些服务一般也是自己维护自己的用户信息。当发展到一定时候，也需要一个Passport机制整合所有服务，使用户可以单点登录。
Sohu的实现方案
在http://passport.sohu.com/ 登录后 fiddler可以拦截到如下的返回信息：
由于passport.sohu.com的登录界面使用了iframe隐藏提交。所以页面没有看到刷新。隐藏的iframe把用户名和加密的password和其他信息发送给了passport.sohu.com。passport.sohu.com在Response中设置了成功登录的cookie。这个cookie可以证实这个用户成功登录了passport.sohu.com。
当用户在Passport成功登录后。客户端的Javascript根据成功登录的标志，操作iframe请求http://passport.sohu.com/sso/crossdomain_all.jsp?action=login 因为在同一个域名下，没有跨域，在这次请求中，上次成功登陆的cookie会被一并带着回去。服务器端检查到成功登录的cookie后会Render回一段同时登录多个站点的html。
这段html 要向4个地址发送请求。截至到现在都是在相同的Domain(passport.sohu.com)请求和返回，为真正的跨站点登录做准备，真正的跨站点登录还没有开始。下面passport.sohu.com通过sso/crossdomain.jsp 在服务器端进行Redirect 设置http head 为302进行跳转。跳转后在这个跳转后的域名下设置登录成功的cookie。这就是sohu实现跨站点登录的核心过程。下面是passport.sohu.com登录17173.com的过程。
1. 通过http://passport.sohu.com/sso/crossdomain_all.jsp?action=login Render回来的script <script type="text/javascript" src="http://passport.sohu.com/sso/crossdomain.jsp?action=login&domain=17173.com"></script> 请求同域下的http://passport.sohu.com/sso/crossdomain.jsp?action=login&domain=17173.com 这时passport.sohu.com下成功登录的cookie会被带回去。
2. 服务器看到成功登录的Cookie后。在服务器端计算出一个加密后的17173.com的登录Url，并Redirect到这个Url。
3. 17173.com从url的QueryString中取得信息。并在Response中设置Cookie。这个Cookie终于写到了17173.com下。而不是passport.sohu.com下。从而使得用户在17173.com下登录。其实用户在17173.com下手动登录也是写上同样的Cookie。以后用户再访问17173.com的页面时这个Cookie会被带回去。这就表示用户在17173.com下成功登录过了。
经过上面的步骤。用户在passport.sohu.com下登录的同时也在其他站点登录了。
在上面的过程中，最核心的技巧就是在指定的域下写入想要的Cookie：
1. Sohu使用了在同一个域名登录后通过再次请求这个域名下某个链接后，得到要登录站点的请求Url，通过javascript使隐藏的iframe请求要登录站点的Url，服务器端接到请求Redirect到要登录站点，然后通过Response写入Cookie，完成跨域名写Cookie的操作。这种写Cookie的方式，需要在跳转时对请求的QueryString进行加密。接受方需要对QueryString进行解密。
2. 这种做法在服务器端不需要特别的处理。只要写好相应Post操作 WriteCookie操作 Redirect操作 就可以了。在FireFox下就可以正常工作了。但是在IE下写Cookie的操作还不行，总是写不进去Cookie。需要在Response中加入一段特别的Header. P3P: CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"
这个Http Header 是P3P安全的要求。P3P的详解 http://www.oreilly.com.cn/book.php?bn=7-302-07170-5
微软对这个的解释：http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q323752
一个更加轻量级的方案
Sohu的通行证方案已经可以轻松的将各个域名下的用户都同步登录了。但是在实现上Sohu会让客户端的浏览器请求两次passport.sohu.com。在第二次得到一个登录多个站点的地址列表。在第三次请求时通过本域下的cookie进行身份验证，最后在服务器端跳转到一个含有加密Key的其它域名的Url地址，最终写入登录成功的Cookie。除去最开始的登录，要求用户在登录后再进行两次请求。并且服务器端要再做一次跳转。Sohu的做法可能由于Sohu服务器环境和数据存储的结构所决定。
其实总共只需一次登录请求，和每个域名下一次请求就可以完成多站点登录了，同时也不需要服务器端的跳转。
跨站点的请求由script的src发出。各个域名下的ssologin处理QueryString中的key，解密key，验证Key的合法性。在Response中写入登录成功的Cookie。完成跨站点Cookie的写入。
两种方案的比较
1. Sohu使用的登录方式，请求次数多，但是每次请求都有对应的验证过程，在服务端跳转时，重要的跳转Url地址在HttpHeader中，使得跳转地址更加安全，使得用户在跨域登录时非常安全可靠。
2. 轻量级方案的登录方式，请求次数少，没有服务器端的跳转，对服务器压力小。但是需要对Key进行加密解密。跳转的Url会在Response的Http Body中Render给用户。在使用轻量级方案的时候，最好在Key中加上时间戳，过期时间设置为3分钟。Key过期认为这个Key是非法Key，不在Response中写入登录成功的Cookie。
我想说的，解决单点登录，方法很多，搜狐是其中一种，也比较复杂了，服务器压力也大.........
目前遇到的系统整合，偶打算用cookie啦，跨库读数据，校验。。。。。
个人觉得比较实用，从成本，优化，技术实现等方面考虑吧。
（慢慢补充）