IIS负载均衡-Application Request Route详解第四篇:使用ARR实现三层部署架构

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
简介:
IIS负载均衡-Application Request Route详解第四篇:使用ARR实现三层部署架构
 
系列文章链接:
 
 
 
               本篇的主要目的是带领大家一起来使用ARR来实现一个三层部署架构。这里的三层部署架构主要是由:服务层,应用程序服务器层已经数据层实现。如下图所示:
 
20120330224630.png
 
           每次一提到“层”这个字的时候,似乎感觉这个字特别的惹火。很多朋友开始讨论起来,于是很多的见解和理解就出来了:有人说:架构就是分层;三层就是指:显示层,业务层,数据访问层…
               不管上述的理解和争论对错与否,这里不会对这些理论和概念进行过多的阐释,这里有一点提到的就是:不要将物理层Tier和逻辑层Layer混在一起讲,或者说,不要将应用程序的逻辑层与物理的部署层混为一谈!
 
               注:在自己的学习和工作的经历中有这样的感觉:很多时候,所学的东西会搅在一起,并且甚至感觉他们相互矛盾,还会颠覆自己之前很多的理解和看法,有时候确实感觉非常痛苦,但是也是像是凤凰的重生。其实这不是什么坏事,知识和经验就是在这过程中,不断的思考,总结,提炼出来的!其实到后来大家就可以发现:我们没有必要死扣一些概念,什么层啊,模式,都不是关键,锻炼出一种思维才是最有价值的。
              
我们这里讲的是物理层的部署。
正如之前一样,我们来做一些准备工作:
    1. 准备三台服务器(可以用虚拟机),其中一台用来处理对静态内容的请求,例如图片,脚本,html页面等,我们把这一台服务器放在第一层。
    2. 再用一台服务器放在第二层,作用应用程序服务器,用来处理动态内容的请求。
    3. 另外一台服务器用来部署数据库。
另外,我也把三台服务器的相关配置说明一下:
    1. 三台服务器安装了Win Server 2008和IIS
    2. 在那台处理静态文件的服务器上,我们安装ARR,也就说,此时这一台服务器做两件事情:负责转发请求;处理对静态文件的请求。
第一步:准备工作
               一般而言,我们判断是否是对静态文件进行请求,主要是通过检查请求的中是否包含文件的扩展名,例如.js,.png等。当然,在一些情况下,我们还以动态的方式来对静态文件的请求进行处理,例如,我们站点中写了一个类似FileHandler的HttpHandler,然后通过类似的www.agilesharp.com/file?fileid=xxxxx的方式来 处理所有对文件的请求。这两种方式各有优缺点和各自的用途,我们这里不做讨论。
 
               很多时候,我们在静态文件放在站点的文件夹中,例如/images/,/css/,/js/等。下面,我们开始演示,我们为了确认对静态文件的请求是由安装了ARR所在的服务器处理的,我们分别在三服务器的站点中放置三张名字一样但是内容不同的图片,如下:
 
20120330224708.png
 
               其他服务器上面的站点结果和这个类似,只是把图片的内容改为了“安捷雨希“而已。
 
第二步:在ARR中配置对静态文件的请求
 
               我们进行这一步操作的主要目的就是:使得ARR所在的服务器来处理所有对站点静态文件的请求(为了起到演示作用,这里对静态文件的请求,我们不会包括html的文件)。
 
               下面,我们就开始操作:
    1. 启动IIS
    2. 创建一个Server Farm,并且添加两台服务器,如图所示:
 
20120330224815.png
 
 
        这个205服务器就是我们安装了ARR的服务器,因为此时我的demo站点部署在8080端口,所以这里要开启“Advance setting“。
        再添加第二台服务器,其上的站点是部署在80端口。
 
        添加的结果就如下:
 
20120330224844.png
   
 
大家到这里就可能有点纳闷了:怎么只是添加了两台服务器呢,不是准备了三台服务器吗?
       理由很简单,有一台服务器是作为数据库服务器,而不是作为http请求处理的服务器(换句话说,http请求不会发送到数据库服务器上去),并且数据库服务器是我们在应用程序中通过连接字符串来连接的。
       
               在我还没有配置Server Farm之前,我分别在两台服务器上浏览了站点:http://localhost:8080/images/logo.png,此时看到的结果如下:
 
20120330224950.png
 
 
               从图中可以看到,我请求logo.png的时候,是应用程序的服务器(没有安装ARR的那个服务器)处理了这个请求。
               下面我们开始配置。
1. 选中创建的Server Farm
2. 选中“Routing Rules“,如下:
 
20120330225135.png
 
3. 双击“Routing Rules“,如下:
 
20120330225212.png
 
 
        主要注意图中标红的两个地方:第一个是配置哪些扩展名的文件不转发请求。在图中,我们配置了*.png,就说明,如果ARR客户端要请求.png文件,那么ARR就不将这个请求转发给Server Farm中的其他服务器,而是有本机直接处理。
 
        配置好了之后,我们就点击“Apply“,然后再次运行浏览器,来看效果。
 
