阿里云负载均衡（阿里云负载均衡收费标准）

本文目录一览：

• 1、WebSocket+SLB（负载均衡）会话保持解决重连问题
• 2、想购买阿里云的云主机，看到有个‘负载均衡’，负载均衡是干嘛的，需要买吗？
• 3、假如有10亿人同时去一个网站浏览，都按F5不松手会怎样？

WebSocket+SLB（负载均衡）会话保持解决重连问题

写在最前面：由于现在游戏基本上采用全球大区的模式，全球玩家在同一个大区进行游戏，传统的单服模式已经不能够满足当前的服务需求，所以现在游戏服务器都在往微服务架构发展。当前我们游戏也是利用微服务架构来实现全球玩家同服游戏。

玩家每次断线（包括切换网络/超时断线）后应该会重新连接服务器，重连成功的话可以继续当前情景继续游戏，但是之前写的底层重连机制一直不能生效，导致每次玩家断线后重连都失败，要从账号登陆开始重新登陆，该文章写在已经定位了重连问题是由SLB引起后，提出的解决方案。

每次重连后，客户端向SLB发送建立连接，SLB都会重新分配一个网关节点，导致客户端连接到其他网关，重连失败。

会话保持的作用是什么？

开启SLB会话保持功能后，SLB会记录客户端的IP地址，在一定时间内，自动戚睁将同一个IP的连接转发到上次连接的网关。

在网络不稳定的情况下，游戏容易心跳或者发包超时，开启会话保持，能解决大部分情况下的重连问题。

但是在切换网络的时候，手机网络从Wifi切换成4G，自身IP会变，这时候连接必定和服务器断开，需要重新建立连接。由于IP已经变化，SLB不能识别到是同一个客户端发出的请求，会将连接转发到其他网关节点。所以使用TCP连接的情况下，SLB开启会话保持并不能解决所有的重连问题。

另外某些时刻，手机频繁开启和断开WI-FI，有时候可能不会断开网络，这并不是因为4G切换WI-FI时网络没断开，从4G切换到Wi-Fi网络，因为IP变了，服务器不能识别到新的IP，连接肯定是断开的。这时候网络没断开，主要是因为现在智能手机会对4G和Wi-Fi网络做个权重判断，当Wi-Fi网络频繁打开关闭时，手机会判断Wi-Fi网络不稳定，所有流量都走4G。所以网络没断开是因为一直使用4G连接，才没有断开。想要验证，只需要切换Wi-Fi时，把4G网络关闭，这样流量就必定走Wi-Fi。

上面说过，四层的TCP协议主要是基于IP来实现会话保持。但是切换网络的时候客户端的IP会变。所以要解决切换网络时的重连问题，只有两个方法：1. 当客户端成功连接网关节点后，记录下网关节点的IP，下次重连后不经过SLB，直接向网关节点发送连接请求。2.使用 SLB的七层（HTTP）转发服务。

当客户端经过SLB将连接转发到网关时，二次握手验证成功后向客户端发送自己节点的IP，这样客户端下次连接的时候就能直接连接网关节点。但是这样会暴露网关的IP地址，为安全留下隐患。

如果不希望暴露网关的IP地址，就需要增加一层代理层，SLB将客户端请求转发到代理层，代理层再根据客户端带有的key，转发到正确的网关节点上。增加一层代理层，不仅会增加请求的响应时间，还会增加整体框架的复杂度。

阿里云的七层SLB会话保持服务，主要是基于cookie的会话保持。客户端在往服务器发送HTTP请求后，服务器会返回客户端一个Response，SLB会在这时候，将经过的Response插入或者重写cookie。客户端获取到这个cookie，下次请求时会带上cookie，SLB判断Request的Headers里面有cookie，就将连接转发到之前的网关节点。

HTTP是短链接，我们游戏是长连接，所以用HTTP肯定不合适。但是可以考虑基于HTTP的WebSocket。

什么是WebSocket？

WSS（Web Socket Secure）是WebSocket的加密版本。

SLB对WebSocket的高磨岁支持

查看阿里云SLB文档对WS的支持，说明SLB是支持游喊WS协议的，并且SLB对于WS无需配置，只需要选用HTTP监听时，就能够转发WS协议。说明WS协议在SLB这边看来就是一个HTTP，这样WS走的也是七层的转发服务。只要SLB能够正常识别WS握手协议里Request的cookie和正常识别服务器返回的Response并且往里面插入cookie，就可以利用会话保持解决重连问题。

