负载均衡

本文是一篇关于技术整合的文章，以一个Web应用为例，使用Docker容器来部署我们的应用，并将Session交给Redis来存储和管理，涉 及到Docker/Redis/Tomcat/Nginx/Spring Web/Spirng Web MVC等技术。其中： Docker——容器技术或虚拟化技术，可以将我们的application及相关依赖打包到一个容器内，方便移植、集群部署，容器完全使用沙箱机制，容 器之间互不影响完全独立。下文所有的server都是部署在Docker中，不了解Docker和相关操作的可以先看看这篇文章。 Redis——一种开源的，先进的 key-value 存储数据库，可用于构建高性能、可扩展的 Web 应用程序的解决方案。本文中用来存储和管理Session。 Nginx——高性能的HTTP和反向代理服务器。本文中用来做负载均衡。 部署结构如下图所示： 环境信息 系统版本：CentOS 7 JDK版本：jdk1.8.0_60 Apache Tomcat版本：6.0.44 Docker版本：1.7.1 Redis版本：3.2.1 Nginx版本：1.10.1 本文中宿主机IP：192.168.111.128 注： 下文中相关技术的详细信息不重复说明了，需要的可以去官网查询。 Docker篇 1.安装与配置 这个过程不说了，省略1000字……（ 看前面发的文章 ）

