负载均衡SLB

在软件系统的架构设计中，对集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。负载均衡本质上是用于将用户流量进行均衡减压的，因此在互联网的大流量项目中，其重要性不言而喻。

早期的互联网应用，由于用户流量比较小，业务逻辑也比较简单，往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大，稍微好一点的系统，访问量就非常大了，并且系统功能也越来越复杂，那么单台服务器就算将性能优化得再好，也不能支撑这么大用户量的访问压力了，这个时候就需要使用多台机器，设计高性能的集群来应对。

那么，多台服务器是如何去均衡流量、如何组成高性能的集群的呢？

此时就需要请出 「负载均衡器」 入场了。

负载均衡（Load Balancer）是指把用户访问的流量，通过「负载均衡器」，根据某种转发的策略，均匀的分发到后端多台服务器上，后端的服务器可以独立的响应和处理请求，从而实现分散负载的效果。负载均衡技术提高了系统的服务能力，增强了应用的可用性。

目前市面上最常见的负载均衡技术方案主要有三种：

基于DNS负载均衡

基于硬件负载均衡

基于软件负载均衡

三种方案各有优劣，DNS负载均衡可以实现在地域上的流量均衡，硬件负载均衡主要用于大型服务器集群中的负载需求，而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中，这三种是可以组合在一起使用。下面来详细讲讲：

基于DNS负载均衡

基于DNS来做负载均衡其实是一种最简单的实现方案，通过在DNS服务器上做一个简单配置即可。

其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP，北方的用户来访问的话，我就返回北京业务服务器所在的IP。

在这个模式下，用户就相当于实现了按照「就近原则」将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。

使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。

但是也有一个明显的缺点是：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。

另外，使用DNS做负载均衡的话，大多是基于地域或者干脆直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。

基于硬件负载均衡

硬件的负载均衡那就比较牛逼了，比如大名鼎鼎的 F5 Network Big-IP，也就是我们常说的 F5，它是一个网络设备，你可以简单的理解成类似于网络交换机的东西，完全通过硬件来抗压力，性能是非常的好，每秒能处理的请求数达到百万级，即 几百万/秒 的负载，当然价格也就非常非常贵了，十几万到上百万人民币都有。

因为这类设备一般用在大型互联网公司的流量入口最前端，以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。

采用 F5 这类硬件做负载均衡的话，主要就是省心省事，买一台就搞定，性能强大，一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能。但是缺点也很明显，一个字：贵。

基于软件负载均衡

软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡，分为7层协议 和 4层协议。

网络协议有七层，基于第四层传输层来做流量分发的方案称为4层负载均衡，例如 LVS，而基于第七层应用层来做流量分发的称为7层负载均衡，例如 Nginx。这两种在性能和灵活性上是有些区别的。

基于4层的负载均衡性能要高一些，一般能达到 几十万/秒 的处理量，而基于7层的负载均衡处理量一般只在 几万/秒 。

基于软件的负载均衡的特点也很明显，便宜。在正常的服务器上部署即可，无需额外采购，就是投入一点技术去优化优化即可，因此这种方式是互联网公司中用得最多的一种方式。

上面讲完了常见的负载均衡技术方案，那么接下来咱们看一下，在实际方案应用中，一般可以使用哪些均衡算法？

轮询策略

负载度策略

响应策略

哈希策略

下面来分别介绍一下这几种均衡算法/策略的特点：

NO1—— Random 随机
这是最简单的一种，使用随机数来决定转发到哪台机器上。

优点：简单使用，不需要额外的配置和算法。
缺点：随机数的特点是在数据量大到一定量时才能保证均衡，所以如果请求量有限的话，可能会达不到均衡负载的要求。

NO2—— Round Robin 轮询
这个也很简单，请求到达后，依次转发，不偏不向。每个服务器的请求数量很平均。

缺点：当集群中服务器硬件配置不同、性能差别大时，无法区别对待。引出下面的算法。

NO3—— Weighted Round Robin 加权轮询
这种算法的出现就是为了解决简单轮询策略中的不足。在实际项目中，经常会遇到这样的情况。

比如有5台机器，两台新买入的性能等各方面都特别好，剩下三台老古董。这时候我们设置一个权重，让新机器接收更多的请求。物尽其用、能者多劳嘛！

这种情况下，“均衡“就比较相对了，也没必要做到百分百的平均。

NO4—— Least Connections 最少连接
这是最符合负载均衡算法的一个。需要记录每个应用服务器正在处理的连接数，然后将新来的请求转发到最少的那台上。

NO5—— Source Hashing 源地址散列
根据请求的来源ip进行hash计算，然后对应到一个服务器上。之后所有来自这个ip的请求都由同一台服务器处理。

