标签：style blog http io 使用 ar strong 文件 数据
一、概述
Router组件在Cloud Foundry中是对所有进来的Request进行路由。
进入Router的request主要有两类：首先是来自VMCClient或者STS的管理型指令，这类request会被路由到AppLife Management组件，又叫CloudController组件去；第二类是外界对你所部署的apps访问的request，这部份requests会被路由到Appexecution，又或者叫做DEAs的组件去。
系统可以部署多个Routers共同处理进来的requests，但是Router上层的LoadBalance不在CloudFoundry的实现范围，CloudFoundry只保证所有的request是无状态的，这样就使上层均衡负载选择面非常非常大了，可以通过DNS做、也可以部署硬件的LoadBalancer、或者简单点弄台ngnix作负载均衡器，都是可行的。
二、组成架构
目前版本的Router组件是对nginx的一个简单封装。它包括ngnix和router.rb两部分，其中nginx利用套接字文件（.sock文件）进行输入输入，router.rb实现对nginx的逻辑封装。从整体的来看，Router组件的结构如下：
外界httpRequest进入Cloud Foundry服务器，nginx会首先接到request，nginx通过sock与router.rb进行交互(所以真正处理请求的是Router组件）。router.rb根据传入的url、用户名密码等，进行逻辑判断，到CloudController组件或者DEA组件取得数据并且通过与niginx连接的.sock文件返回。router.rb是对nginx进行了逻辑封装。熟悉CloudFoundry的朋友肯定知道，CloudFoundry给每一个app分配了一个url访问，如果直接使用VMware所托管的CloudFoundry.com的话，那你的app的url可能就是xxx.cloudfoundry.com，无论通过命令给你的app扩展了多少个instances，都是从这个url访问的，这里面的url转换路由就是由router.rb实现的。
注意：第二版的时候，因为ruby直接处理请求性能不行，换成了lua脚本来接收请求，再由ruby程序将结果返回。
标签：style blog http io 使用 ar strong 文件 数据
原文地址：http://blog.csdn.net/u010515761/article/details/39963737
