HAproxy

【推荐阅读】微服务还能火多久？>>> 转自: https://www.cnblogs.com/lyhabc/p/5820492.html 　　利用HAProxy代理SQL Server的AlwaysOn辅助副本 公司最近数据库升级到SQL Server2014 ，并部署了alwayson高可用集群 机房内有三套程序需要读取数据库 第一套：主程序，读写数据库，连接主副本 第二套：报表程序，读报表，连接辅助副本 第三套：历史库程序，读历史库，连接辅助副本 软件环境 机器环境 架构图 为什麽需要使用HAProxy？ 之前机房里面有2000个终端，这些终端是一个很小的嵌入式设备，第二套报表程序原来是使用直连数据库IP（10.11.10.36）来连接数据库 但这样有一个弊端，当36这台辅助副本宕机，那么报表程序就瘫痪了，因为2000个终端要更改数据库连接需要烧写程序到终端里面非常耗费时间 可能要几天时间 最后决定使用HAProxy做负载均衡和TCP连接重定向 使用HAProxy有几个好处 1、前端不需要后端数据库的实际IP，当需要升级后端数据库，比如打补丁的时候特别方便 2、HAProxy能够自动检测后端数据库服务，探测1433端口是否存活，如果1433端口出问题，能够自动重定向连接到37这台辅助副本 3、减轻单台读库压力，使用RR轮询算法，请求均衡分发到36和37这两台辅助副本

【推荐阅读】微服务还能火多久？>>> LVS特点： 1.抗负载能力强，使用IP负载均衡技术，只做分发，所以LVS本身并没有多少流量产生； 2.稳定性、可靠性好，自身有完美的热备方案；（如：LVS+Keepalived） 3.应用范围比较广，可以对所有应用做负载均衡； 4.不支持正则处理，不能做动静分离。 常用四种算法： 1.rr：轮询，轮流分配到后端服务器； 2.wrr：权重轮叫，根据后端服务器负载情况来分配； 3.lc：最小连接，分配已建立连接最少的服务器上； 4.wlc：权重最小连接，根据后端服务器处理能力来分配。 可以采用ipvsadm –p（persistence）来保持session，默认是300/s Nginx特点： 1.可工作在七层或四层，可以对做正则规则处理；（如：针对域名、目录进行分流） 2.配置简单，能ping通就能进行负载功能，可以通过端口检测后端服务器状态，不支持url检测； 3.抗高并发，采用epoll网络模型处理客户请求； 4.只支持HTTP和EMail，应用范围比较少； 5.nginx主要是HTTP和反向代理服务器，低系统资源消耗。 常用四种算法： 1.rr：（默认）轮询，轮流分配到后端服务器； 2.weight：根据后端服务器性能分配； 3.ip_hash：每个请求按访问ip的hash结果进行分配，并发小时合适，解决session问题； 4.fair

一、前言 　　已经一年没有更新博客了，由于公司事务比较多，并且楼主我也积极在公司项目中不断实践.net core、DDD以及Abp vnext，也积累了一些吐血经验，目前我在做一家在线教育公司负责智慧校园业务，所涉及到的数据一天达上百万，并且还需要对这些并发数据进行解析转化，在此次的过程中也涉及到了使用RabbitMQ进行业务的解耦和流量削峰来应对如此大量的请求；过程是痛苦的，但结果是美好的。 说到MQ，大家应该都听过，像RabbitMQ，Kfaka，Activemq，rocketmq等，消息队列是一种跨进程的通信机制，主要用于上下游之间传递消息的，主要给我们解决了“应用解耦”、“流量削峰”、“异步通信”等，下图是针对MQ的对比图，如果不完善的地方请海涵： 二、RabbitMQ说明 1、在这么多的MQ中，我为什么选择使用RabbitMQ呢？其实最主要的原因是它是部署最广泛的开源消息代理，有成千上万的用户，社区支持性非常好，支持许多操作系统和云环境上运行，也支持多种消息传递协议，关键还是部署简单，在高并发、高可用中有成熟的方案，详情见官方文档： RabbitMQ 2、在针对RabbitMQ集群架构方案中，有四种架构模式，主备模式、镜像模式、远程模式、多活模式，每种架构都可以算很实用，在企业中“镜像模式”也是用的最多的，最普遍的。 3、RabbitMQ 六种工作模式 点对点模式（一对一

