负载均衡

第1章 引言 随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互 联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已 经成为架构研发人员首选的方式。 水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了宕机造成的损失。通过负载均衡策略，有效的降低了单台机 器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取 （Read）数据的速度和并发量 。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的 实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶 段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，比如Taobao的基于ibatis和Spring的的分布式数据访问 层，已有多年的应用，运行效率和生产实效性得到了开发人员和用户的肯定

对于千万级的注册用户的门户项目是前端这块是怎么去实现的，自己在平常的工作中总结了一些经验，也是在不断的挫折中，不断演练的，希望总结出来给大家参考下，和大家一起探讨，一起进步。 一、门户设计一般会遇到哪些难点 （一）、首页打开时间太慢了 在开发一个门户到生产上线后，首页响应时间是检验门户整个系统架构以及开发的重要的一项指标，有时候我们发现在公司测试发现速度都挺快的，怎么到生产首页打开就慢了呢？ （二）、页面加载不流畅，总感觉看着不舒服 因为门户一般都是偏向于内容和图片类资源比较多，但是我们打开自己的网页，有时候总感觉加载并不是按照我们期望的那样加载得到，顺其自然，总感觉看起来怪怪的。 （三）、希望用户缓存的地方未进行缓存 很多静态的前端资源，其实在系统未进行更新时候，第一次加载之后，希望缓存到用户的本地，但是因为缓存策略没搞好，经常未进行有效的缓存。 （四）、页面的头部尾部经常需要被第三方嵌入 因为作为一个比较大的门户站点，可能会让很多小的服务接入进来，但是头部和尾部因为是需要保持风格统一，所以经常需要被第三方进行嵌入。 （五）、代码没有进行有效的压缩，导致被窃取 因为作为门户站点，前端如果不进行加密的话，代码很容易被别人进行抄袭伪造，而且还很容易清楚里面的业务逻辑，从而很容易仿造和进行攻击。 （六）、增量静态资源发布 经常门户线上环境需要增加一点小功能

一.实验目的 二.实验拓扑 三.实验编址 四.实验步骤 1.基本配置 2.实现两分部间、总部与两分部之间的通信 使用ping命令测试直连链路连通性 配置完成，在R1查看路由表 在路由表中已经见到以PC2所在网段为目的网段的路由条目，且下一跳路由器为R3 测试PC1与PC2之间的连通性，可以看到通信正常，使用tracert命令测试经过的网关 查看R3路由表 在PC2测试与PC1的连通性并查看所经过网关 在总部R2测试与分布连通性 3.配置浮动静态路由实现路由备份 在R1上配置静态路由，目的网段为PC2所在网段，掩码24位，下一跳为R2，优先级设置为100（默认是60） 查看R1路由表 可以看到，路由表无变化，，使用display IP routing-table protocol static命令仅查看静态路由的路由信息 可以看到目的地址为PC2的两条优先级为100和60的静态路由条目都已经存在 在R3做R1同样的对称配置 关闭R1的S 1/0/1，验证备份链路 完成后查看R1路由表，使用display IP routing-table protocol static命令查看 可以看到 优先级为100的条目为Active状态，优先级为60的条目为Inactive状态 测试PC1与PC2连通性并查看所经过的网关 4.通过负载均衡化实现网络优化 回复R1上S 1/0/1接口

为什么有了Compose和Swarm，还会有Kubernetes的出现？ https://www.cnblogs.com/chenqionghe/p/11474486.html 图非常好 一、k8s设计思想更先进 k8s的主要设置思想，是从更宏观的角度，以统一的方式来定义任务之间的各种关系 1.k8s的核心功能图 2.k8s的全局架构图 把微服务比喻为人，服务治理解决的是人的沟通，人太多了就需要生存空间和沟通方式的优化，这就需要集群和编排。 compose和swarm可以解决少数人之间的关系，比如把手机号给你，你就可以方便的找到我，但是如果手机号变更的时候就会麻烦，人多了也会麻烦。 而k8s是站在上帝视角的高度抽象，看到了 总体有哪些组织，不同组织有什么样的特点（Job、CronJob、Autoscaler、StatefulSet、DaemonSet...） 不同组织之间交流可能需要什么（ConfigMap，Secret...），这样比较紧密的人在相同的pod中，通过Service-不会变更的手机号，来和不同的组织进行沟通， 帮助人们快速构建组织(Deployment、RC)。 k8s就是把组织协调这项管理学落实到了计算机工程上 二、功能对比 1. swarm偏重的是容器的部署，而k8s偏重应用的部署 swarm中最小单元是容器，而k8s是pod，pod可以由多个容器组成

