Pivotal使用HAProxy作为其访问入口，当然是允许使用其他负载均衡软件或硬件进行替换的。不过，基于怕麻烦和强迫症，个人还是用了HAProxy到最终的生产环境。为了满足特定的应用需求和可靠性需求，对负载均衡这一层做了一定的配置，本文通过四个案例共享这些经验。
为不同应用分配不同的HAProxy
Pivotal Cloud Foundry的配置界面中，HAProxy允许配置多个IP(同时需要在资源尺寸页配置相同个数的HAProxy虚拟机)，这样一个CF就拥有了多个入口。可以通过管理员的人脑，对运行在这套CF上不同应用按照负载和安全的考量，分配到不同的HAProxy上。具体实例如下：
假定为PCF配置了两个HAProxy(10.20.30.40和10.20.30.41)，在DNS上，默认将*.pcf.mydomain.com子域分配给了这个PCF，指向了10.20.30.40。此时，如果应用app1域名为app1.pcf.mydomain.com，则该应用的访问将通过 10.20.30.40进入PCF。
这时如果这个应用app1需要使用域名app1.mydomain.com，并且负载很大和/或可靠性要求高，则可以在DNS上将app1.mydomain.com指向10.20.30.41，然后cf create-domain org1 mydomain.com创建域名(如果这个域名整个CF都要用，那就用cf create-shared-domain)，然后用cf map-route app1 mydomain.com -n app1为这个应用增加一个新的域名。
此时，通过app1.mydomain.com和app1.pcf.mydomain.com都可以访问这一应用，但是前者通过10.20.30.41进入PCF，后者通过10.20.30.40进入PCF。
为同一HAProxy上的不同域名配置SSL证书并自动访问https
PCF可以生成个自签名的域名给分配给自己的子域，但实际生产中使用证书肯定不会是自签名的，而且多数也不会是整个子域的域名，而是单独的域名，还是针对前文的实例，增加如下需求：另一个应用app2与app1属于同一系统，需要使用域名 app2.mydomain.com，app1.mydomain.com和app2.mydomain.com均有各自的SSL证书，同时二者均要求禁止http访问。
此时可以将DNS上app2.mydomain.com指向10.20.30.41，然后登陆10.20.30.41这个HAProxy的OS(用户名为vcap，密码可以在Pivotal Operation Manager的界面上找到)，进行HAProxy配置。
对于自动跳转https的需求，可以通过修改/var/vcap/jobs/haproxy/config/haproxy.config里的http-in完成。
- frontend http-in
- mode http
- bind :80
- option httplog
- option forwardfor
- reqadd X-Forwarded-Proto:\ http
- acl is_app1_mydomain_com hdr(host) -i app1.mydomain.com
- redirect location https://app1.mydomain.com:443 if is_app1_mydomain_co
- acl is_app2_mydomain_com hdr(host) -i app2.mydomain.com
- redirect location https://app2.mydomain.com:443 if is_app2_mydomain_com
- default_backend http-routers
对于多个证书的需求，可以通过修改/var/vcap/jobs/haproxy/config/haproxy.config里的https-in完成。将需要的证书上传到这台HAProxy，并在配置文件中添加即可，证书文件支持的格式请参见/var/vcap/jobs/haproxy/config/cert.pem。
- frontend https-in
- mode http
- bind :443 ssl crt /var/vcap/jobs/haproxy/config/cert.pem crt /var/vcap/jobs/haproxy/config/app1.mydomain.com.pem crt /var/vcap/jobs/haproxy/config/app2.mydomain.com.pem
- option httplog
- option forwardfor
- option http-server-close
- reqadd X-Forwarded-Proto:\ https
- default_backend http-routers
#p#
多层负载均衡满足安全需求和业务需求
企业的安全及防火墙策略对PCF来说是个灾难，当然现在的版本已经有Availability Zone来覆盖这一需求，但是下面这种需求还是难以实现：PCF部署在生产网络，但是需要被互联网访问，安全策略仅允许DMZ网络对外提供服务，因此需要做个脱裤子放屁的事儿是PCF可以从internet访问。还以上例为基础，app1和app2均需要互联网访问（将定DMZ网络中存在可用的负载均衡设备50.60.70.100和50.60.70.101）：
首先获取一个DMZ网段的IP，如50.60.70.80，开通负载均衡设备50.60.70.100和50.60.70.101访问PCF的对外IP的10.20.30.41的80和443端口，将10.20.30.41的80和443端口在DMZ负载均衡设备上负载均衡为50.60.70.80的80和443，将50.60.70.80的80和443端口NAT成公网的80和443，并返回需要的域名（比如app1.bjsdns.mydomain.com、app2.bjsdns.mydomain.com等），在DNS中把app1.bjsdns.mydomain.com、app2.bjsdns.mydomain.com做别名成app1.mydomain.com和app2.mydomain.com，就大功告成了。
让CF与普通Tomcat应用服务一块工作
对于企业内部的私有PaaS来讲，PCF中最让人担心的技术就是PCF的运行环境架构（包含负载均衡和自动弹性）。下面的方案可以屏蔽使用互联网技术带来的新技术不确定性风险，使私有PaaS为实时业务系统提供服务成为可能。这个方案通过将应用服务负载均衡到IaaS资源，确保在PCF的整个运行环境框架出现问题时，可做到用户无感知的故障恢复。具体细节如下：
1、在PCF中（比如分配10个应用实例，假定应用名称为app1）和使用IaaS虚拟机单独部署的多个Tomcat节点（比如2个）中部署相同应用代码。
2、在PaaS中使用如下命令创建域（比如mydomain.com），创建应用域名（app1.mydomain.com），绑定应用域名（app1.mydomain.com绑定到应用app1）：
- cf create-domain org1 mydomain.com
- cf map-route app1 mydomain.com -n app1
3、在负载均衡设备中配置virtual service（比如50.60.70.80），其对应的real service为PaaS环境的入口IP（比如10.20.30.41）和其他使用IaaS虚拟机单独部署的多个Tomcat节点，单独Tomcat节点的权重为1，PaaS入口IP的权重为其为此应用分配的应用实例个数（10）。
4、在DNS中将应用域名（app1.mydomain.com）配置为负载均衡设备上的virtual service IP（50.60.70.80）。
5、当用户访问app1.mydomain.com，DNS将解析到负载均衡设备，负载均衡设备会根据策略和权重将请求负载均衡到单独的Tomcat或PaaS入口IP上，如果到了PaaS入口IP上，PaaS将根据客户端访问的域名在此进行解析，并根据策略将请求route到应用app1的10个应用实例上。
博文出处：http://blog.csdn.net/cloudguru/article/details/45054165