上周欣喜地发现，微软官方终于针对 asp.net core 在使用负载均衡的情况下从 http 强制重定向至 https 的问题提供了解决方法。 app.UseForwardedHeaders( new ForwardedHeadersOptions { ForwardedHeaders = ForwardedHeaders.XForwardedProto }); var options = new RewriteOptions() .AddRedirectToHttpsPermanent(); app.UseRewriter(options); 但实际使用之后，欣喜变成了失望 —— 微软对这个问题的认识角度和我们不一样，造成这个方法对我们不适用，不得不继续使用我们的土方法。 为什么会这样？请看下面的分解。 AddRedirectToHttpsPermanent 早就在 BasicMiddleware 的 RedirectToHttpsRule 中实现了，它的逻辑很简单 —— 判断当前请求是否是https，如果不是就进行重定向。 if (!context.HttpContext.Request.IsHttps) { // ... } 这个直接了当的判断在使用负载均衡的场景下不仅不会发挥应有的作用，而且会产生致命的副作用 —— 让请求进入重定向死循环（ERR_TOO_MANY

Nginx教程(7) 正向代理与反向代理【总结】 1、前言 　　最近工作中用到反向代理，发现网络代理的玩法还真不少，网络背后有很多需要去学习。而在此之前仅仅使用了过代理软件，曾经为了访问google，使用了代理软件，需要在浏览器中配置代理的地址。我只知道有代理这个概念，并不清楚代理还有正向和反向之分，于是赶紧学习一下，补充一下知识。首先弄清楚什么是正向代理，什么是反向代理，然后是二者在实际使用中展示的方式是什么样的，最后总结一下正向代理用来做什么，反向代理可以做什么。 2、正向代理 　　正向代理类似一个跳板机，代理访问外部资源。 举个例子： 　　我是一个用户，我访问不了某网站，但是我能访问一个代理服务器，这个代理服务器呢,他能访问那个我不能访问的网站，于是我先连上代理服务器,告诉他我需要那个无法访问网站的内容，代理服务器去取回来,然后返回给我。从网站的角度，只在代理服务器来取内容的时候有一次记录，有时候并不知道是用户的请求，也隐藏了用户的资料，这取决于代理告不告诉网站。 　　客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。 　　例如之前使用过这类软件例如CCproxy， http://www.ccproxy.com / 需要在浏览器中配置代理的地址。 总结来说：正向代理 是一个位于客户端和原始服务器(origin server

版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。 本文链接：https://blog.csdn.net/u012486840/article/details/53098890 1、静态HTTP服务器 首先，Nginx是一个HTTP服务器，可以将服务器上的静态文件（如HTML、图片）通过HTTP协议展现给客户端。 配置： server { listen 80; # 端口号 location / { root /usr/share/nginx/html; # 静态文件路径 } } 2、反向代理服务器 什么是反向代理？ 客户端本来可以直接通过HTTP协议访问某网站应用服务器，如果网站管理员在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。 反向代理 配置： server { listen 80; location / { proxy_pass http://192.168.0.112:8080; # 应用服务器HTTP地址 } } 既然服务器可以直接HTTP访问，为什么要在中间加上一个反向代理，不是多此一举吗？反向代理有什么作用？继续往下看，下面的负载均衡、虚拟主机，都基于反向代理实现，当然反向代理的功能也不仅仅是这些。 3、负载均衡

简介 Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随即连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。 Ribbon 工作原理 ...... 案例搭建 对于Robbin，我们不用再去重新添加jar了，因为在eureka中就已经有了。 服务注册中心 前几节已经演示过，这里就不多讲了，如需要了解请 点击进入 服务消费方 application.yml 配置文件 #服务启动端口号 server: port: 9001 #服务名称(服务注册到eureka名称) spring: application: name: consumer #客户端注册进eureka服务列表内 eureka: client: service-url: defaultZone: http://localhost:7001/eureka #该应用为注册中心，不会注册自己,默认true register-with-eureka: true #是否需要从eureka上获取注册信息,默认true fetch

1.建立以下拓扑，并连接上ODL控制器。 Miniedit拓扑截图 ODL拓扑界面截图 2.利用ODL下发组表、流表，实现建议负载均衡 s1组表 下发组表后连通性截图 s2流表 s3流表 s4流表 3.利用Wireshark验证负载均衡的实现 来源： http://www.cnblogs.com/miyu5279/p/8137342.html

作业链接： https://edu.cnblogs.com/campus/fzu/SoftwareDefinedNetworking2017/homework/1559 实验目的 1、搭建如下拓扑并连接控制器 2、下发相关流表和组表实现负载均衡 3、抓包分析验证负载均衡 实验步骤 1.建立以下拓扑，并连接上ODL控制器。 2.利用ODL下发组表、流表，实现建议负载均衡 S1组表和流表 s2流表 s3流表 -s4流表 3.利用Wireshark验证负载均衡的实现 连通性 s4-eth1 s4-eth2 s4-eth3 来源： http://www.cnblogs.com/emperor-fa/p/8231306.html

SDN第5次上机作业 实验目的 1、搭建如下拓扑并连接控制器 2、下发相关流表和组表实现负载均衡 3、抓包分析验证负载均衡 实验步骤 1.建立以下拓扑，并连接上ODL控制器。 提交要求：ODL拓扑界面截图（如上图所示） 2.利用ODL下发组表、流表，实现建议负载均衡 提交要求：利用 sudo ovs-ofctl dump-flows br0 -O OpenFlow13 及 sudo ovs-ofctl dump-groups SW -O OpenFlow13 查看的截图 3.利用Wireshark验证负载均衡的实现 s4-eth1 s4-eth2 s4-eth3 提交要求：分别对s4各个端口进行抓包，验证负载均衡 来源： http://www.cnblogs.com/easteast/p/8125383.html

作业链接 1.建立以下拓扑，并连接上ODL控制器。 代码如下： from mininet.topo import Topo class MyTopo(Topo): def __init__(self): # initilaize topology Topo.__init__(self) # add hosts and switches h1 = self.addHost('h1') h2 = self.addHost('h2') h3 = self.addHost('h3') h4 = self.addHost('h4') sw1 = self.addSwitch('s1') sw2 = self.addSwitch('s2') sw3 = self.addSwitch('s3') sw4 = self.addSwitch('s4') # add links self.addLink(sw1,h1, 1, 1) self.addLink(sw1,sw2, 2, 1) self.addLink(sw1,sw3, 3, 1) self.addLink(sw4,sw4, 4, 1) self.addLink(sw2,sw4, 2, 2) self.addLink(sw3,sw4, 2, 3) self.addLink(sw4,h2, 4 ,1) self.addLink(sw4,h3,

大型高性能 ASP.NET 系统架构设计 　　大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。　　 　　 系列文章链接： 　　 构建高性能 ASP.NET 站点 开篇 　　 构建高性能 ASP.NET 站点之一 剖析页面的处理过程（前端） 　　 构建高性能ASP.NET站点之二 优化HTTP请求(前端) 　　 构建高性能ASP.NET站点之三 细节决定成败 　　 构建高性能ASP.NET站点 第五章—性能调优综述（前篇） 　　 大型高性能ASP.NET系统架构设计 　　 构建高性能ASP.NET站点 第五章—性能调优综述（中篇） 　　 构建高性能ASP.NET站点 第五章—性能调优综述（后篇） 　　 构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（上篇）—识别性能瓶颈 　　 构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下前篇）—简单的优化措施 　　 构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优（下后篇）—减少不必要的请求 　　 构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析 　　 构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化