20120330225248.png
 
 
        大家看到上面的图,右边图是我在ARR所在的服务器发送请求得到的结果,而左边是我直接在应用程序服务器上面查看图片。
 
还记得在之前没有配置的时候,我在ARR服务器上面发送请求的时候,看到的是“安捷雨希“,说明ARR转发了对png文件的请求;而当我们配置之后,此时ARR就不在转发这个请求,而是自己处理,所以我们看到了”agilesharp“的图片。
 
               这里,依然给大家留一个作业:大家可以把对html文件的请求也不转发,看看效果!
























本文转自yanyangtian51CTO博客,原文链接:http://blog.51cto.com/yanyangtian/822057  ,如需转载请自行联系原作者


相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
2月前
|
负载均衡 Java 持续交付
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
104 7
|
2月前
|
存储 负载均衡 监控
如何利用Go语言的高效性、并发支持、简洁性和跨平台性等优势,通过合理设计架构、实现负载均衡、构建容错机制、建立监控体系、优化数据存储及实施服务治理等步骤,打造稳定可靠的服务架构。
在数字化时代,构建高可靠性服务架构至关重要。本文探讨了如何利用Go语言的高效性、并发支持、简洁性和跨平台性等优势,通过合理设计架构、实现负载均衡、构建容错机制、建立监控体系、优化数据存储及实施服务治理等步骤,打造稳定可靠的服务架构。
52 1
|
5月前
|
消息中间件 负载均衡 Kafka
Kafka 实现负载均衡与故障转移:深入分析 Kafka 的架构特点与实践
【8月更文挑战第24天】Apache Kafka是一款专为实时数据处理和流传输设计的高性能消息系统。其核心设计注重高吞吐量、低延迟与可扩展性,并具备出色的容错能力。Kafka采用分布式日志概念,通过数据分区及副本机制确保数据可靠性和持久性。系统包含Producer(消息生产者)、Consumer(消息消费者)和Broker(消息服务器)三大组件。Kafka利用独特的分区机制实现负载均衡,每个Topic可以被划分为多个分区,每个分区可以被复制到多个Broker上,确保数据的高可用性和可靠性。
149 2
|
5月前
|
C++
【Azure云服务 Cloud Service】如何在部署云服务Cloud Service时候通过启动任务Start Task来配置IIS (如开启ARR)
【Azure云服务 Cloud Service】如何在部署云服务Cloud Service时候通过启动任务Start Task来配置IIS (如开启ARR)
|
6月前
|
负载均衡 监控 Kubernetes
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
Service Mesh 是一种用于处理服务间通信的基础设施层,它通常与微服务架构一起使用,以提供诸如服务发现、负载均衡、熔断、监控、追踪和安全性等功能。
|
6月前
|
负载均衡 安全 Cloud Native
云上负载均衡:构建高可用、高性能的网络应用架构
与云原生技术深度融合:随着云原生技术的普及和发展未来的云上负载均衡将更加紧密地与云原生技术相结合。例如与Kubernetes等容器编排平台集成实现自动化的服务发现和路由管理;与Serverless架构结合提供无缝的流量接入和请求处理能力。 安全性能提升:面对日益严峻的网络安全威胁云上负载均衡将更加注重安全性能的提升。通过引入加密传输、访问控制、DDoS防护等安全措施确保网络流量的安全性和隐私性;同时还将建立完善的安全监控和应急响应机制以应对各种安全事件和突发事件。 支持多协议和多场景:未来的云上负载均衡将支持更多种类的网络协议和应用场景以满足不同用户和业务的需求。例如支持HTTP/2、
304 0
|
7月前
|
存储 负载均衡 应用服务中间件
Web架构&OSS存储&负载均衡&CDN加速&反向代理&WAF防护
Web架构&OSS存储&负载均衡&CDN加速&反向代理&WAF防护
127 1
|
8月前
|
Kubernetes 负载均衡 应用服务中间件
k8s 二进制安装 优化架构之 部署负载均衡,加入master02
k8s 二进制安装 优化架构之 部署负载均衡,加入master02
|
8月前
|
缓存 负载均衡 监控
探索分布式系统演进之路:从负载均衡到微服务架构
小米分享了分布式系统的发展,从早期的负载均衡(入口级、网关和客户端)到微服务架构的演进。微服务实现服务解耦,增强系统弹性,但带来了新的挑战。为优化数据库性能,实施了主备读写分离、全文搜索引擎、缓存集群等措施。通过微服务治理,如服务注册、动态配置、灰度发布等,提升了系统稳定性和可靠性。未来将继续优化分布式系统,提供更好的服务体验。关注公众号“软件求生”了解更多。
119 6
|
8月前
|
负载均衡 应用服务中间件 nginx
服务器架构、分布式系统、负载均衡、微服务、高可用性
**分布式系统取代单体架构,以微服务实现高扩展性和灵活性。通过负载均衡技术增强性能,防止单点故障,结合冗余备份与故障切换保障高可用性,这种架构是支撑大规模在线业务的关键。**
170 3