负载均衡

1、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 upstream backserver { server 192.168.0.14; server 192.168.0.15; } 2、指定权重 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 upstream backserver { server 192.168.0.14 weight=10; server 192.168.0.15 weight=10; } 3、IP绑定 ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 upstream backserver { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; } 4、最少连接 least_conn web请求会被转发到连接数最少的服务器上面。 upstream backserver { least_conn; server 192.168.0.14:88; server 192.168.0.15:80; } 来源： CSDN 作者： 怪只怪满眼尽是人间烟火 链接： https://blog.csdn.net/weixin_38959210/article

1 负载均衡 调用微服务时,在集群服务器中,轮询发送请求 @LoadBalanced 注解添加到RestTemplate 修改请求路径,写服务id, rt.getForObject(“http://item-service/{1}”) 底层是RestTemplate 在微服务中是必须有的 2 重试 MaxAutoretries 单台服务器的重试次数 2) MaxAutoretriesNextServer 向后重试几台服务器 3) Connecttimeout 连接超时时间 ; 会引起重试 4) ReadTimeout 等待接收响应的超时时间 ; 会引起重试 5) OkToRetryOnAllOperations 是否对所有类型请求都重试 ; 默认只对get请求重试 两个超时参数在yml配置中配置无效,需要在代码中配置 3 微服务中必须使用负载均衡么? 微服务中必须使用重试么?重试优缺点是什么? 在微服务架构中，负载均衡是必须使用的技术，通过它来实现系统的高可用、集群扩容等功能。负载均衡可以分为两种：服务端负载均衡和客户端负载均衡。通常所说的负载均衡指服务器负载均衡， 服务器集群时才需要做负载均衡，单台服务器谈不上负载均衡 重试 优点：避免因为网络阻塞导致的连接失败 缺点：可能发生重复的请求操作 微服务中可以不使用负载均衡 缺点:一处爆炸处处爆炸 优点:省钱 微服务中不是必须使用重试

了解LVS LVS 是 Linux Virtual Server 的简写，意即 Linux虚拟服务器 ，是一个虚拟的服务器集群系统。本项目在1998年5月由 章文嵩 博士成立，是中国国内最早出现的自由软件项目之一。 宗旨 使用集群技术和Linux操作系统实现一个高性能、高可用的服务器. 很好的可伸缩性（Scalability） 很好的可靠性（Reliability） 很好的可管理性（Manageability）。 实操 我们这里用到的软件是keepalived，Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。 准备环境 准备三台服务器 lvs服务器： 10.0.0.41 nginx两台 ：10.0.0.42 10.0.0.43 lvs服务器的操作 #!/bin/bash yum -y install ipvsadm keepalived //下载keepalived的服务 echo " " > /etc/keepalived/keepalived.conf //清空配置文件 cat >>/etc

使用 3 台阿里云服务器（k8s-master0, k8s-master1, k8s-master2）作为 master 节点搭建高可用集群，负载均衡用的是阿里云 SLB ，需要注意的是由于阿里云负载均衡不支持后端服务器自己转发给自己，所以 master 节点的 control-plane-endpoint 不能走负载均衡。 先在 k8s-master0 上安装好 k8s ，安装步骤见 Ubuntu 安装 k8s 三驾马车 kubelet kubeadm kubectl ，然后打快照创建阿里云 ecs 镜像。 确定 control-plane-endpoint 主机名，这里假设是 k8s-api ，在 k8s-master0 的 hosts 中添加 k8s-api 的解析。 10.0.1.81 k8s-api 在 k8s-master0 上创建集群， kubeadm init \ --control-plane-endpoint "k8s-api:6443" --upload-certs \ --image-repository registry.aliyuncs.com/google_containers \ --pod-network-cidr=192.168.0.0/16 \ --v=6 创建成功后会出现下面的提示 Your Kubernetes control-plane

Deployment介绍 Deployment是kubernetes 1.2引入的概念，用来解决Pod的编排问题。Deployment可以理解为RC的升级版（RC+Reolicat Set）。特点在于可以随时知道Pod的部署进度，即对Pod的创建、调度、绑定节点、启动容器完整过程的进度展示。 使用场景 创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建过程。 检查Deployment的状态来确认部署动作是否完成（Pod副本的数量是否达到预期值）。 更新Deployment以创建新的Pod(例如镜像升级的场景)。 如果当前Deployment不稳定，回退到上一个Deployment版本。 挂起或恢复一个Deployment。 Service介绍 Service定义了一个服务的访问入口地址，前端应用通过这个入口地址访问其背后的一组由Pod副本组成的集群实例，Service与其后端的Pod副本集群之间是通过Label Selector来实现“无缝对接”。RC保证Service的Pod副本实例数目保持预期水平。 外部系统访问Service的问题 IP类型 说明 Node IP Node节点的IP地址 Pod IP Pod的IP地址 Cluster IP Service的IP地址 环境介绍 主机 IP地址 服务 master 192.168.1.21

1、大型网站系统与JAVA中间件实践 本书围绕大型网站和支撑大型网站架构的Java中间件的实践展开介绍。 从分布式系统的知识切入，让读者对分布式系统有基本的了解；然后介绍大型网站随着数据量、访问量增长而发生的架构变迁；接着讲述构建Java中间件的相关知识；之后的几章都是根据笔者的经验来介绍支撑大型网站架构的Java中间件系统的设计和实践。希望读者通过本书可以了解大型网站架构变迁过程中的较为通用的问题和解法，并了解构建支撑大型网站的Java中间件的实践经验。 对于有一定网站开发、设计经验，并想了解大型网站架构和支撑这种架构的系统的开发、测试等的相关工程人员，本书有很大的参考意义；对于没有网站开发设计经验的人员，通过本书也能宏观了解大型网站的架构及相关问题的解决思路和方案。 2、大型分布式网站架构设计与实践 本书主要介绍了大型分布式网站架构所涉及的一些技术细节，包括SOA架构的实现，互联网安全架构，构建分布式网站所依赖的基础设施，系统稳定性保障，海量数据分析等内容，深入地讲述了大型分布式网站架构设计的核心原理，并通过一些架构设计的典型案例，帮助读者了解大型分布式网站设计的一些常见场景及遇到的问题。 3、Web信息架构设计大型网站 针对新技术做了全面更新——搭配新颖范例、全新场景及最佳实践信息——但是，其焦点依然放在基础原理上。其结构严谨，图文并貌

一、 Hadoop 集群动态扩容、缩容 随着公司业务的增长，数据量越来越大，原有的 datanode 节点的容量已经不能满足存储数据的需求，需要在 原有集群基础上动态添加新的数据节点 。也就是俗称的 动态扩容 。 有时候旧的服务器需要进行退役更换，暂停服务，可能就需要在 当下的集群中停止某些机器上 hadoop 的服务 ，俗称 动态缩容 。 1． 动态扩容 1.1． 基础准备 在基础准备部分，主要是设置 hadoop 运行的系统环境 修改新机器系统 hostname （通过 /etc/sysconfig/network 进行修改） 修改 hosts 文件，将集群所有节点 hosts 配置进去（集群所有节点保持 hosts 文件统一） 设置 NameNode 到 DataNode 的免密码登录（ ssh-copy-id 命令实现） 修改主节点 slaves 文件，添加新增节点的 ip 信息（ 集群重启时配合一键启动脚本使用 ） 在新的机器上上传解压一个新的 hadoop 安装包，从主节点机器上将 hadoop 的所有配置文件， scp 到新的节点上。 1.2． 添加 datanode 在 namenode 所在的机器的 /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop 目录下创建 dfs.hosts 文件 cd /export

浮动静态路由及负载均衡 原理概述 浮动静态路由(Floating Static Route)是一种特殊的静态路由，通过配置去往相同的目的网段，但优先级不同的静态路由，以保证在网络中优先级较高的路由，即主路由失效的情况下，提供备份路由。正常情况下，备份路由不会出现在路由表中。 负载均衡(Load sharing)，当数据有多条可选路径前往同一目的网络，可以通过配置相同优先级和开销的静态路由实现负载均衡，使得数据的传输均衡地分配到多条路径上，从而实现数据分流、减轻单条路径负载过重的效果。而当其中某一条路径失效时，其他路径仍然能够正常传输数据，也起到了冗余作用。 实验目的 ●理解浮动静态路由的应用场景 ●掌握配置浮动静态路由的方法 ●掌握测试浮动静态路由的方法 ●掌握配置静态路由负载均衡的方法 ●掌握测试静态路由负载均衡的方法 实验内容 R2为某公司总部，R1与R3是两个分部，主机PC-1与PC-2所在的网段分别模拟两个分部中的办公网络。现需要总部与各个分部、分部与分部之间都能够通信，且分部之间在通信时，之间的直连链路为主用链路，通过总部的链路为备用链路。本实验使用浮动静态路由实现需求，并再根据实际需求实现负载均衡来优化网络。 实验拓扑 实验步骤 1.基本配置 根据实验编址表进行相应的基本配置，并使用ping命令检测各直连链路的连通性。 其余直连网段的连通性测试省略。 2.实现两分部间

背景 Dubbo是一个分布式服务框架，能避免单点故障和支持服务的横向扩容。一个服务通常会部署多个实例。如何从多个服务 Provider 组成的集群中挑选出一个进行调用，就涉及到一个负载均衡的策略。 几个概念 在讨论负载均衡之前，我想先解释一下这3个概念。 负载均衡 集群容错 服务路由 这3个概念容易混淆。他们都描述了怎么从多个 Provider 中选择一个来进行调用。那他们到底有什么区别呢?下面我来举一个简单的例子，把这几个概念阐述清楚吧。 有一个Dubbo的用户服务，在北京部署了10个，在上海部署了20个。一个杭州的服务消费方发起了一次调用，然后发生了以下的事情: 根据配置的路由规则，如果杭州发起的调用，会路由到比较近的上海的20个 Provider。 根据配置的随机负载均衡策略，在20个 Provider 中随机选择了一个来调用，假设随机到了第7个 Provider。 结果调用第7个 Provider 失败了。 根据配置的Failover集群容错模式，重试其他服务器。 重试了第13个 Provider，调用成功。 上面的第1，2，4步骤就分别对应了路由，负载均衡和集群容错。 Dubbo中，先通过路由，从多个 Provider 中按照路由规则，选出一个子集。再根据负载均衡从子集中选出一个 Provider 进行本次调用。如果调用失败了，根据集群容错策略

一、ribbon是什么? Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。 简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。 二、客户端负载均衡？？ 服务端负载均衡?? 我们用一张图来描述一下这两者的区别 这篇文章里面不会去解释nginx，如果不知道是什么的话，可以先忽略， 先看看这张图 服务端的负载均衡是一个url先经过一个代理服务器（这里是nginx），然后通过这个代理服务器通过算法（轮询，随机，权重等等…）反向代理你的服务，来完成负载均衡 而客户端的负载均衡则是一个请求在客户端的时候已经声明了要调用哪个服务，然后通过具体的负载均衡算法来完成负载均衡。 三、如何使用: 首先，我们还是要引入依赖，但是，eureka已经把ribbon集成到他的依赖里面去了，所以这里不需要再引用 ribbon的依赖，如图： 依赖： < dependency > < groupId