一、前言 　　已经一年没有更新博客了，由于公司事务比较多，并且楼主我也积极在公司项目中不断实践.net core、DDD以及Abp vnext，也积累了一些吐血经验，目前我在做一家在线教育公司负责智慧校园业务，所涉及到的数据一天达上百万，并且还需要对这些并发数据进行解析转化，在此次的过程中也涉及到了使用RabbitMQ进行业务的解耦和流量削峰来应对如此大量的请求；过程是痛苦的，但结果是美好的。 说到MQ，大家应该都听过，像RabbitMQ，Kfaka，Activemq，rocketmq等，消息队列是一种跨进程的通信机制，主要用于上下游之间传递消息的，主要给我们解决了“应用解耦”、“流量削峰”、“异步通信”等，下图是针对MQ的对比图，如果不完善的地方请海涵： 二、RabbitMQ说明 1、在这么多的MQ中，我为什么选择使用RabbitMQ呢？其实最主要的原因是它是部署最广泛的开源消息代理，有成千上万的用户，社区支持性非常好，支持许多操作系统和云环境上运行，也支持多种消息传递协议，关键还是部署简单，在高并发、高可用中有成熟的方案，详情见官方文档： RabbitMQ 2、在针对RabbitMQ集群架构方案中，有四种架构模式，主备模式、镜像模式、远程模式、多活模式，每种架构都可以算很实用，在企业中“镜像模式”也是用的最多的，最普遍的。 3、RabbitMQ 六种工作模式 点对点模式（一对一

负载均衡定义： 负载均衡是由多台服务器以对称的方式组成一个服务器集合，每台服务器都 具有等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。通过某 种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器 上，而接收到请求的服务器独立地回应客户的请求。 均衡负载能够平均分配客户请求到服务器列阵，籍此提供快速获取重要数据， 解决大量并发访问服务问题。这种 群集技术 可以用最少的投资获得接近于大型 主机的性能。 这种技术可以运用在流量拥塞时、访问路径过长、网民数量大增、运行这种系统负载、大大的提高了系统的可靠性、负载均衡技术解决网络拥塞的问题、处理大量并发的访问服务能力、提高服务器的响应速度、为用户提供更好的访问质量。所以说负载均衡是智能化、高性能、灵活性的技术。 设计思想： 一台普通服务器的处理能力只能达到每秒几万个到几十万个请求，无法在一秒钟内处理上百万个甚至更多的请求。但若能将多台这样的服务器组成一个系统，并通过相关技术将所有请求平均分配给所有服务器，那么这个系统就完全拥有每秒钟处理几百万个甚至更多请求的能力。这就是 负载均衡 最初的基本设计思想。 负载均衡的几种实现技术： http重定向： 当http代理（比如浏览器）向web服务器请求某个URL后，web服务器可以通过http响应头信息中的Location标记来返回一个新的URL

1. 导言 绝大多数业务场景都是需要知道客户端IP的 在k8s中运行的业务项目，如何获取到客户端真实IP？ 本文总结了通行的2种方式 要答案的直接看方式一、方式二和总结 SEO 关键字 nginx ingress客户端真实ip kubernets获取客户端真实ip rke获取客户端真实ip rancher获取客户端真实ip 本文由 www.iamle.com 流水理鱼 原创，wx公众号同名 1.1 流量链路介绍 7层转发链路 Client(客户端) > Nginx > K8s Ingress(Nginx ingress) 4层转发链路 Client(客户端) > 公有云LB > K8s Ingress(Nginx ingress) ps: 实际业务会串联更多层级的转发。WAF、CDN、Api Gateway一般是http 7层转发，LB一般是4层tcp转发 1.2 准备whoami探针 whomai是一个go编写的调试探针工具，回显http头信息 在k8s中部署一个containous/whoami用来作为探针，配置好ingress公网和访问，这样客户端web访问可以看到基本的http头信息，方便调试 kubectl apply -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: whoami

1. 导言 绝大多数业务场景都是需要知道客户端IP的 在k8s中运行的业务项目，如何获取到客户端真实IP？ 本文总结了通行的2种方式 要答案的直接看方式一、方式二和总结 SEO 关键字 nginx ingress客户端真实ip kubernets获取客户端真实ip rke获取客户端真实ip rancher获取客户端真实ip 本文由 www.iamle.com 流水理鱼 原创，wx公众号同名 1.1 流量链路介绍 7层转发链路 Client(客户端) > Nginx > K8s Ingress(Nginx ingress) 4层转发链路 Client(客户端) > 公有云LB > K8s Ingress(Nginx ingress) ps: 实际业务会串联更多层级的转发。WAF、CDN、Api Gateway一般是http 7层转发，LB一般是4层tcp转发 1.2 准备whoami探针 whomai是一个go编写的调试探针工具，回显http头信息 在k8s中部署一个containous/whoami用来作为探针，配置好ingress公网和访问，这样客户端web访问可以看到基本的http头信息，方便调试 kubectl apply -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: whoami

master相关组件部署 来源： oschina 链接： https://my.oschina.net/u/4350344/blog/3216083

https://www.cnblogs.com/daixiang/p/5575477.html 一、haproxy介绍： 　　HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。HAProxy实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。 　　在linux内核版本为2.6或打了epoll补丁的linux2.4上运行haproxy能获得其最好的性能。 二、keepalived介绍：　　 　　keepalived理论工作原理 　　　　　　keepalived可提供vrrp以及health-check功能，可以只用它提供双机浮动的vip