负载均衡

域名解析 | A记录 ，CNAME，MX，NS 你懂了吗 域名解析 什么是域名解析？域名解析就是国际域名或者国内域名以及中文域名等域名申请后做的到IP地址的转换过程。IP地址是网路上标识您站点的数字地址，为了简单好记，采用域名来代替ip地址标识站点地址。域名的解析工作由DNS服务器完成。 如下图，百度 www.baidu.com 就是域名，解析出来的IP 14.216.177.30 这个过程就是域名解析。 A 记录 A (Address) 记录是用来指定主机名（或域名）对应的IP地址记录。用户可以将该域名下的网站服务器指向到自己的web server上。同时也可以设置您域名的二级域名。又称IP指向，用户可以在此设置子域名并指向到自己的目标主机地址上，从而实现通过域名找到服务器。 　　说明： 　　·指向的目标主机地址类型只能使用IP地址； 　　1) 添加A记录 　　在“主机名”中填入子域的名字，“类型”为A，“IP地址/主机名”中填入web服务器的IP地址，点击“新增”按钮即可。 　　注：如果“主机名”一栏为空则表示对域名mydomain.com本身做指向。 　　2) 修改A记录 　　只要在“IP地址/主机名”一栏中将原来的IP地址直接修改为新IP地址，然后点击“修改”按钮即可。 　　3) 删除A记录 　　点击要删除的A记录后面对应的“删除”按钮即可。 　　4) 泛域名解析 　

Nginx应用 Nginx是一款非常优秀的HTTP服务器软件 支持高达50000个并发连接数的响应 拥有强大的静态资源处理能力 运行稳定 内存、CPU等系统资源消耗非常低 目前很多大型网站都应用Nginx服务器作为后端网站程序的反向代理及负载均衡器，提升整个站点的负载并发能力 Nginx负载均衡实现原理 Nginx配置反向代理的主要参数 upstream 服务池名{} 配置后端服务器池，以提供响应数据 proxy_ _pass http://服务池名 配置将访问请求转发给后端服务器池的服务器处理 Nginx静态处理优势 Nginx处理静态页面的效率远高于Tomcat的处理能力 如果Tomcat的请求量为1000次，则Nginx的请求量为6000次 Tomcat每秒的吞吐量为0.6M，Nginx的每秒吞吐量为3.6M Nginx处理静态资源的能力是Tomcat处理的6倍，优势可见一斑 动静分离原理 服务端接收来自客户端的请求中，既有静态资源也有动态资源 实验环境： Nginx服务器：192.168.52.135 Tomcat服务器1：192.168.52.134 Tomcat服务器2：192.168.52.150 1、将实验所需工具包从宿主机共享出去 负载均衡配置： 一、搭建Tomcat服务器1 1、安装jdk [root@tomcat1 ~]# mkdir /mnt/tools /

PS ：主要罗列的是问题点，以及对应的一些解决方案，仅供参考。。。 相关链接： 阿里全链路压测 有赞全链路压测 京东全链路压测 饿了么全链路压测 滴滴全链路压测解决之道 美团全链路压测自动化实践 逻辑思维在全链路压测方面的实践 一、什么是全链路压测 基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。 二、全链路压测解决什么问题 针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。 三、面对的问题点以及解决方案 1、业务模型梳理 首先应该明确的是：全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块， 针对性的进行扩容准备，而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍，这样会造成不必要的成本投入。 2、数据模型构建 数据构建和准备，应该考虑这几点问题： ①、数据的真实性和可用性 可以从生产环境完全移植一份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量； ②、数据脱敏 基于生产环境的全链路压测，必须考虑的一点是不能产生脏数据，以免对生产造成影响，影响用户体验等，因此在数据准备时需要进行数据脱敏； ③、数据隔离 同样

负载均衡服务概念 负载作用： 01： 对用户访问请求进行调度处理 02：减少web服务器访问压力 负载实现： 硬件方式实现：F5 A10 软件方式实现： nginx：利用网络4层或7层实现负载均衡 Lvs : 利用网络4层功能负载 haproxy : 利用网络4层或7层功能实现负载均衡（功能配置更强大/网站页面图形界面） 集群： 　　对台服务器完成相同的工作(提高网站架构并发处理能力/架构伸缩性更高/架构冗余能力强/架构成本降低) 　　1）：部署软件程序相同 　　2）：部署软件配置相同 　　3）：部署网站代码相同 反向代理： 　　可以让外网用户 -- 访问 --内网主机服务器 　　外网用户--> nginx（方向代理）--发送给内网web服务器 正向代理： 　　可以让内网主机 --访问 --外网主机服务器 内网用户访问 --代理服务器（正向代理）-->国外网站服务器 负载均衡部署配置过程： 第一个历程：编写配置web集群服务 来源： https://www.cnblogs.com/zhanghongqi/p/11846037.html

下载 nginx-upsync-module wget https://github.com/weibocom/nginx-upsync-module/archive/v2.1.0.tar.gz 重新编译nginx --add-module=/root/sortware/nginx-upsync-module-2.1.0 下载consul ungzip解压 cp consul /usr/bin 运行 consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -node=ali -bind=内网地址 -ui -client=0.0.0.0 upstream swoole_server { 　　server nginx.xuedong.vip:9501; 　　upsync 127.0.0.1:8500/v1/kv/upstreams/swoole_test upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off; 　　upsync_dump_path /root/servers_test.conf; 　　include /root/servers_test.conf; } reload -s reload

