开发者学堂课程【企业运维之云上网络原理与实践课程：【视频】第四讲-负载均衡ALB+实验三-使用ALB实现灰度发布】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/991/detail/14982
【视频】第四讲-负载均衡ALB+实验三-使用ALB实现灰度发布
内容介绍：
一、前言应用型负载均衡ALB的产品功能
二、课程目标
三、概述
四、相关概念与产品功能
五、技术框架
六、产品优势
七、场景与案例
八、总结
九、实验
一、前言
云网络的概念，包括如下：
云网络的发展，从经典网络发展到 vpc 网络；
云网络的产品，包括 nat，共享贷款包，
云网络的产品和互通的方式；
云网络的运维工具；
云网络相关的协议，包括 tcpip，http 等
SLB 就是 CLB， CLB 与 ALB 相似，CLB的产品包括 CLB 负载；CLB 的监听配置，包括4层7层的区别，电杆检查，服务器组等相关组件；CLB 主要的内容包括 CLB 常见的异常问题的分析，例如无法访问后端以及常见的异常状态码诊断。
vpc 相关的产品，包括 vpc 的网络底层事件， vpc 网络的内容。
1、创建 service 暴露服务
如果要知道 SLB 是如何结合 ack 和 ex，就需要有 K8S的相关的知识点，K8S中比较重要的组件称为 service，也就是服务， service 是K8S中的专有名词，也是重要的组件，service 的意思就是服务，可以是整体的服务或微服务，服务就相当于提供的应用称为服务，因为K8S中有很多 Port， Port 就是容器组，service 有很多 Port 的集合，类似于负载均衡 SLB，但是它是虚拟的负载均衡。
2、什么是 service？
service 提供访问的入口，外部请求不能直接访问容器，因为容器中的 Port 就是容器中安装的真正应用和服务，因为在 K8S比较灵活、弹性、自由，很多都是无状态的，无状态就是生成和销毁不会有数据存储，是状态无关的，所以 Port 在调度和生成的时候比较随机，不要求 Port 有固定的 IP，也不要求 Port 固定在某些服务器上，所以如果直接访问 Port，首先对应的 IP 不能固定，而且 Port 的多少也不能固定，因为 Port 比较弹性，例如业务增长，Port 可以根据业务的请求情况自动弹性伸缩，所以以 service 服务来代表所有的Port集合，架构类似于 SUV，相当于设备是虚拟的负载均衡器，外部请求只要固定的访问到设备服务的 VIP 就可以，由 VIP来负载均衡，把它自动转发流量到后端的 Port 上，Port 只要有增加和减少，设备都会自动更新的规则和策略，所以增加减少对外部请求的客户端是不感知的，所以所有的策略都是由 K8S自动完成，就是 service 的概念。
3、service 类型
service 主要有以下三种：
（1）ClusterIP
分配一个集群内部的 IP 地址，只能在集群内部访问。
service 需要提供 VIP 的虚拟 IP，ClusterIP 相对于在集群内，单独分配给 service 用的 IP，称之为集群内的 IP，称为 ClusterIP，ClusterIP 只能在集群内部的访问，在 K8S集群内才能访问到的 ip 称为 ClusterIP，如果是在集群外部，或者在公网、在外部网络，ClusterIP 无法访问到，因为不是对外的，只有在集群内部才能访问，即使是相同的bbc的内网的其他 ecs，如果 ecs 不在集群内，也无法访问，ClusterIP 只能在集群内部被访问。
（2）NodePort
分配一个集群内部的IP地址，并在每个节点上启用一个端口来暴露服务，可以在集群外部被访问。
service需要提供VIP的虚拟IP，ClusterIP相对于在集群内，单独分配给service用的IP，称之为集群内的IP，称为ClusterIP，ClusterIP只能在集群内部的访问，在K8S集群内才能访问到的ip称为ClusterIP，如果是在集群外部，或者在公网、在外部网络，ClusterIP无法访问到，因为不是对外的，只有在集群内部才能访问，即使是相同的bbc的内网的其他ecs，如果ecs不在集群内，也无法访问，ClusterIP只能在集群内部被访问。
（3）LoadBalancer
分配一个集群内部的IP地址，并在每个节点上启用一个端口来暴露服务，除此之外，kubernetes会请求底层云平台上的负载均衡器，把Node节点作为后端添加进去。
Node 在 K8S中指的是一台 ecs，也就是一台虚拟机， Port是指 Node 中的容器，Node Port 相当于是ecs上的监听端口， 如果ecs中有Port，外面是 Node，可以运行很多 Port，Node Port 是指ecs监听的端口，可能是3333在ecs上鉴定端口，假设外部请求访问的是 ecsip，加上端口333，会把请求再通过的iptf转发，转发到 Port中，假设是外部服务，一般监听80端口，或者43端口，所以NodePort需要做映射，客户端访问的目的 ip 是 ecs 的ip加上ecs的监听的端口，通过ipvs转换规则，转发到Port中，Port 是真正的应用，首先 ip 会变成 Port 的 ip，端口会变成 Port 的端口，就是80和43，有对应的转换，这是 Node Port类 型的 service。
LoadBalancer，会生成云厂商的负载均衡的服务，会把ecs加入到负载均衡的后端，相当于会把ecs加入到负载均衡后端的服务器组，整体架构如下 ：
LoadBalancer类型的service流量链路
LoadBalancer类型的设备，会创建SLB，假设有4台Node，相当于4台ecs，会加入到虚拟服务器组，虚拟服务器组会加入到一个组，把组加入到SLB的后端，SLB会把流量分发给Node，Node上就有端口转换规则，其转换的端口，并不是的业务端口，并不是Port真正的业务端，可能是333端口，当ECS收到请求流量时，再把真正的流量发给Port业务，类似真正业务的端口，以上就是典型的SLB结合K8S的应用场景，需要有K8S的相关概念，如果站在SLB本身的视角，无法识别后端到底是否是k8s是SLB是正常的其他流量，只是把流量分发给后端的ess，ess再进一步处理，判断是否发给Port进一步处理。K8S中有两种模式，一种模式称为classic模式， classic模式会把集群中所有的Node节点，加入到SLB的后端，假设业务是redis，redis只在NODE2和NODE3上，但是会把所有的节点都加入到后端，但是当客户访问redis，如果分发到NODE2，NODE2上并没有redis，如果没有，Node2会再做一次转发，转发到1或者3，因为只有1和3上有真正的业务服务器，好处就是可以不用经常去维护后端的Port情况，即使后端Port在删除和减少或者增加的时候，也不需要去更新后端的服务器，因为已经默认所有的都转发，再经过节点上做一次转发就行，坏处是要做两次跳转，如果第一次转发正好命中，服务器上没有业务，还需要再次调转。
local 模式与之前的规则不一样，假设 service 负载 SLB 类型的设备，它提供的是个redis 服务器，redis 服务器只会把 redis 所在的对应的 ecs 节点加入到后端，只在Node 1和 Node 3上有 redesPort，只会把 ecs1和 ecs3，加入到后端，在转发的时候会精确的转发给 NODE1、NODE3，直接转发给 radios 应用，就不需要转到webNODE4。假设 NODE3的redis挂，就要更新规则，把这台 NODE3从后端移除，假如在 Node4上又起 redis 应用，就需要把这台 ecs 加入，就会有调用更新的过程，这是区别。以上是 KBS 结合 SLB 的应用场景。
KBS 中的结合 SLB 应用的第二场景称为 ingress 的场景：
Ingress是一种k8s资源对象，用于对外暴露服务。该资源对象定义不同主机名（域名）及URL和对应后端Service (k8s Service )的绑定.根据不同的路径路由http和https流量。而Ingress Contoller是一个pod服务，封装一个web前端负载均衡器，同时在其基础上实现动态感知Ingress并根据Ingress的定义动态生成前端web负载均衡器的配置文件，比如Nginx Ingress Controller本质上就是一个Nginx ,只不过它能根据Ingress资源的定义动态生成 Nginx的配置文件，然后动态Reload。ingress是统一对外的服务入口，例如官网的用户端，要访问真正的业务称为ingress，常用Nginx做，称之为Nginxingress控制器，通过ingress，转发给后端，SLB结合场景如下：
ingress 本身就是 service，先要有4个设备，才能创建，ingress 本身是一组 Port：
原则：
●Pod 多副本，避免单点故障
●Ingress controller 部署在单独的节点，避免其他应用抢占资源
●根据业务流量水平扩缩容ingress节点或者Ingress controller水平伸缩
ingress本身也是服务，在场景中也是一样的，把对应的服务和对应的ecs，加入到SLB后端，就是4层的监听，会把流量分发给对应的ecs节点，ingres作为流量分发，策略执行，例如有很多域名或很多服务，由ingress作为统一入口，由统一入口来判断，真正的服务是哪个，转发到对应的服务，例如在微服务场景下，就是应用订单服务，或者购物车、首页等每个服务，都可以单独作为应用部署。所以通过ingress分发请求给对应的服务，以上就是结合场景。
路由-Ingress
SLB 结合 ingress 也是类似的，ingress本身是一个分布式服务的框架，本质就是把不同服务所在的ecs，或者Node节点加到SLB后端。
二、课程目标
1、了解应用型负载均衡ALB的产品功能
2、了解应用型负载均街ALB底层架构与相关技术
3、掌握应用型负载均衡ALB的产品优势
4、熟悉应用型负载均街ALB的使用场景
三、概述
1、用户核心痛点与诉求
最初的网络在2,000年，一般的应用都是WEB应用，或者是音视频应用，都是流量比较小的，或者场景比较简单的，发展到现在，应用最多的是短视频，短视频的应用包括直播应用，有很明显的特点，就是流量特别大，包括在线人数，一场直播可能有几十万人，所以视频流量非常大，对视频场景的要求很高，而且用户对延迟体验要求也更高的。这是业务和用户的视角。如果站在技术人员的视角，最早很多业务都是单体的价格，会把所有的内容都打包到APP中，通过APP来服务，如今很多应用会做分布式，一是提供高可用，二是容量更大，所以会从单体扩展到分布式，包括微服务的架构，为安全考虑，可能会部署到多云，甚至混合云，混合云就是同时使用IDC和公共云两套，或者多个云厂商，使用一套，实现负载，当可用区异常，或者其中云厂商有异常，可以快速切换。不仅对架构是要求是比较高，而且对网络要求也非常高，这是网络发展情况。
从发展情况，可以看出来有很多痛点：
（1）超高可用：Always Online对业务高可用提出更高要求
①健康检直 ②可用区容灾 ③地域级容灾
是对可用性的要求比较高的，如果普通的应用场景，可能都要求多可用区，或者融灾可用区，对可用性要求越来越高；
（2）5G/IOT时代的来临互联网将迎来更大的流量洪峰
①更大的并发连接 ②更大的带宽 ③系统有着更好的弹性
对弹性的要求高，因为很多业务场景，都是有比较高的弹性，例如促销活动，业务流量是平视的，可能是好几倍或者好几十倍，所以这种场景对弹性的要求会特别高；
（3）业务复杂度的攀升需应用更快速的交付
①面向应用的负载均衡 ②高级路由、 流量镜像等功能支持 ③面向云原生的快速交付模式
是对应用的方向要求会高，因为应用越来越复杂，价格也是越来越复杂，特别是应用结构之后，各种服务之间调用可能比单体之间会更复杂，会涉及的东西更多，所以这也是重要痛点。
（4）复杂的网络环境对安全和运维，便利性提出更高要求
①抵御DDoS攻击 ②WAF内用层防御 ③HTTPS安全加密
是对安全也更看重，包括攻击、网络环境可能会经常受到境外攻击。
基于这几点痛点和诉求，包括网络发展现状，引出ALB的产品，来解决这些痛点和诉求。
四、相关概念与产品功能
1、负载均衡SLB产品家族
（1）负载均衡SLB ( Server Load Balancer )是阿里云负载均衡产品的统称，一种对流量进行按需分发的服务，通过将流量分发到不同的后端服务来扩展应用系统的服务吞吐能力，并且可以消除系统中的单点故障，提升应用系统的可用性。
（2）SLB负载均衡具有即开即用，超大容量，稳定可靠，弹性伸缩，按需付费等特点。
（3）根据不同应用场景分为︰主要基于7层(HTTP/HTTPS)的应用型负载均衡ALB、主要基于4层(TCP/UDP)的传统型负载均衡CLB。
应用型负载均衡ALB( Application Load Balancer )是阿里云推出的专门面向HTTP、HTTPS和QUIC等应用层负载场景的负载均衡服务，具备超强弹性及大规模七层流量处理能力。ALB具备处理复杂业务路由的能力，与云原生相关服务深度集成，是阿里云官方提供的云原生Ingress网关。
传统型负载均衡它主要专注于4层，7层也支持，但是7层的功能会比较少，而且没有应用型负载均衡更强。
2、什么是应用型负载均衡ALB
应甲型负载均衡ALB ( Application Load Balancer)是阿里云推出的专门而向HTTP、 HTTPS和QUIC等应用层负载场景的负载均衡服务，具备超弹性及大规模流量处理能力。ALB具各处理复杂业务路由的能力，与云原生相关服务深度集成，是阿里云直方提供的云原生Ingress网关。
应用型负载均衡ALB具有即开即用，超大性能，稳定可靠，弹性伸缩，按需付费等特点，更加适合7层应用交付场景。
应用型负载均衡ALB面向7层，支持HTTP/HTTPS/HTTP2/WSS/QUIC/GRPC等众多协议，单实例可支持高达100万QPS，业界性能遥遥领先。
3、为什么需要应用型负载均衡ALB
应用型负载均衡与传统负载均衡的对比，首先定位就是7层的ALB，面向于httpp等7层的协议，SLB主要是4层的更强，
二点ALB支持基于mfv的虚拟化平台，支持弹性伸缩的功能， nfv就是network focusion fertilization，就是网络功能虚拟，把网络的功能虚拟。传统的网络功能，都是硬件设备，例如防火墙，就需要摆防火墙的设备。nfv就把硬件的功能，虚拟化的功能通过软件实现。ALB就是基于nfv平台来支持， CLB是基于物理机的架构，服务器需要提前部署，例如10台或者100台，部署完以后，就不能很快的扩展，只能再购买新的物理机，再把物理机加入到群，才能做横向扩展。如果是基于nfv虚拟化，可秒级的弹性扩展，可以支持100万qps，而且如果业务比较低，只要付1000QPS的费用，按照业务增长弹性支付，不需要提前购买大规格的实例。支持丰富的7层特性，包括基于内容的路由http、重写、限速等功能，在CLB的场景下，只支持域名转发，包括GDP头的识别等等。云原生Ingress网关。支持流量拆分、镜像、灰度发布和蓝绿测试。ALB典型的场景就是在7层场景下高自动弹性，还有视频大流量延时的场景。
4、与自建应用负载均衡对比
ALB产品与自建的区别如下：
（1）自建应用负载均衡
协议：主要支持基础协议。如HTTP、HTTPS等，受限于版本关系；
性能：性能受限于自建Ngnix的ECS能力，或者第三方镜像，性能不足；
安全：没有默认的主动安全保障需要自己部署和维护安全方案；
弹性：无弹性能力;扩容，缩容涉及资源评估及购买，操作繁琐；
可靠性：单点部署,最多时双机部著,可靠性依赖ECS部署关系；通过四七层分离，多一个故障点；
运维：需要经常性升级软件；故障处理繁琐复杂；
（2）应用型负载均衡ALB
协议：支持丰富协议，如HTTP、HTTPS、HTTP2、wSs、QUIC、GRPC0，送代更快；
性能：基于弹性架构的高性能；单实例支持100万QPS；
安全：默认5G的DDoS防护能力；支持一键集成WAF能力，应用层更安全；
弹性：随业务而动的自动弹性，无需干预；
可靠性：基于集群的可靠性能力，单实例本质是在集群承载，完全避免可靠性问题，客户也无需关注可靠性部署；有障自动恢复，无需人工介入；一个实例一个节点更简单；
运维：完全无此操作，无需主动升级，新功能自动在控制台呈现；
如果是自建，需要依赖于服务器的性能，即使用特别大规格，与ALB比起来，也差的是比较远的，而且的安全性也没有ALB高，因为ALB支持提高wifi的能力，不用太多的配置，就支持配置wifi。ecs的弹性会比较慢，虽然ecs没有弹性伸缩，但是ecs弹出来之后，肯定要配置或者应用扩容等等，可能弹性操作没有ALB简单。如果要做像ALB一样高可用，就需要做多集群，或者多可用区的部署，对运维也是负担，原生就支持多可用区的概念，不需要额外考虑高可用。
5、ALB应用型负载均衡关键特性
ALB有三大特征：
（1）多级调度实现超高弹性
多级调度确保流量均衡单实例支持高达100万QPS
ALB同时向客户交忖域名与VIP
●DNS域名调度噙保流量在可用区间均衡分配；
●VIP调度确保流量在后端服务器间均衡分发，并且支持一致性哈希与会话保持
（2）丰富且强大的基于内容路由
支持多种内容匹配策略，并支持重定、向重写、标头改写等转发策略
（3）业界最先进的协议支持
从应用层到传输层，ALB支持最先进的协议，让应用更快更安全
拓展：最老的http协议是http1.0，到后来的http1.1，再到现在的http 2，应用比较广。协议的发展，也是基于业务的发展，也是基于使用的发展、网络的发展，现在的各种科技或者各种协议都是为解决实际的问题，所以，为什要与APP协议的发展。http1.0的特点就是使用的是短连接，在tcp连接中，只能发送一次http请求，每发http请求都需要单独建立http连接，会消耗比较多与业务的流量不相关的流量；第二点就是延时的浪费，因为每次请求，都会要建立tcp连接，因为三次握手的过程延迟，消耗也比较大，所以发展出来http 1.1，在http 1.1中，对场景做优化，在tcp连接中它可以发送多个http请求，发送多个APP请求，相当于可以不断开连接，可以连续发，但是连续发有顺序要求，例如发123请求，但是要求响应的时候，也需要响应的顺序也是123。在http 1.1发展之后，又遇到问题， http支持压缩的，压缩的常常是data部分，请求头的部分是无法做压缩的，但是很多场景，请求头也会占用比较大流量，也不利于的传输，所以就发展出http2， http 2在请求头上做改变，首先以二进制的方式，不再以文本形式，二进制的传输效率更高，字节会更小，而且会对重复的或者常用的字段，会简写标头，来进一步压缩头部。http 2中，可以不按照顺序来发送请求和响应，例如的请求是123，响应可以是231或321这种形式的响应，http2相对http 1.1有非常明显的提速。例如可以打开浏览器，右键调试模式，会加载特别多的信息，包括图片、 GS文件、CSS文件等等，会打开很多信息，打开每个文件或者信息就是具体请求，http2会更快响应内容。quick也是为解决http 8的问题，虽然不要求http层的响应顺序，但是如果在TCP层发生丢包，要求有重传机制的，只有在TCP层面重传完，才能正常接收完整的流量，这是TCP的限制。 tcp协议无法更改，后来就发展出http 3，也就是quick协议，底层四层，不使用tcp，不用让htcp上，如果丢包，就不需要再有对头用色的这种情况，就需要quick协议本身去做丢失的判断，包括异常的判断，由应用层本身去判断包有没有丢失。
五、技术框架
1、应用型负载均衡ALB如何工作-概览
ALB的整体大图如下：
●ALB面向应用层，提供域名与VIP，多级分发承载海量请求
●ALB可在可用区间弹性缩放，避免单可用区资源瓶颈
●ALB通过EIP+共享带宽提供公网能力，实现灵活公网计费
●ALB允许用户自定义可用区组合，适应原有计算资源的分布
ALB有较明显的特征，ALB创建完ALB实例的时候，会分配给ALB域名，解析ALB域名的时候，会解析到多个vip，如果是内网，可能是内ip，如果是公网就是公ip，一般是在多可用区部署，如果解析到3个ip，3个ip属于不同的可用区，原生支持多可用区的负载，ALB后面可以挂很多服务器组，每个服务器最后可以挂不同的资源：
2、应用型负载均衡ALB如何工作-示意图
以下是负载均衡的整体情况：
一般的情况都是httpv和gdps的请求，客户端发送请求给ALB，ALB首先需要有监听，端口后面，会有转发规则，匹配转发规则后，转发到对应的后端服务器组，服务器组就是对转发规则提供的一种服务器。同时会有很多运维的功能。
3、应用型负载均衡ALB如何工作-概览
• 监听是ALB最小业务单元，监听上需要配置协议与端口以告知ALB需要处理什么流量，如HTTP协议，80端口。
• 每个负载均衡至少有一个监听，才能开始流量处理与分发。
• 每个ALB可以配置多大50个监听 ，用于处理不同的业务流量。
监听要选择监听协议和监听端口，监听协议就是7层协议，7层协议有httpb协议、httpbs协议、quick协议和gipc协议，主要是这四种协议应用层。端口也是自定义，可以是80或43，但是这是常规的定义版，但是也可以配置别的端口，例如配置8080或者8,000，一般来说是默认端口。
4、应用型负载均衡ALB如何工作-服务器组
• 服务器组是一个逻锡组，包含多个后端用用于处理ALB分发的业务请求。
•ALB中服务器组独立于ALB存在，可以将同一服务器组挂载与不同ALB后端。
•服务器组最大可以包含1000个后端
•ALB服务器组支持云ECS、ECI、ENI等多种类型后端
服务器组就是把一组提供相同服务的服务器集合成虚拟组，组中可以是ecs，也可以添加eci，eci就是容器，弹性容器实例，也可以是ENI，ENI就是弹性网卡，只加弹性网卡，但是弹性网卡添加到服务器上，例如在一台ecs上，它可以绑定多个弹性网卡，把对应弹性网卡加入监听服务器组，监听服务器就会把对应的流量，转发到弹性网卡上。
5、应用型负载均衡ALB如何工作-健康检查
• 健康检查是ALB至关重要的工作机制
• ALB探测服务器组中不健康滅的后端，并避免将流量分发给不健康的后端。
• ALB支持丰富灵活的健康检查配置，如协议、端口、以及各种健康检查阈值。
• ALB提供健康检查模板，可将健康检查模板快速的应用到不同的服务器组。
健康检查的作用就是去探测业务的健康，如果没有健康检查，无法感知到后端的业务服务器是否正常，或者是否提供服务，假如没有健康检查，后端有3台服务器，其中一台服务器宕机，或者一台服务器的应用可能挂，负载均衡会转发到这台服务器上，业务就会异常，如果配置健康检查，就会去探测服务是否正常，如果响应正常的状态，就认为正常服务的，所以健康检查是为高可用，性能提供的功能。健康检查提供多个健康检查的模式，可以使用TCP的健康检查，也可以使用HTTP的健康检查，TCP的健康检查，只会探测服务器的接听端口是否是正常的打开，探测模式会发3次握手，如果ecs回复，就认为是正常的。如果是选择http健康产检查探测，就需要发几个http的请求，在之前，会先建立tcp三次握手，发http请求，请求完之后，如果ES服务或者应用服务，返回正确状态码，例如返回200，说明服务是在正常工作的，才认为服务是正常的，才会持续把请求流量转发到这台服务器上，健康正常和不正常，都有预值的，例如会探测两次，每隔两秒探测一次，失败时间是两秒会有预值，后面连续探测两次失败，才会显示任务失败，连续探测两次成功才认为成功，在预值之内，可能会等待几秒钟，才会切换，依据业务的敏感程度来配置的预值和时间间隔时间。
6、应用型负载均衡ALB如何工作-转发规则
• ALB具备强大丰畜的基于内容路由的能力
• ALB路由转发规则可基于域名（host)、路径（url）、查询宇符串、HTTP标头、Cookie、Http Method等条件进行匹配。
• 可支持转发（Forvard)、重定向（Redirect）、重写（Rewrite）、返回固定响应、插入HTTP标头等动作。
• 每个监听可以支持多达100条转发规则。
转发规则是ALB较强的功能，它可以在监听收到之后，匹配规则，根据规则转发到不同的服务器，越来越多企业和用户，需要更多的规则，因为可以减少ALB的维护，例如有很多域名，如果没有规则，很多域名，每个域名都购买ALB，首先费用会比较高，而且运维也不太方便，用ALB为入口，运维转发会比较简单。
7、丰富的自定义规则属性
转发规则有对域名的匹配规则，例如指定的某个域名做判断或者对路径做判断，http header就是http请求头， ua就是使用的是什么客户端。对查询字符串的判断，对http请求方法做判断。例如去访问访问百度：
* Connected to www.baidu.com (110.242.68.3) port 80(#O)> GET / HTTPZ1.1
> User-Agent: curl/7.29.0>Host: www.baidu. com> Accept:*/*
<HTTP/1.1 200 OK
< Accept-Ranges: bytes
<Cache-Control: private，no-cache，no-store，proxy-revalidate，no-transfor
<Connection: keep-alive
<Content-Length:2381
< Content-Type: text/html
< Date: Tue,26 Apr 202211:55:14 GMT
<Etag: "588604c1-94d"
发送http请求，连接百度的ip，端口默认80，第一行就是请求头，请求头中有几个元素，第一段就是请求方法，常见的就是get、header、delete等等请求方法，中间这一段就是请求的url，默认是斜杠，如果可以指定url，就是具体的url内容，第三块就是请求协议，默认是http1.1，也可以用http1.0。请求头称之为http header，head中有不同的header，其中一个head就是aua， sf就是接收的东西，响应体是body。请求头中也有请求，但是get请求是不包含httpdata，如果是使用post请求，例如上传post的表格或post的文件、post的内容，是在body中。以上是完整的http请求，包括请求行、请求头、请求体、响应行，响应头、响应体，以上是针对7层协议做规则判断。浏览器访问的也是类似的，匹配规则做操作，例如转发操作等等。
8、 支持全链路https加密
ALB是反向代理，客户端发送请求，与ALB建立三次握手，会请求发给ALB，ALB 7层监听也是类似的， ALB再发送TCP的三次握手，与后端的ecs建立三次握手，然后tcp连接，连接之后，再进行ecs握手或者ts握手，再传http内容。零信任就是新一代的网络安全防护的理念，它的关键在于打破默认的信任，用一句话概括来就是持续验证，永不信任，默认不信任企业网络内外的任何人、设备和系统，基于身份认证和授权重新构造，访问控制和信任基础，从而确保身份可信、设备可信、应用可信、列入可信，在这种场景下，在部署业务或者在开发业务本身的时候，就要求不管是否是vpc，就要求业务本身是加密的流量，基于这种场景，http就支持来回加密的场景，但是在传统的CLB场景下，是无法支持的，只能是http铭文的回源。
9、率先支持更高效安全的TLS1.3加密协议
ALB支持tlc 1.3，不向下兼容，因为版本越高，越安全，移除很多md 5，xr 24等等较弱的密码散链，算法可能会更安全，交互会更快，在tlc1.2中：
首先会发送hello，server就是加密的算法，服务端会返回算法，包括证书，最后服务客户端会发送key信息，在交互完成至少要有两个r t t，两个来回，才能完成tls握手，tls1.3可以一次性发送，服务端回过来，包括key信息，在一个rtt中就完成，所以tlc1.3在交互上也更优，所以特点就是更安全、交互更快，所以ALB支持tlc1.3。
10、 支持多证书灵活配置
• ALB的 HTTPS/SSL 类型监听器中增加对 SNI 协议的支持，从而保证一个HTTPS监听可配置多个域名证书 ，在收到来自不同客户端的域名请求时，返回不同的服务器证书，建立正确的HTTPS会话链接，避免出现https访问浏览器频繁提示告警的情况。
如果要配置多个域名，多个域名需要配置多个证书的，这里的多域名是真正的不同的根域名，例如百度或者阿里云，这两个根域名都可以配置到一个负载均衡上，通过SSL，SSL就是tls协议中可以支持sni的字段来支持证书的识别，ALB的 HTTPS/SSL类型监听器中增加对SNI 协议的支持，从而保证一个HTTPS监听可配置多个域名证书，在收到来自不同客户端的域名请求时，返回不同的服务器证书，建立正确的HTTPS会话链接，避免出现https访问浏览器频繁提示告警的情况。不能用host来去识别不同的域名，因为发送http请求之前，已经完成 tls握手。访问的是https，首先会tcp三次握手，访问默认的43端口，以下就是ts握手过程：
*SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
subject: CN=baidu.com, 0=""Beijing Baidu Netcom Science Technology Co.,Ltd" ,OU=service operation department
*L=beijing,ST=beijing,C=CN
start date: Feb 2108:42:022022GMT
expire date: Aug 0201:16:03 2022 GMT
common name: baidu.com
issuer:CN=GlobalSign Organization Validation CA - SHA256 - G2,0=GlobalSign nv-sa，C=BE
证书是百度，客户端验证正确之后才会发送http请求，所以在握手过程之中，不知道host的情况。有各种加密算法，传各种不同的服务端，服务端会找算法匹配。Sni在扩展字端中，称为 Server Name Indication extension 字段，通过字段，服务端就能知道域名，服务端会返回域名对应的证书，可以在SLB上部署多个域名来进行请求。基本上客户端和服务端，都支持sni模式，在老的客户端厂家，例如windows XP，或者更早的版本，或者特殊的软件，可能不会带sni 字段，如果不带sni字段，相当于服务端或者ALB，就无法识别请求哪个域名，就会返回默认的，握手就会失败。
11、 控制台丰富易用性功能
每个产品都有配额，可以通过配合管理自助的申请，申请也是自动审批，根据规格或者使用情况，会有自动化的审批规则，如果申额度变满，申请建立是少量调整申请，申请如果是符合要求的，可以通过，如果已经达到上限就会拒绝。删除保护功能，删除保护就是为防止意外的删除和意外的修改。 tls自定义安全策略，这里不仅仅支持tlc 1.1，1.2各种版本，还支持各种加密套件，在加密套件中，可以指定某几项或者最安全的几项来勾选，可以灵活自定义功能，还支持黑白名单，例如把恶意的请求加入到黑名单，或业务只对公，只提供给某些企业用户使用，就把ip加入白名单，其恶意的请求，或者其不想被访问的，都会拒绝。
12、 ALB丰富产品功能汇总
路由功能基于策略。运维的指标，可以通过指标来更好的监控业务，及时做动作；出现异常，可以通过指标来进行故障排查。
六、产品优势
1、应用型负载均衡ALB的四大核心优势
如下：
超强性能：单实例支持高达100万QPS
安全可靠：多种容灾方案集成DDos、WAF防护
面向云原生：与ACK/SAE/K8S深度集成，云元生Ingress网关
开箱即用：秒级创建实例即开即用，用完即走
2、 ALB多级容灾:实现业务永续
四级高可用容灾架构、业务Always Online，DDoS与WAF防护为业务安全保驾护航。
ALB高可用功能，支持健康检查；多集群的部署；地域高涌，比如北京和上海或者北京和深圳，支持两地高可用的集群，再通过gtm实现地区的高可用，云盾功能，防护常见的流量攻击。
3、 云原生的负载均衡:与ACK/SAE/K8S深度集成
新功能上线灰度发布实现功能快速迭代：
在传统的CLB场景下，部署在k8s集群中的Port，但是如果把ALB作为Controller，不需要在K8S集群中再重新部署，相当于把 slb的功能和ingress的功能都集成在一起，简化网络情况，可以直接在ALB中做路由，策略等等，通过ALB 来做流量分发的动作。
大促前使用线上真实业务流量仿真：
ALB还支持流量镜像的功能，由于经常会有测试版本，通过流量镜像，镜像的流量是客户的真实的流量，可以用客户真实流量，对业务进行压测，用真实流量压测，会较真实的模拟线网的情况。国家监管机构要求企业提供业务真实的流量数据做分析，该场景下，可以做流量镜像，把流量镜像到非业务的ecs上，在ecs上做流量采集，会避免影响线上业务，如果没有该功能，只能在线网的业务上做流量采集，业务量较大的情况下，会占用业务的CPU或者资源的，可能会对业务的性能有影响，如果有流量镜像，会避免影响线上的业务，镜像的流量对ALB本身没有影响，也可以避免对业务产生抖动。
微服务架构中实现快速服务发现：
ALB支持快速发现和新服上线，可以自动发现故障或者新版本与旧版本的替换。ALB 对于云原生和K8S的场景集成度比较高。
4、 ALB简单易用∶开箱即用简单便利
●秒级开通：秒级开通，弹性伸缩，按量付费，7x12免运维。
●完善的监控：完善的监控项，支持事件告警，服务器组级别，（不）健康实例数。
●丰富的日志：配置审计日志，7层访问日志，数据一键挖掘（SLS）。
●与WAF集成：一键开启WAF。流量透明接入，无需修改域名配置。
ALB的应用性很高，包括开通方式很快，弹性高，支持很多的监控，支持很多高点，可以配置不同高点策略，支持不同的监控情况，通过监控指标及时做运维，如果提前配置监控指标，在业务异常或者在业务没发生异常的时候就感知到异常，例如配置连接数的预值或者qps预值，提前有预警的功能。支持日志分析，分析访问哪些域名比较集中，根据这些流量的分析，挖掘对应的域名或者URL，查看是否是集中异常攻击或异常的请求等等。一键开启WAF，并不需要再做额外的配置，点击开启，不需要去再修改cname和做业务改造，无损比较小。
七、场景与案例
1、通用场景∶应用型负载均衡ALB典型应用场景
ALB应用场景如下：
7层高弹性:大互联网场景
弹性伸缩、弹性付费不感知规格,超大容量如:电商/游戏/宣金/媒体等。
QUIC:音视频行业低时延场景
更快的建连时间首屏打开时间更短
如∵长短视频/直播/在线教育等
面向云原生:金丝雀蓝绿发布
基于header/cookie的路由重定向/重写等高级7层特性
2、典型案例-某跨国企业上云项目
秒集突增种的情况下，对弹性要求特别高；音视频的业务对延迟要求比较高的场；云原生的场景， ALB集成度比较高的，支持丰富的基层的特性，可以完美的集成到云原生的场景下。典型案例如下：
改造前：
对外是客户端访问 SLB的入口，SLB一般是加密流量，做4层的负载均衡，会把流量引流到后端的ecs，客户用第三方厂家的镜像，做转发，把流量转发给清洗设备，清洗设备再到WAF安全设备，通过流量清洗，把流量转发回自定义镜像，让负载均衡的服务器把真正的业务网，转发给后端的业务集群。
改造后：
使用ALB产品，ALB本身支持负载均衡和转发的功能，因为支持很多丰富的7层负载均衡，所以直接流量发给ALB，ALB把流量通过匹配策略，默认发给外部集群，外部集群把流量转发回给ALB，ALB通过策略，例如识别流量，把真正的业务往后转发给真正的业务端，改造后只需要使用ALB，能够减少链录。ALB支持比较灵活的转发规则，ALB可以直接实现转发的功能，以上是较典型案例。
八、总结
1.相关概念
互联网发展的概述:从文本到音视频，包括用户对网络使用的痛点、安全高可用等等，通过发展趋势和痛点引出ALB产品， ALB的特性是高弹性、支持丰富路由、支持较多路由协议的转发策略。
2. 技术架构
ALB的技术架构，包括：
（1）监听支持很多协议；
（2）服务器组中，支持不同的后端实例，有ecs与eci容器实例
（3）健康检查支持TCP协议的健康检查，httv健康检查支持HEAD的方法和get的方法，head的方法，就只请求头，不需要返回HTTPbody，可以节省后端的业务流量；
（4）转发规则，支持很多域名路径及不同的规则；
（5）支持全电动加密，支持gdps；
（6）ALB支持tls协议，它可以支持tls1.3，可以自定义tls的加密套件，因为监控支持较多监控指标。
3.产品优势
产品优势主要有四大部分。
（1）超强性能，最大支持100万的qps；
（2）安全可靠就是应用级高可用，集训高可用，地域级高可，还有支持WAF防防护；
（3）面向云原生的高度集成，云原生中会有绘图发布、流量仿真、微服务快速发现的场景，对这些场景适配性较好；
（4）开箱即用，也就是秒开通，包括完善监控，还有丰富日志WAF集成，较方便。
4.案例
三大应用场景：大型互联网的场景、音视频的场景，金丝雀蓝绿发布场景
九、实验
1、使用ALB实现灰度发布的功能
实验概述：灰度发布也称为金丝雀发布，是介于黑和白之间的发布，在以前旷工下矿时，会带一只金丝雀，因为金丝雀对瓦斯和煤气较敏感，在较低浓的情况下，金丝雀就会瓦斯中毒，所以会带着金丝雀判断是否有泄漏。灰度发布（又称为金丝雀发布)是一种平滑过渡的发布方式，将老版本应用与新版本应用同时部署在环境中让一部分用户继续使用老版本应用，一部分用户开始使用新版本应用，然后根据用户使用情况调整新版本流量占比，逐步把所有用户都迁移到新版本应用。
实验目的：掌握ALB监听配置，掌握ALB实现灰度发布。
在之前，会直接应用升级为新应用，如果新应用有缺陷或者有未知的异常，就会影响全网或所有的客户端，灰度发布的贡献就是会引流或者把一小部分的请求发布到新版本，绝大部分的客户端可以实现比较平滑的发布模式，当新版本验证正常之后，在逐渐的切换流量到新版本的应用上。
实验中用到两个产品，ALB产品和ecs，会在ecs上部署两台ecs，其中一台ecs，部署老版本应用，新的ecs，部署新版本应用。以下是实验的界面：
左边是实验手册，云产品，实验报告，云产品就是实验的资源情况，账户密码直接通过实验创建好，直接打开浏览器，登录子账号，就可以进入资源信息界面，先验证实验资源是否正确的生产出来。有AM3结尾的ALB实例，实验中提前创建两个服务器组，两个服务器组是X3结尾和ud结尾。X3就是旧版本的应用，这两个服务器组，是一组服务器的集合，可以加不同的后端，监听的业务端口是80，后面会布置1台Nginx来模拟业务。Appv2对应ecs 2，后端协议使用http铭文回源的协议，也可以选择gdps。
健康检查默认开启，检查方式选择HTTP，也可以选用TCP，TCP就指定后端端口。可以检查的路径，推荐配置特定的健康检查的路径，例如health check。对于状态码，返回对应的状态码，才认为正常，如果没有勾选，就认为健康检查失败。
实验手册:通过客户端访问ALB，ALB会部署两个APP.OLD和APP.NEW如何实现两者之间平滑切换。
切换地域，登录两台服务器，首先通过终端登录到ecs1，两台服务器登录密码都一样。登陆之后，安装Nginx，Nginx就是Web应用服务器， Nginx性能比阿帕奇的强，动态Web用tomcat或者自建应用等。安装完后启动，先stop再eable服务，最后通过status确认是否启动，如果是Running状态，说明两个服务已经正常启动。默认监听80，再查看响应情况：
[root@izbp17yc5v66ypb3rwifiiZ~]# curl -localhost
只进行head请求：
[root@izbp17yc5v66ypb3rwifiiz ~]#curl -X HEAD localhost
正常响应200状态码，说明服务已经正常监听、正常响应，因为两台服务器默认一样，在静态文件目录下区分两台服务器，一般访问index htm文件，首先创建编辑文件，定义为ALB.html，内容设为旧版本的应用，再部署新版本的页面：
[root@izbp17yc5v66ypb3rwifiiz html]# vim alb.html[root@izbp17yc5v66ypb3rwifiiz html]# cat alb.html
APP-OLD
通过静态页面来区分两个不同的业务，在真实业务场景下属于不同的研究版本或者真实的业务场景。以下是sod实例：
该实例对应分配了域名，可以用answer lookup解析域名，解析返回结果有两个：
alb-d7ptc3zdxds9ylrams.cn-hangzhou.alb.aliyuncs.com. 30 IN A 47.110.150.231
alb-d7ptc3zdxds9yl3ams.cn- hangzhou.alb.aliyuncs.com. 30 IN A 47.110.140.12
两个IP就是公网IP。客户端发起请求给ALB，ALB本身有两个可用区，会负载均衡到两个可用区。
创建监听，选http协议，监听80端口，添加下一步后配置不用改变就提交，报警可以不用管，因为刚配置上，会进行初始化探测，判断业务是否正常，可以通过jar包查看：
[root@iZbp17yc5v66ypb3rwifiiz html] # tcpdump -i any port 80 -nnvv
健康检查的IP就是100网端，后端响应之后就会返回响应，认为是正常的。
添加完之后，就可以访问对应的业务，可以直接通过IP访问，在真实业务场景下，不能通过域名，假设业务是百度域名，需要在云解析内配置CName， ALB再做解析，因为ALB上解析不需要用户配置，就自动会解析两个IP，在测试环境，可以直接通过访问ALB的域名去访问业务，例如直接输入httpa，不用加端口号，因为默认80。显示APP-OLD即访问成功，业务一开始都在老的应用上。
下一步实现灰度发布，需要用到监听的转化规则，点击到监听中，有监听的详细内容和转发规则，因为不同的规格原因，所以有些默认不支持，与实例规格相关，演示的方法就是匹配不同的HTTP标头，假设火狐的请求转发给新是APP应用，其他客户端发起的请求访问老应用，只需要选择标头http header：
>HEAD/ HTTP/1.1
> User-AgEnt: curl/7.29.0> Host: localhost
> Accept:*/*
<HTTP/1.1 200 OKHTTP/1.1 200 OK
< Server: nginx/1.20.1Server: nginx/1.20.1
< Date: Tue，26 Apr 202212:57:52 GMTDate: Tue，26 Apr 202212:57:52 GMT< Content-Type: text/html
Content-Type: text/html<Content-Length: 4833
现在发起的是curl请求，转发给新的APP应用，新的APP应用服务器组配置的就是新的ecs2，假设配置的权重是20，如果匹配权重是100，相当于只要匹配上，全都是转发给火狐，转发规则有两条，即默认的和后配的，请求会从上到下执行，先去判断标头是否包含five fox字段，如果包含，就会转发给新版本的应用服务器，如果没有匹配上这规则，就会命中默认规则，实现部分引流，验证应用服务是否是优秀：在网络环境调试中，只要是具体请求，请求头有useagent的字段，就是命中字段，就会把它转发给对应的请求，所以匹配的是HTTP请求领域的内容。如果验证一下除file fox之外的浏览器，例如谷歌浏览器，访问的就是旧的，请求头不带file fox，是Chrome，说明通过useagent识别不同的客户端发起的请求，实现灰度发布功能。还可以把部分的流量按比例分配，应用服务器如果要匹配路径，转发给两个服务器组，因为新的服务器组，无法判断，所以把80%的流量转发给旧的服务器组，引流少部分的流量给新的服务器，大部分流量保持在老的服务器上，来测试新的服务是否正常工作，也是先匹配路径，匹配到路径之后，按照权重转发，通过验证，第一次访问是OLD，第二次是OLD，第三次是NEW，第四次是OLD，通过多次测试，就是20%和80%的比例，相当于按照比例来负载。