>内网 目前阿里云的服务器内网间是千兆共享的带宽，没有特殊限制。由于是共享网络，因此无法保证带宽速度是不变的。 如果您需要两台同地域的 ECS 实例传输数据，一般建议使用内网连接。同时，RDS、SLB、以及 OSS 相关的内网速度也都是千兆共享的环境。这些产品间也都可以使用内网相互连接使用。 目前只要是相同地域下，SLB 、RDS 、OSS 同 ECS 之间 都是可以直接内网互通连接使用的。 对于内网中的 ECS 实例： 只有同一账号、同一地域的实例，默认才会内网互通。 同一账号、同一区域、不同可用区之间内网也互通，即使内网IP地址不是同一网段，也可以正常内网连接。 如果是不同账号间、相同地域下，可以通过安全组实现内网互通，详情请参见 安全组应用案例。 实例的内网 IP 地址不能进行修改、更换。 实例的内网、外网不支持VIP(虚拟IP)配置。 内网 DNS 地址 经常遇到客户修改了服务器DNS配置，再想改回默认却忘记了地址。下面是阿里云线上个地域内网DNS地址，供参数设置使用： 华北 1: 1020272116 1020272118 华东 1: 1014322116 1014322118 华东 2： 1001002136 1001002138 香港: 1014322116 1014322118 美西： 1014322116 1014322118 华北 2: 1020272116 1020272118 华南 1: 1001002138 1001002136 亚太 1001002136 1001002138

如果在本地搭建，我们可以使用haproxy+keepalived方式轻松实现k8s中的负载均衡，但是阿里的ecs不能使用keepalived,所以我们被迫只能使用阿里的 slb了。

既然keepalived的方式不能使用，那我们就使用阿里的slb进行负载均衡呗，由于该负载均衡不需要被外部访问，只提供对k8s集群节点之间的访问,所以我们就使用私网的slb。
[上传失败(image-b02d7-1604545387128)]

我们保证该slb和k8s集群节点的node属于同一个局域网内，具体配置如下

第一步就是监听该slb的6443端口，该端口后端的服务器组分别是3台ecs的6443端口(apiserver服务)。接着我们可以 在master1节点 上执行如下命令

由于后端服务器组的 apiserver 都尚未运行，预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。 如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。

我们在master1节点上创建kubeadm-configyaml文件，用于初始化控制平面节点，如下。

接着我们在master1节点上执行如下命令初始化

最后结果如下

看上面的日志好像是kubelet的问题。我们先确认kubelet是否运行,发现处于running状态。

接着查看kubelet的日志

发现一个奇怪的问题，>NAT网关：类似于路由器，下可接多个服务器，下服务器需要提供服务的话需要做端口映射。
SLB：一种负载均衡服务，可以实现无状态应用请求多服务器负载均衡分发。（多个服务器上都部署一样的无状态程序）

开个玩笑，B站就是Nginx挂了[奸笑]

slb对应的是自建LVS

都行 nginx的话 需要自己购买大额的宽带 非常昂贵 就看你的业务 如果只是偶尔高访问量 不是持续的话 就slb吧

肯定是阿里云slb，slb提供了标准的api接口可以通过api方便快速得完善相关服务配置，很多觉得自己用nginx可以做负载均衡，但实际结果呢？不仅增加了运维成本，在稳定性和安全性上根本没有保证，可以说出力不讨好。当然很多企业是基于自身成本考虑，阿里云slb相对自建nginx来说，成本确实高出很多，而且限制也很多，比如在某一端口下限制代理数量等等。总之公司有钱不差钱百分百上slb，稳定安全，减少运维成本。基于成本考虑自建nginx，需要自己做好各种监控运维策论，付出更多的运维成本，稳定性相对来说没有slb稳定

slb费钱，没有固定的。nginx负载均衡费用可以固定下来。

很多觉得自己用nginx可以做负载均衡，有没必要购买阿里云负载均衡SLB呢？购买阿里云负载均衡SLB和自己用nginx做负载均衡有何区别与优势呢？ 其实自己用nginx做负载均衡就是吃力不讨好，运维成本高，而且很不稳定，相对于直接购买阿里云负载均衡SLB稳定搞、容灾高、多种协议支持、并且运维成本低。

其实nginx现实中大部分都是用来做反向代理了。负载均衡的话有条件还是slb吧，网络层的快一些

一般网站用虚拟主机即可，够用就行，没必要用整台的服务器。
建议你用：阿里云的虚拟主机-普及版（1G网页空间，送50M SQL数据库，支持HTML/ASP/NET/PHP/MYSQL/MSSQL），能备案：150元/年。
可以加咱，在线上。

目前我们公司后台使用clickhouse，来做数据的离线分析；配置为四台集群（shard）
通过springboot+clickhouse-jdbc完成服务与clickhouse jdbc的连接；使用的是clickhouse官方，BalancedClickhouseDataSource(urls,properties)，做到四台服务之间的负载均衡；网上很多资料都表示
这个包虽然可以做到一定程度的负载均衡，但是无法做到故障转移；按照大家的推荐，我本地是nginx搭建clickhouse-jdbc 负载均衡的服务

安装nginx ,参考地址： >