负载均衡

首先了解一下什么是一致性哈希，这里推荐一篇博客： http://blog.csdn.net/cywosp/article/details/23397179/ 在分布式应用中，扩容和收缩是一个半自动化的过程，在此期间，应用基本上是可用的，所以不能发生大规模动荡的意外，为了最小化潜在的影响，这时候需要使用到一致性hash算法实现负载均衡和分库分表，hash路由算法在分布式场景下极为重要的角色。 consistent hashing 算法早在 1997 年就在论文 Consistent hashing and random trees 中被提出，目前在cache 系统中应用越来越广泛； 比如你有 N 个 cache 服务器（后面简称 cache ），那么如何将一个对象 object 映射到 N 个 cache 上呢，你很可能会采用类似下面的通用方法计算 object 的 hash 值，然后均匀的映射到到 N 个 cache ； hash(object)%N 一切都运行正常，再考虑如下的两种情况； 1 一个 cache 服务器 m down 掉了（在实际应用中必须要考虑这种情况），这样所有映射到 cache m 的对象都会失效，怎么办，需要把 cache m 从 cache 中移除，这时候 cache 是 N-1 台，映射公式变成了 hash(object)%(N-1) ； 2

对于1M以内的文件上传，无需任何处理，大文件10M以上需要为上传路径添加/zuul前缀，也可使用zuul.servlet-path自定义前缀 如果Zuul使用了Ribbon做负载均衡，那么对于超大的文件，需要提升超时设置：hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds:60000 ribbon: 将服务注册到Eureka Server上，并配置文件上传大小的限制，配置文件添加以下内容： http://localhost:8761/erueka/ @ReponseBody @Controller public class FileUploadController{ }

服务端很多同学包括自己对keepalive理解不清晰，经常搞不清楚，TCP也有keepalive，HTTP也有keepalive，高可用也叫keepalive，经常混淆这几个概念。做下这几个概念的简述，尽管名字基本上是一样的，但是所表示意义和范畴却大相径庭。 Keepalived是一个基于VRRP协议来实现的服务高可用方案，可以利用其来避免IP单点故障。它的作用是检测服务器的状态，如果有一台服务器宕机，或出现故障，Keepalived将检测到，使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中。 Keepalived一般不会单独出现，而是与其它负载均衡技术（如lvs、haproxy、nginx）一起工作来达到集群的高可用。 一个简单的使用例子，将域名解析到一台负载均衡机器上，然后负载均衡反向代理到WEB机器上。中间的负载均衡只有一台，没法做到高可用，至少需要做到两台，那配置成两台机器之后，Keepalived就可以保证服务只有一个对外的虚拟IP，如果MASTER的负载均衡出现故障的时候，自动切换到BACKUP负载均衡上，服务不受任何影响。Keepalived来保证这些。 我们以前有过一套稍显复杂的服务配置，Keepalived给HAProxy提供高可用，然后HAProxy给Twemproxy提供高可用和负载均衡

微服务架构是一种软件架构风格，将一个复杂的应用拆分为多个服务模块，每个模块负责单一的业务功能对外服务，并且可以单独编译部署。每个模块单独部署，模块之间无法直接通信，所以需要借助RPC（远程过程通信协议）或者通过HTTP协议让模块之间进行通信。dubbo 是一套微服务系统的协调者。运用dubbo时将dubbo的jar引入项目中然后项目初始化的时候就会将当前系统需要发布的服务以及当前系统的IP和端口号发送给注册中心；以及描述当前系统所需要的服务，然后向注册中心请求这些服务所在的IP和端口号。 分布式： 将以一个业务拆分为多个子业务，部署在不同的服务器上。分布式和微服务是一样的。 集群： 分布式是以缩短单个任务的执行时间来提升效率，集群是通过单位时间内执行的效率来提高效率的，集群的每台服务器上部署的是同样的服务，他是有组织性的，一台服务器崩了，其他服务器可以顶上来。而分布式的每个节点都完成不同的功能，如果一个节点崩了则此服务器的服务无法访问，所以最好就是分布式+集群部署。 负载均衡： 负载均衡其实就是集群的前置。集群部署完后，需要一台服务器充当调度者角色，用户的所有请求首先被此调度者服务器接收，然后根据每台服务器的负载情况分发请求。 <HTTP重定向实现负载均衡> 当用户请求某个服务时，请求首先被调度者服务器截获，然后根据某种策略选择集群中的一台服务器

一, LVS介绍 linux , 是由章文嵩博士主导的开源负载均衡项目,目前LVS已经被集成到Linux内核模块中. 集群 : , , , . , , , , . 目的 . 分类 :HPC,LB,HA 1. 缩写 HPC 2. 3. 三层架构 , , 前端 : , ; 中间 : , ; 后端 : , . 性能评估 : 从性能角度 LVS , . 从功能角度 三种工作模型 其中DR模式性能最为优越，使用最为广泛。 NAT 模式 , 通过网络地址转换实现 , , . TUN 模式 ,TUN IP ,TUN DR , IP . DR 模式 , , 是通过路由技术实现的负载均衡技术 , NAT , MAC , , ,DR . 名词术语 : , , IP , IP IP , IP IP 常用算法 : - rr) - - - 缺点 : 上面说了负载均衡集群 LVS, LVS , , , , . 负载均衡集群主要是提高服务的响应能力的 , 100 , , , һ , , , , . 二 , , , , , , . 高可用性集群主要是提供 7*24 , down , down , , . 高性能集群主要是用于需要大量 CPU , , 3D , . 二, LVS的三种工作模式解析 /*--> */ /*--> */ /*--> */ /*--> */ /*--> */ 1 NAT LVS IP IP