Go语言实现WS服务器有两种方法，一种是利用golang.org/x/net下的websocket包，另外一种方法就是自己解读Websocket协议来实现，由于WS协议一样是基于TCP协议之上，完全可以通过监听TCP端口来实现。

客户端发送Request消息

服务器返回Response消息

其中服务器返回的Sec-WebSocket-Accept字段，主要是用于客户端需要验证服务器是否支持WS。RFC6455文档中规定，在WebSocket通信协议中服务端为了证实已经接收了握手，它需要把两部分的数据合并成一个响应。一部分信息来自客户端握手的Sec-WebSocket-Keyt头字段：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==。对于这个字段，服务端必须得到这个值（头字段中经过base64编码的值减去前后的空格）并与GUID"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"组合成一个字符串，这个字符串对于不懂WebSocket协议的网络终端来说是不能使用的。这个组合经过SHA-1掩码，base64编码后在服务端的握手中返回。如果这个Sec-WebSocket-Accept计算错误浏览器会提示：Sec-WebSocket-Accept dismatch

如果返回成功，Websocket就会回调onopen事件

游戏服务器的使用的TCP协议，是在协议的包头使用4Byte来声明本协议长度，然后将协议一次性发送。但是在WS协议是通过Frame形式发送的，会将一条消息分为几个frame，按照先后顺序传输出去。这样做会有几个好处：

websocket的协议格式：

参数说明如下：

阿里云的SLB开启HTTP监听后，会检查过往的Request和Response请求，收到服务器返回的Response后，会往Response插入一个Cookie

客户端收到服务器的Response后，可以在Header中查到有个“Set-Cookie”字段，里面是SLB插入的Cookie值

客户端断开连接后，下次发送请求需要往Headers插入Cookie字段

分别在阿里云的两台ECS实例上部署WS服务器，打开8000端口，开启一个SLB服务，SLB服务选择HTTP方式监听，并且打开会话保持功能，Cookie处理方式选择植入Cookie。Demo服务器没有做HTTP健康监听的处理，健康检查这块可以先关掉。

在两台ECS上启动WS服务器，然后本地运行客户端，分别测试两台服务器是否能正常连接，测试完毕后，测试SLB能否正常工作。服务器和SLB都正常的情况下，运行客户端，客户端会得到以下结果

收到的三次Cookie都相同，说明Cookie是有正常植入工作的，并且三次都被SLB正确抓取了。

收到的三次serverId也都是同样的值，说明三次都是同一个ECS上的服务器响应。

至此，验证成功。

Websocket+SLB会话保持能够解决超时重连和切换网络时重连的问题。

参考：

阿里云会话保持

解答Wi-Fi与4G网络切换的困惑

WebSocket的实现原理

阿里云SLB对WebSocket的支持

HTTP Headers和Cookie

想购买阿里云的云主机，看到有个‘负载均衡’，负载均衡是干嘛的，需要买吗？

看访枣腊谨问量，如果局肆访问量很大，而且网站响应延迟比较高就买负载均衡。负载均衡的意思凳基就是把服务器压力分摊到其他服务器上，已达到快速响应，减少延迟。

假如有10亿人同时去一个网站浏览，都按F5不松手会怎样？

网站会崩溃，任何一个网站都不可能承受的住。

我们可以粗略地估计一下，普通键盘的刷新速度最快可以达到1000次每秒，考虑到有很多软件并不需要这么快的响应速度，这些软件会降低这个频率来节省电脑资源。我自己用谷哥浏览器试了一下，按f12打开控制台选择network选项，按住f5不松手（直接在浏览器界面按住f5只会刷新一次，我想这跟题主的本意可能不符）这时候控制台飞快刷新，目测每秒几十次，按10次算的话十亿人按住f5不松手产生的浏览量可以达到100亿每秒。

我们再看一下可能是世界上短时间内并发最高的网站——双十圆薯一时候的淘宝。具体的数据我们没有不过我们可以根据网上提供的一些数据估算一下。淘宝访问最高的时候应该就是十一号零点刚过那几分钟，事实上淘宝交易额增速最快的也是那几分钟，我猜测每秒峰值订单也是发生在这个时候，这个数据是54.4万笔每秒。假设一千个人里边有一个下单的那么当时的浏览量大概5亿每秒。实际上这个时候的淘宝虽然没有崩溃，但是很多页面已经出现了延迟，有很多数据已经刷不出来。而题橘则者中的条件远远超过这个数字，淘宝也是完全承受不住这个访问量的（实际上我已经尽量低估了十亿人按住f5造成的访问量，高估了淘宝在双十一承受的访问量）。我觉得没有任何一个网站可以承受这么大的访问量。

