标签：mamicode cti 搭建集群 health 并且 处理 === 扩展 服务器
原文:IIS负载均衡目录
[========]
任何的负载均衡技术都要想办法建立某种一对多的映射机制: 一个请求的入口映射到多个处理请求的节点，从而实现分而治之（Divide and Conquer）。
这种映射机制使得多个物理存在对外体现为一个虚拟的整体，对服务的请求者屏蔽了内部的结构。
采用不同的机制建立映射关系，可以形成不同的负载均衡技术，常见的包括：
DNS轮询是最简单的负载均衡方式。以域名作为访问入口，通过配置多条DNS A记录使得请求可以分配到不同的服务器。
DNS轮询没有快速的健康检查机制，而且只支持WRR的调度策略导致负载很难“均衡”，通常用于要求不高的场景。 并且DNS轮询方式直接将服务器的真实地址暴露给用户，不利于服务器安全。
CDN（Content Delivery Network，内容分发网络）。通过发布机制将内容同步到大量的缓存节点，并在DNS服务器上进行扩展， 找到里用户最近的缓存节点作为服务提供节点。
因为很难自建大量的缓存节点，所以通常使用CDN运营商的服务。目前国内的服务商很少，而且按流量计费，价格也比较昂贵。
IP负载均衡是基于特定的TCP/IP技术实现的负载均衡。
IP负载均衡可以使用硬件设备，也可以使用软件实现。
硬件设备的主要产品：F5-BIG-IP-GTM（简称F5)
软件产品主要有：LVS、HAProxy、NginX
其中LVS、HAProxy可以工作在4-7层，NginX工作在7层。关于三者的简单对比，可以参考这里。
OSI（Open System Interconnection）是一个开放性的通信系统互连参考模型。
OSI的7层从上到下分别是： 7应用层、6表示层、5会话层、4传输层、3网络层、2数据链路层、1物理层；其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流。
微软与iis集成的反向代理Application Request Route配置使用简单。
https://docs.microsoft.com/en-us/iis/extensions/planning-for-arr/using-the-application-request-routing-module
安装 Microsoft Web 平台安装程序
https://www.iis.net/downloads/microsoft/web-platform-installer
运行，选择安装下面组件
Web Deploy
Applicaiton Request Router（应用程序请求路由）
Url Rewriter（Url重写）
使用Server Farms搭建集群
部署一个代理站点，修改应用程序池的闲置时间为0，
去掉回收的固定时间间隔
部署两个服务节点
每个服务器节点下面添加了一个文件1.html，用来进行下面的测试
新建一个Server Farm
添加服务器节点，一定要在点击Add前配置好端口号
配置路由规则，第一次创建完ServerFarm时可以选择自动创建路由规则，也可以自己添加URL重写规则
运行Health Test测试服务器节点是否正常
通过访问代理服务器来访问服务节点下的文件
服务节点测试通过
Load Balance 设置负载均衡算法和分发规则
Monitoring and Management
其特点是占有内存少，并发能力强。
有说Nginx针对静态html文件的性能才比较好。
http://nginx.org/
经过负载均衡服务器后，请求数据包的源地址会修改为负载均衡服务器的地址，使用X-Forwarded-For的方式获取客户端的真实IP地址。
ARR中配置反向代理，
后端代码中通过X-Forwarded-For请求头获取真实地址
var sourceAddress = Request.Headers["X-Forwarded-For"];
//得到ip+端口号的地址形式，10.98.0.228:51129标签：mamicode cti 搭建集群 health 并且 处理 === 扩展 服务器
原文地址：https://www.cnblogs.com/lonelyxmas/p/10903736.html