前言： 　　之前写了通过Ribbon+RestTemplate实现调用服务，此处我再系统的说一下两者的区别 一、springcloud的负载均衡策略 　　1、Ribbon　 是基于Netflix Ribbon实现的一套客户端 负载均衡的工具，类似Nginx 主要功能时提供客户端的软件负载均衡算法 LB就是负载均衡，集中式(F5)，进程内(Nginx)，消费者可以自动看 从Eureka中拿到对应的服务列表，默认进行轮询RoundRobinRule 下图是RestTemplate的自带的7中均衡策略 我们在之前通过Ribbon+RestTemplate实现调用服务的时候，在获取RestTemplate的方法上加了@LoadBalanced ,实现默认轮询，如果需要更改其均衡策略，则在配置类中声明想要的均衡策略 具体实现参考： https://www.cnblogs.com/guanyuehao0107/p/11819375.html @Configuration public class RestConfig { @Bean //通过RestTemplate来实现调用接口 @LoadBalanced //表示RestTemplate开启了负载均衡 public RestTemplate getRestTemplate(){ return new RestTemplate(); } /

一、本地环境介绍： 负载均衡的三台机器均为Ubuntu Server 14.04 64位系统，内核中已集成ipvs模块( modprobe -l | grep ipvs 查看 )。为演示LVS负载均衡后的效果，需先在其中两台机器中安装apache服务（apt-get install apache2），并将位置在/var/www/html/目录下index.html文件修改成不同内容（如主机名）。 1 二、部署架构： 主机名 IP 角色 UbuntuServerEn64 192.168.226.149 负载均衡服务器 director UbuntuServerEn64_2 192.168.226.145 真实服务器 real server（已安装apache） UbuntuServerEn64_3 192.168.226.148 真实服务器 real server（已安装apache） VIP为192.168.226.150（VIP为对外提供的IP，并不是真实物理IP） 1 2 3 4 5 6 7 部署成功后，所有发送到VIP的请求包都会由director按照设置的算法分发到不同的real server进行处理。 三、部署过程： 1、负载均衡服务器（director）配置： #由于内核已集成ipvs模块，只需要安装ipvsadm即可 apt-get install ipvsadm

Nginx负载均衡概述 Web服务器，直接面向用户，往往要承载大量并发请求，单台服务器难以负荷，我使用多台WEB服务器组成集群，前端使用Nginx负载均衡，将请求分散的打到我们的后端服务器集群中，实现负载的分发。那么会大大提升系统的吞吐率、请求性能、高容灾 Nginx要实现负载均衡需要用到proxy_pass代理模块配置 Nginx负载均衡与Nginx代理不同地方在于 Nginx代理仅代理一台服务器，而Nginx负载均衡则是将客户端请求代理转发至一组upstream虚拟服务池 Nginx可以配置代理多台服务器，当一台服务器宕机之后，仍能保持系统可用。 upstream配置 在nginx.conf > http 区域中 upstream django { server 10.0.0.10:8000; server 10.0.0.11:9000; } 在nginx.conf > http 区域 > server区域 > location配置中 添加proxy_pass location / { root html; index index.html index.htm; proxy_pass http://django; } 此时初步负载均衡已经完成，upstream默认按照轮训方式负载，每个请求按时间顺序逐一分配到后端节点。 upstream分配策略 weight 权重

Nginx负载均衡概述 1 Web服务器，直接面向用户，往往要承载大量并发请求，单台服务器难以负荷，我使用多台WEB服务器组成集群，前端使用Nginx负载均衡，将请求分散的打到我们的后端服务器集群中， 2 实现负载的分发。那么会大大提升系统的吞吐率、请求性能、高容灾 Nginx要实现负载均衡需要用到proxy_pass代理模块配置 Nginx负载均衡与Nginx代理不同地方在于 Nginx代理仅代理一台服务器，而Nginx负载均衡则是将客户端请求代理转发至一组upstream虚拟服务池 Nginx可以配置代理多台服务器，当一台服务器宕机之后，仍能保持系统可用。 upstream配置 在nginx.conf > http 区域中 upstream django { server 10.0.0.10:8000; server 10.0.0.11:9000; } 在nginx.conf > http 区域 > server区域 > location配置中 添加proxy_pass location / { root html; index index.html index.htm; proxy_pass http://django; } 此时初步负载均衡已经完成，upstream默认按照轮训方式负载，每个请求按时间顺序逐一分配到后端节点。 upstream分配策略 weight 权重

按照上一节中《搭建高可用mongodb集群（三）—— 深入副本集》搭建后还有两个问题没有解决： 从节点每个上面的数据都是对数据库全量拷贝，从节点压力会不会过大？ 数据压力大到机器支撑不了的时候能否做到自动扩展？ 在系统早期，数据量还小的时候不会引起太大的问题，但是随着数据量持续增多，后续迟早会出现一台机器硬件瓶颈问题的。而mongodb主打的就是海量数据架构，他不能解决海量数据怎么行！不行！“分片”就用这个来解决这个问题。 传统数据库怎么做海量数据读写？其实一句话概括：分而治之。上图看看就清楚了，如下 taobao岳旭强在infoq中提到的 架构图： 上图中有个TDDL，是taobao的一个数据访问层组件，他主要的作用是SQL解析、路由处理。根据应用的请求的功能解析当前访问的sql判断是在哪个业务数据库、哪个表访问查询并返回数据结果。具体如图： 说了这么多传统数据库的架构，那Nosql怎么去做到了这些呢？mysql要做到自动扩展需要加一个数据访问层用程序去扩展，数据库的增加、删除、备份还需要程序去控制。一但数据库的节点一多，要维护起来也是非常头疼的。不过mongodb所有的这一切通过他自己的内部机制就可以搞定！顿时石化了，这么牛X！还是上图看看mongodb通过哪些机制实现路由、分片： 从图中可以看到有四个组件：mongos、config server、shard、replica