实际上十亿人接近世界人口的七分之一，根本不会有一个页面可以吸引这么多人同时访问，网站在设计的时候也完全不会考虑如此高的并发。

现实中的网站访问远比这个复杂，这里只是做一个很粗略估计来讨论一下，欢迎大家提出不同意见。

看到有朋友在评论中提出疑问，我自己测试了一下，然后看了下Apache的日志21次，只代表我自己的测试，不保证准确，给大家一个参考。

传说中的洪水攻击，其效果就是这样，那会瞬间阻塞网络，导致网站访问慢或访问不到，目前来看也只有阿里有可能承受住

10亿人同时浏览一个网站，并且还按F5进行不断刷新，现实当中没有这样的网站，如果盯局有的话一定是会崩溃的！

但是现实中和题主假设最接近的网站有，谁？那就是经常被全国人民在春运时喷的12306，我们不妨来看看当前12306的流量数据。

2018年的时候铁路官方提供过当年春运时12306的页面流量次数，高峰时期单日PV是1500亿次，平均到每小时则是1500/17=88亿次(注：12306晚23点到第二天6天不售票，这里我就去掉了这7小时)。也就是说12306每小时88亿的访问量，每分钟则相当于1.47亿的访问量。

这个数据量已经是相当惊人了，即便是淘宝双11也是比不上12306的。同时，这里还请注意，铁路官方这里仅仅是说的页面访问量，如果加上数据库的查询、出票等等功能，那么12306所承担的压力会更加大，负荷也更重，因此全球范围内真正牛逼的网站，能承受全国亿人同时冲击的就只有它了，剩下才是淘宝双11的高并发流量冲击。

可以说当前的12306系统超越当前任何一个秒杀系统。

目前12306所承受的访问量还在逐步递增，因为春运走铁路的人群也是逐年递增，很多人疑问为何12306开始线上购票后怎么票越来越难买，还不如当年线下排队购票。其实很多人是忽视了铁路春运人数增长这个现象。

从春运最开始的1亿人次，逐年增长到现在破4亿人次，票显然是越来越难买。这个数字增长其实已经反映了铁路这些年来的运力增长，但这个运力的增长赶不上越来越多民众的出行需求。

今年12306又出现了崩溃的情况，显然买票的人多了。

Lscssh 科技 官观点：

综合技术难度来说，12306实现的技术远比淘宝电商平台要复杂，如果你真的懂技术就会惊叹12306目前所取得的成绩，否则在你眼里肯定是不如淘宝天猫。

首先祝贺我国人民都有闲情雅致去同一个网站浏览。

这个问题，放在8年之前，答案是瘫，你会在网站高峰是很容易看到网站不可访问的提示；放在今天，答案是要恭喜您，这个级别的网站的架构师们，已经同样怀着一颗闲情雅致的心情，把这个问题解决了；就算是自己没解决，也会找武林高手把这事儿解决。最直观的例子就是我国的12306网站。

早些年，当12306在线购票系统刚刚公布不久，春运来了。来自五湖四海的弟兄们怀着回家团圆的热情，一起按F5刷票，把网站搞瘫了。没错瘫了。那个时候，能刷到票的，除了手速，最关键的是运气。

所以从那时起，关于12306的各种负面消息一股脑地涌现出来。大到系统架构、服务器；小到用户体验。甚至在互联网产品经理的交流沙龙上，12306的网站改版竟然成了反面教材，被肆意使用。

12306经历了最初期的磨难，但依然要面对无法躲避的春运、国庆黄金周等难关。12306召集有大数据并发经验的互联网公司们的大牛、架构师们，为网站献计献策，充分优化系统架构；具体改了多少架构；做了多少重构不得而知。而经过时间的沉淀，大家能够普遍认同的是，12306的数据关系，往往比常见的互联网公司要复杂的多。而经历了大并发的多次洗礼，大家感觉到，系统便稳定了很多。