创建rabbitmq容器 docker network create rabbtimanet 创建三节点rabbitmq容器 rabbitmq1 ： docker run -d --name=rabbitmq1 -p 5672:5672 -p 15672:15672 -e RABBITMQ_NODENAME=rabbitmq1 -e RABBITMQ_ERLANG_COOKIE='YZSDHWMFSMKEMBDHSGGZ' -h rabbitmq1 --net=rabbtimanet rabbitmq:management rabbitmq2 ： docker run -d --name=rabbitmq2 -p 5673:5672 -p 15673:15672 -e RABBITMQ_NODENAME=rabbitmq2 -e RABBITMQ_ERLANG_COOKIE='YZSDHWMFSMKEMBDHSGGZ' -h rabbitmq2 --net=rabbtimanet rabbitmq:management rabbitmq3 ： docker run -d --name=rabbitmq3 -p 5674:5672 -p 15674:15672 -e RABBITMQ_NODENAME=rabbitmq3 -e RABBITMQ_ERLANG_COOKIE=

1.背景介绍 随着 Internet 的快速发展和业务量的不断提高，基于网络的数据访问流量迅速增长，特别是对数据 中心、大型企业以及门户网站等的访问，其访问流量甚至达到了 10Gb/s 的级别；同时，服务器网 站借助 HTTP、FTP、SMTP 等应用程序，为访问者提供了越来越丰富的内容和信息，服务器逐渐 被数据淹没；另外，大部分网站（尤其电子商务等网站）都需要提供不间断 24 小时服务，任何服 务中断或通信中的关键数据丢失都会造成直接的商业损失。所有这些都对应用服务提出了高性能和 高可靠性的需求。 但是，相对于网络技术的发展，服务器处理速度和内存访问速度的增长却远远低于网络带宽和应用 服务的增长，网络带宽增长的同时带来的用户数量的增长，也使得服务器资源消耗严重，因而服务 器成为了网络瓶颈。传统的单机模式，也往往成为网络故障点。针对以上情况的解决方案：(1) 服务器进行硬件升级：采用高性能服务器替换现有低性能服务器。 该方案的弊端：高成本：高性能服务器价格昂贵，需要高额成本投入，而原有低性能服务器被闲置，造成资 源浪费。可扩展性差：每一次业务量的提升，都将导致再一次硬件升级的高额成本投入，性能再卓越 的设备也无法满足当前业务量的发展趋势。无法完全解决现在网络中面临的问题：如单点故障问题，服务器资源不够用问题等。(2) 组建服务器集群，利用负载均衡技术在服务器集群间进行业务均衡

一：bonding的概念 所谓bonding就是将多块网卡绑定同一IP地址对外提供服务，可以实现网卡的带宽扩容、高可用或者负载均衡。 二：bonding的优势 1 网络负载均衡 2 提高带宽网络传输效率 3 网络冗余与高可用 三：bonding的策略(7种策略) 1 balance-rr （mode=0）轮询（Round-robin）策略：从头到尾顺序的在每一个slave接口上面发送数据包。本模式提供负载均衡和容错的能力。 2 active-backup（mode=1）主备模式 ,在绑定中，只有一个slave被激活。当且仅当活动的slave接口失败时才会激活其他slave。为了避免交换　　机发生混乱此时绑定的MAC地址只有一个外部端口上可见。在bongding的2.6.2及其以后的版本中，主备模式下发生一次故障迁移时，bonding将在新　　激活的slave上会送一个或者多个gratuitous ARP.bonding的主salve接口上以及配置在接口上的所有VLAN接口都会发送gratuitous ARP，只要　　这些接口上配置了至少一个IP地址。VLAN接口上发送的的gratuitous ARP将会附上适当的VLAN id。本模式提供容错能力，primary option，　　documented below会影响本模式的行为。 3 balance-xor（mode=2

1. 什么是 Ribbon？ Spring Cloud Ribbon 是一套实现客户端负载均衡的工具。注意是客户端，当然也有服务端的负载均衡工具，我们后面再介绍。可以认为 Ribbon 就是一个负载均衡器（Load Balancer，简称LB，即：low比~~）。负载均衡就是将用户的请求平摊的分配到多个服务上，从而达到系统的高可用。 简单来说，Ribbon 的主要功能是提供客户端的软件负载均衡算法，将 Netflix 的中间层服务连接在一起。Ribbon 客户端组件给我们提供了一套很完善的配置项，比如可以配置连接超时、重试等等。 再说的通俗一点，就是可以在配置文件中列出 LB 后面所有的机器（即服务），Ribbon 会自动根据某种规则（如轮询、随机等等）去连接这些机器（即服务），我们也可以自定义一些负载均衡算法。 再简单点，Ribbon 就是一个类库，集成在服务消费方，消费方从服务注册中心获知有哪些地址（即服务）可用，然后消费方通过 Ribbon 从这些地址当中选择一个合适的服务器来消费服务。 2. Ribbon 的使用 我们在前面文章中，将订单服务注册到 Eureka，然后消费方可以通过 http 请求去获取订单的信息，但是这是最原始的 http 调用，没有任何 Ribbon 的东西在里面，接下来我们要在消费方植入 Ribbon。 2.1 导入 Ribbon 依赖

Ribbon 负载均衡 首先引入依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-ribbon</artifactId> </dependency> 修改application类，加入 @LoadBalanced @Bean public RestTemplate restTemplate(){ return new RestTemplate(); } controller类中调用 @Autowired private RestTemplate restTemplate; @GetMapping("user") @ResponseBody public List<User> findAll() { List<User> users = restTemplate.getForObject("http://USER/findAll",List.class); return users; } yml可选配置参数 #预加载配置,默认为懒加载 ribbon: eager-load: enabled: true clients: mima-cloud-producer,mima-cloud-producer2