原理概述: 浮动静态路由(Floating Static Route)是一种特殊的静态路由，通过配置去往相同的 目的网段，但优先级不同的静态路由，以保证在网络中优先级较高的路由，即主路由失效的情况下提供备份路由。正常情况下，备份路由 不会出现在路由表中。 负载均衡(Load sharing),当数据有多条可选路径前往同一目的网络，可以通过配 置相同优先级和开销的静态路由实现负载均衡，使得数据的传输均衡地分配到多条路径上，从而实现数据分流、减轻单条路径负载过重的效果。 而当其中某一条路径失效吋，其他路径仍然能够正常传输数据，也起到了冗余作用。 模拟实验内容： R2为某公司总部，R1与 R3是两个分部，主机PC-1与 PC-2所在的网段分别模拟两个分部中的办公网络。现需要总部与各个分部、分部与分部之间都能够通信，且分部之间在通信时，之间的直连链路为主用链路，通过总部的链路为备 用链路。本实验使用浮动静态路由实现需求，并再根据实际需求实现负载均衡来优化网络。 实验拓扑： 实验编址 ： 设备 接口 IP地址 子网掩码 默认网关 PC-1 Ethnet0/0/1 192.168.10.10 255.255.255.0 192.168.10.1 R1(Router) GE 0/0/0 192.168.10.1 255.255.255.0 N/A Serial0/0/1 10.0.12.1

（1）网站架构的伸缩性设计 1.不同功能进行物理分离实现伸缩。纵向分离和横向分离，不同的服务器部署不同的业务。 2.单一功能通过集群规模实现伸缩。集群内的多台服务器部署相同的服务，提供相同的功能。 （2）应用服务器集群的伸缩性设计 如果HTTP请求分发装置可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。 这里，这个HTTP请求分发装置被称作均衡负载服务器。 实现负载均衡的技术，以下几种： 1.HTTP重定向负载均衡。 HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求一台真实的Web服务器地址，并将该Web服务器地址写入HTTP重定向响应中（响应状态码为302）返回给用户浏览器。在图6.5中，浏览器请求访问域名 www.mysite.com 。DNS服务器解析得到IP地址是114.100.80.10，即HTTP重定向服务器的IP地址。然后浏览器通过IP地址 114.100.80.10访问HTTP重定向负载均衡服务器后，服务器根据某种负载均衡算法计算获得一台实际物理服务器的地址(114.100.80.3)，构造一个包含该实际物理服务器地址的重定向响应返回给浏览器，浏览器自动重新请求实际物理服务器的IP地址(114.100.80

这篇文章很不错。对 数据库水平扩展技术的前因后果讲解得比较透。转载来与大家分享（原始出处我已经找不到了，应该是来自于阿里的同学们）。 ------------------------------------------ 1 引言 随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取（Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶段（beta版）

socket.io是目前较为流行的web实时推送框架，其基于nodejs语言开发，底层用engine.io实现。 借助nodejs语言异步的特性，其获得了不错的性能。但单个实例的socket.io依然承载能力有限，最多只能容纳3000个long-polling方式的客户端进行连接。 将socket.io进行分布式扩展的难点有两处： 1. 进行负载均衡时客户端 必须保证始终连到一个节点上 如果客户端采用 long-polling长轮训 方式进行连接，则每次轮训都会产生一个新的请求，若不进行限制。就有可能连接到集群内新的 socket.io节点上，导致异常的发生。 解决方法： 使用nginx的ip_hash实现session sticky ，让客户端始终连接到集群内一台节点上。 2. 多个实例之间的消息推送 当集群内某台节点想要向连接到集群的所有客户端发送消息时，某些客户端因为负载均衡时ip_hash可能被分配到了其他的节点上，这时就需要向其他节点发布推送消息，让其他节点的同时向客户端进行推送。 解决方法： 使用redis的发布与订阅功能与 socket.io-redis开源库 ，该库在节点向客户端群发消息时会将该消息发布到redis的订阅队列中，让其他节点能够订阅到该消息，从而实现节点间消息推送。 上图是采用该架构的一个聊天服务器集群示例，每个chatnode相当于一个socket

最近要搭建一个高并发的网站。所以，得设计负载均衡这一块。从大的方向上讲，负载均衡分为硬负载均衡，和软负载均衡。下面依次简要说明一下： 硬负载均衡 ： 硬负载均衡，也就是使用专用的负载均衡设备。主流的硬负载均衡器有如下几种： F5 ：最主流的硬负载均衡器。便宜的20万以上，贵的100多万。 深信服 ：乞丐版低配12万元起价。 A10 ：基本都在100万元以上。 Array ：16-100万。 看这价格就知道，硬负载均衡，一般的中小公司，都会被价格折磨、然后犹豫、最后放弃。 软负载均衡 ： 软软负载均衡，也就是，不使用专用的负载均衡设备，而是通过软件来实现负载均衡。常用的有如下几种： DNS ：最原始的负载均衡方式，名字就已经说明了一切，不用细说了。 LVS ：最常用的软件负载均衡。我见过的国内百万级用户的架构，基本都是靠它顶的。 Nginx ：也是现在流行的、常用的负载均衡方案之一。 来源： oschina 链接： https://my.oschina.net/u/2250952/blog/549306

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