有一年春运，购票系统和以往相比，简直可以用丝滑来形容。12306甚至没给大家留下什么瘫痪的印象。事后，12306和阿里云宣布战略合作。12306向阿里云提出了严峻的挑战，而阿里云不负众望，为12306保驾护航。

其实，大并发一直是信息时代不得不面对的一个问题。12306只不过是一个例子，时至今日，大并发已经衍生出更多复杂的场景。双11我们在畅快购物的同时，偶尔在一瞬间还是会感到大并发带给网站的压力。只不过，用户已经更加从容；因为他们相信，网站有这个技术马上会将瘫痪的服务恢复。等下下就好~

10亿用户并发访问，此等流量目前也还没有一个大型网站能承载。 日前12306就出现了崩溃的现象，有人猜测疑似因流量过大导致。“12306 服务”承受着这个世界上任何秒杀系统都无法超越的QPS，上百万的并发再正常不过了！不过大型网站的访问量大、并发量高、海量数据等方面如果处理不来，没法解决多用户高并发访问问题还是要崩了。

目前淘宝的高并发流量承载水平。 每年的双十一狂欢节是阶段性高并发访问的典型代表，1分36秒，交易额冲到 100 亿 ！高并发系统架构通常采用分布式集群部署，服务上层有着层层负载均衡。根据不同服务器负载能力和配置策略来均衡分配访问流量，保证系统的高可用性。当然，其中还有容灾系统的辅助作用。

2019双十一来说，天猫淘宝每秒交易创建峰值54.5万笔、实时计算消息处理峰值25.51亿条/秒，而用户在购物支付中未感受到抖动、流畅平稳。支付宝技术自主研发的技术之一、分布式数据库OceanBase再次刷新数据库处理峰值，达6100万次每秒。

服务器性能、程序并发处理能力有限。网站在大并发，高负载时就会有瘫痪，拒绝服务的崩溃现象出现。对于“10亿人同时去一个网站浏览”，十亿级别的并发访问，放现在任意一大型网站都难以承载。

负载均衡、合理的使用并发和异步、发挥服务器多核优势…还仍是当下研究和 探索 的重要课题。因需求而演进，最初期的单机架构，到容器化技术实现运行环境隔离与动态服务管理，在现在系统还可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题。并发到千万级亿数级别并发情况也是服务端的架构的不断演进过程。

如果是测试，额，好像这个场景也只会是测试，，看网站类型吧，如果只是浏览网页，做静态缓存，加不算钱的CDN完全没问题

主根服务器，在美国，网络运维预算中国工程师也有杰出吊炸天的专家，在使用网络到现在，目前没有听到过，主根服务器卡爆，您用的网络，是付了钱的，您出多少钱，别人为你提供多少优质的网络服务，网络工程师这点常识不可能没有，不预留兼容空间，常按键盘F5，持续刷新，取决您的电脑cpu是否足够强大，不会影响到别人使用网络的，过流使用网络，各大网络运营商后台，会给您限速的，不可能给你一根网线，让你去开网吧，您出多少钱，您就享受怎样的有限网络限制服务。一块钱成本，想要博得四两拨千斤，肯定不现实，网络工程师可不是光吃白米饭不需要菜的主，不会给黑客留后门让您无节制的使用有限网络，谁会做亏本买卖，所以您试图卡爆主根服务器想法，不会实现。

很有趣的一个问题，从侧面引申出了用户与服务器之间的访问关系，究竟有哪些因素会影响我们的访问呢？题目中已经预示了这个问题：

那么，就从这两个方面来简单分析一下，是否存在同时支撑10亿用户访问的网站吧！

一、关于网站流量的问题讨论

随着互联网的快速发展，网站内容不再单调，一个页面存在图片、音频、视频等多种元素，这给传输的带宽带来了一定的压力。

我们不按照视频播放的特殊情况来计算，仅仅按照一般网页打开高峰值的流量来进行估算。鉴于高清图片，语音，flash等因素，初步估计峰值带宽需要200K每秒。那么，假若10亿人同时访问需要多少的带宽呢？大家不要急，容我拿出计算器好好计算一下，为了便于计算，暂不采用1024的进位，使用约为1000的进位（1M=1024K）。瞬时产生的峰值流量为200000G，也就是200T。当前网络传输最高已经支持100G，但是实际应用场景较少，我们按照最理想100G来计算。

那么单台服务器带宽肯定无法满足10亿人的同时使用，需要200000G除以100G台服务器才能完成这一目标，显然2000台服务器的搭建并不现实（不是无法实现，只不过成本过于昂贵）。

二、关于程序、服务器性能能否支持的问题

我们拿12306、淘宝商城这两个高流量的网站举例，您就会知道10亿人同时访问所带来的压力。

一年一度的春节就要来临，也到了12306最容易崩溃的时间段。这部，前不久12306疑似又出现了崩溃的问题。我们先来看下2018年时12306高峰期的统计数字：

请记住每秒164.8万次这个数字！

再来说说淘宝，淘宝最具参考价值的就是双十一时的用户访问量。据相关统计数字显示，淘宝双十一峰值用户访问数据是每秒4200万次。即便如此，淘宝当晚依然如临大敌，全力保障避免网络以及服务器出现问题。

每秒164.8万次、每秒4200万次与每秒10亿次来对比，可想而知这个数据的恐惧。甚至这里令我想到了DoS攻击（拒绝服务，通过频繁占用资源最终导致网络或服务器崩溃），10亿人同时访问远比病毒攻击要来得更加可怕！

结论是当前不存在同时支持10亿人访问的网站！

对于10亿用于同时接入某网站的问题，您怎么看？

欢迎大家留言讨论，喜欢的点点关注。

很有想象力的一个问题，十亿人同时刷新一个网站，至少目前为止还没有网站能够架得住，按照现在阿里巴巴云计算的能力讲，服务器的组合能力已经优化到一种非常合理化的境界，单纯的依靠计算能力提升的空间已经非常有限了，如果单单是为了应对这些人的冲击构建大量的服务器，毫无疑问将会产生极大的浪费，任何企业都不会为了应对这一攻击而购置大量的服务器。

早期的云计算产生其实也是一种偶然的因素，亚马逊早期为了应对服务器巨大的冲击，购置了大量的服务器，结果发现储备的服务器太多了，就想着如何处理这些多余或者利用这些服务器的额外用处，于是想着如果把这些服务器构建起来给一些中小企业提供服务，而且这些服务器之间还可以进行资源的共享，这就是早期云计算产生的简单的需求，但随着功能的延申云计算所起到的作用也越来越大，亚马逊在这方面投入的精力也是越来越大，但成效也越来越明显，成为亚马逊市值飙升的重要参照因素，而且云计算的诞生对于甲骨文的数据库有非常大的冲击，亚马逊已经宣传旗下的数据库切换到云计算的模式，相信不久的将来阿里巴巴也会完成这一使命。

同时访问一个网站，考验的就是网站的负载均衡能力，现在网站已经不是单一的服务器构造了，不同地区的访问会汇总到不同的区域里面，最后通过数据的交互将数据汇总到总的主控服务器上，然后做出具体的反应从理论上讲，如果想要快速的反应就要求在接受到数据一瞬间就要准确到传递到正确的服务器上，关键是第一步如果访问量过大，第一步接收的服务器可能直接崩溃或者数据被排队等待了，可以想象在双11期间阿里巴巴启动的服务器的数量要多于平时，同时阿里巴巴已经把服务器迁移到阿里云上了，对于服务器的管理能力又进一步增强了，同时又增加了很多的备用服务器来支撑，毕竟阿里云的业务能力也在进一步增强，所以增加备用的服务器也是业务上的需要。

增加服务器的负载能力最简单直接有效的办法就是增加服务器的数量，但这种方式对于成本的要求还是非常高，每家都不会去做这种事情，毕竟如果只是单纯的使用几次这种成本的代价太高，之前的购票网站12306经常出现宕机的情况，最后还是阿里巴巴的阿里云一起协助解决了这类冲击的问题，其实订票冲击相比双11的冲击还是差了许多，解决并发问题的能力上在国内范围最厉害的企业当属于阿里巴巴，12306把查询的功能部署在阿里云上极大降低12306主要服务器的压力，同时也是对阿里巴巴负载能力一个极大的检验。

即使阿里巴巴已经在解决负载能力上有着非常丰富的经验，但是10亿用户同时刷新网站的做法，即使放在阿里巴巴面前也是一个极大的难题，不仅仅是技术能力的问题关键还是在于是否有必要购置这些服务器，希望能帮到你。

按住F5不算啥，部分已加载的是读取本地缓存，ctrl+F5，shift+Command+R才是毁灭性的吧