开发者学堂课程【企业运维之云上网络原理与实践课程：【视频】第六讲-云服务与总结】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/991/detail/14991
【视频】第六讲-云服务与总结
内容介绍：
一、课程目标
二、 Privatelink 相关概念和产品功能
三、通过 Privatelink 理解遇云上网络空间排查方法
四、问题判断方法论
五、回顾本期训练营
一、课程目标
1.了解 Privatelink 产品架构与最佳实践
2.通过 Privatelink 理解云上网络问题排查方法
3.理解问题排查方法论
4.回顾本期训练营内容
二、 Privatelink 相关概念和产品功能
1.为什么需要 Privatelink ？
在不破坏网络边界的基础上提供云服务。
2.云网络时代的相关历史：
(1)第0阶段：处于 Classic Netwok 经典网络时代。所有 ECS 都
在一个大型的二层网络里面；所有的安全都是通过安全组来隔离，没有独立的网络空间、网络边界，无法进行自定义。
(2)第一阶段：拥有了 VPC 后，可对其中的 ECS 、交换机进行分配网络网段。对于一个 VPC 而言，就是一个独立的网络环境。
Privatelink ：云网络衍生，以进一步提炼客户需求场景后衍生出的产品。
网络边界：前期有一个对等连接的产品，可以实现vpc和vpc之间点到点的互通。如果 VPC 可以使这三者之间互通，那么两两之间就需要建立对等连接。因为它有严格的网络边界，所以说需要两两互通，需要借助一个第三方的产品拉两条线，相当于是拉了一根线，两根线代表高可用；让两两之间能够互通。对于左边的 VPC 而言，它就是子网，对于右边而言，它也是一个子网，那么它们就是严格的一个网络边界。
VBR ：指的是线下机房。如果它跟不同的 VPC 通，它也需要一一对应，即它不能去通过A VPC 去绕行到 B V PC ，这样的路径是不被允许的。这样，又侧面的说明了两个VPC 是相互独立的的，同时也不能去做中转。
为了解决当一个客户有很多 VPC 的问题，我们就需要拉很多条线，才能让两两之间能够完全互通。对于这样的场景，我们衍生出了云企网这个产品：可以实现作为一个 hab ，所有人都与我连过后，它可以作为一个 habwork 网络，来实现所有经过我的 VBC 都能实现两两之间的互通，不用再去维护这么复杂的一张网络。
(3)第二阶段：当网络节点够多的时候，会非常的复杂， CEN 是为解决一个多VPC 复杂组网问题而成的产品。
(4)第三阶段： CEN即云企网，这个产品不能真实的解决更多客户的问题。原因是：比如存在公司并购的问题，或者说存在前期规划不合理，导致后续有网站冲突的问题，那么到底该怎么解决？于是就延伸，进一步的迭代和衍生，产生出了 Privatelink 这个产品。
云服务：泛一点讲，税货、ntp即时钟、DNS这些都是云服务。
举例：比如我是一个淘宝的支付接口，我自身也是一个服务，即我也在云上。其他客户想跟我通的时候，我不希望他走公网，因为我们认为互联网是不安全的，此时就可以通过 Privatelink 这个产品。
网络边界：一个 VPC 或一张通过 CEN 组成的一个主网，就是一张拥有网络完整网络边界的一个大网。比如客户a、客户b一样拥有同样大小的网络，即三个vpc或者两个vpc、一个vpr 这样的一个主网。我希望两者之间不在三层互通，就是说我不希望我的客户b的vpc能直接跟客户a对接；因为对于两者来说，一旦对接，它们俩之间就没有严格意义的网络边界了，他们俩之间在路由层面就是互通的。
举个例子，比如我在这里是10的网段，另一个是192的网段和172的网段，我希望如果网段不冲突的话，我是可以通过网络来打通这两个 VPC 或形成对等连接、把两个 vpc 加入到cen里面。但是两个公司是不同的主体、不同的信息安全等级，我不允许他们俩之间互通，但是b又需要去访问a的一些接口，由于一些安全等级的要求，又不能去通过公网去访问。
那么就要通过 Privatelink 的产品。 Privatelink 这个产品解决的主要的问题是：对于b而言，我访问的仍然是自己网络线内的东西，就是网络自营的网络内的一个IP；然后通过 Privatelink 产品衍生，就可以访问到a。对于a而言，是绝对安全的：我只允许 b访问我特定的接口，是对外暴露特定的接口，并且是通过内网的形式，；另外我还可以主动去控制来是否提供服务。
按照这个自制网络来区分，相当于是我的 abc ，他们都是完整独立的一张网络，对外只是提供一个服务。这个云服务有很多种形式，即从这些资质网络里去访问 Privatelink 就可以了；对于我来说，我始终是单向去访问的。
不破坏网络边界的基础上提供云服务：对于我来说我的一张独立的网络，那么这张网络可能是一个 VPC 组成的，也可能是由 CEN 组成的多个 VPC 之间的一张网。它是一个独立的网络，拥有自己的网络边界。
比如我的集团a和另一个集团有一些合作，但是我不希望我们两个并网，就是把两个网并拢在一起，因为我有自己的网络规划。这种情况下，要 b去访问a的一些接口，就需要用到 Privatelink 的这个产品。
3. Privatelink 产品简介
Privatelink 即私有网络，它提供了一个渠道，让a和b之间可以通过私网的形式，在不破坏网络编辑的情况下能够互通。利用阿里云的私有网络进行服务交互的一种方式。利用私网连接，用户可以通过私有网络单向访问部署在其它 VPC中的服务，无需创建NAT网络、EIP等公网出口。交互数据不会经过互联网，有更高的安全性和更好的网络质量。
服务使用方和服务提供方两者之间要提供服务，只能通过公网的形式去访问。伴随着信息安全的要求越来越高，集团不允许通过公网方式去访问，所以需要有一个网络封闭的私网环境，保证私网不通。客户端去访问内部的一个IP地址，通过私网连接的方式，在它的终端节点服务出去的时候出去，变成了一个映射出来的地址去访问他提供的服务。
原来的环境是公网到公网，那么到这个环境里面，保证了私网和私网的请求，同时私网和私网之间又不需要两个 VPC 通过 CEN或者其他的方式把它打通，且满足们俩之间三成互联。通过这个产品来实现这样的功能，不需要两个VPC并网，又可以让其中的 ECS 和它的服务之间通过私网的方式去互联，保证绝对的安全性、保证双方不去破坏自己各自的网络边界。
网络边界：在物联网网络里面，有一个叫btp的技术，是一个支持率。即在这个网络里面我们就可以认为，我们服务方a服务方b都是有各自网络，然后我不希望他们两个通过专线的方式也能够直接打通；说我不希望他们两个在如果都在云上，我不希望他都通过 VPC 或者CEN的形式但也互相打通了。
特点:
(1)本地私网通信：服务提供方之间完全是私网通信。
(2)保持网络封闭：服务提供方不需要在公网暴露自己的网络接口。
(3)单向服务访问：终端节点和终端服务节点 SLB ，只允许使用方
单向的访问提供方。
(4)保持双方网络独立：不用进行并网操作、修改路由，也可以保证
双方的网络独立。
4. Privatelink 使用场景
(1)云服务：更加安全可控的云服务入口、支持跨地域访问云服务、
支持IDC访问云服务。
上边是一个企业，或者说是一些内部的接口或者是云内的一些服务，也会通过这样的形式暴露给客户。
客户有 VPC 、IBC，我打通了三个节点之间的三个独立档过后，我要去访问一些云内的服务，云内的服务部署是希望这个客户他有独立的这个接口。比如举个例子，我们有一些rds或ridence，云服务它其实是一个公共服务，所有客户都会来访问过，但是我的客户不可能说他跟所有的云服务都去打通。
所以就通过在客户的 VPC 内创建两个 Endpoint ，即创建两个终端节点。界面提供终端节点服务，然后客户的接口只用去放到这个终端节点，就可以和我们的云服务互通了，因为大多数云服务都只需要被动被访问。
比如我们的服务器，那么现在大家看到服务器对外、对客户对在的 ECS 暴露是100.100的地址，但是后续如果客户对这些服务器的要求越来越高，包括现在也支持一些自建这个 Dacp服务。
那么当客户对这些网络的要求、规范要越来越高的时候，就会用到 Privatelink 这个产品，让他的服务去通过只能访问自己云内的、自己网络内的一个IP地址，然后去访问到对应的云服务。
(2)企业内部服务：支持服务化的企业IT架构、支持单账号和多账号体系、服务方和业务方的网络规划各自独立简化管理、更高的安全管控能力和安全隔离能力。
上边分为服务层、业务层。其实很好去理解，那么举个例子：比如我是一个做游戏的开发商。我的账号里面有很多款游戏，为了治理，给游戏a开了个账号、游戏b开了个账号，这些账号它都有自己的成本，所有的前端或者后端它都会部署在一个自己账号里面，即一个云企业网里面。
在集团内它有一个服务层，就是它的一些公共服务，比如它把一些账号或者客户信息存在了自己的公共服务层，使双方都会去享受这些共享的资源。
同时将来又不希望业务方和服务方有任何的网络规划冲突。在做学习规划的时候，其实有可能没有规划好，但是都要去访问这个公共服务地区，此时我就可以用 Privatelink 这个产品去提供。对于我来说，只需要在 VPC 里面创建一个Endpoint，即终端节点。这个终端节点服务绑定了这个sob，然后它就可以提供一些公共服务。对于每个账号而言，它也是各自独立的。
即通过独立的网络规划去访问另一个独立的公共服务地区，大家不用担心这些 VPC 的网段之间的冲突，因为 Privatelink 这个产品就是去解决网段冲突的。
(3)云上企业生态：公司的性质是有很多 ISV的，就是服务提供方，是一个非常广的一个公司有很多的服务合作方。每个合作方都跟我之间有信息互通的要求，但是每个合作方他们都是独立的，每个合作方就是比如 ISV 是各自独立，公司的 ISV 会给很多企业提供服务。比如集中提供解决方案的一个公司，要给很多人的公司去提供不同的解决方案，那其他公司都要去访问公司对应的服务，不同企业的网络规划是不可能相同的，那么冲突在网络里面是非常命中网段冲突的。那么就要通过 Privatelink 产品去有效的对外暴露需要暴露的服务同时,不去破坏我的网络边界。
在这个主网里就可以看到我企业a会同时去访问两个 ISV ，然后企业b也会去访问两个 ISV 。通过这个产品,不用再去担心两个企业的网站是否有冲突，我直接去访问你对我暴露的一个私网的接口。在这个场景下也保证了安全性。
5.产品组成
在交换机中生成一个客户网卡。例如存在网点192.168.1.1要去访问172.16.1.1，同时其本身的网络中也存在172.16.1.1.通过云企网的方式打通后，没有办法访问服务方b，通过 Privatelink 产品去解决。终端节点 Privatelink 会在客户的左边的，即客户侧通过提供一个叫终端节点的东西，将其逻辑化，即它会在客户的交换机里面，使用自己的ip192.1.16.该网段属于客户使用方的，此时使用起来就不会产生冲突。终端节点eni到另一侧会映射成一个100的网段区访问 SLB 。对于左右而言都是独立的。
所需主键：
(1)终端节点(Endpoint)：让客户选择两个交换机，对应生成两个网卡。使用的是左侧客户对应的两个ip地址。属于阿里云上 vpc 。代表了某个云上服务在服务使用方VPC中的私有连接接入点。终端节点通过终端节点网卡接入到某个可用区的虚拟交换机。创建终端节点时，可以根据终端节点服务名称，发起连接到服务提供方的终端节点服务的连接请求。
(2)终端节点可用区和网卡(EndpointZone&ENI)：代表了服务使用方VPC中的服务请求入口，终端节点网卡是在服务使用方VPC中基个虚拟交换机中的一个弹性网卡(ENI)，会占用虚拟交换机网段中的一个私网IP地址，所有发送到这个弹性网卡地址的服务请求将会通过私有连接转发到对应服务提供方在相同可用区的服务资源。
(3)终端节点服务（Endpoint Service）：关联服务侧，云内的网络服务通常是以 SLB 的形式暴露。这里是由私网 SLB 去关联私网的 SLB 。关联后台的服务资源，目前大多数都是私网 SLB 。此时不再需要公网ip，是纯私网场景去提供服务。服务提供方通过私有接提供的对外服务，服务称唯一识，服务提供方可以管理务使用方发起的连接请求终端节点服务可以添加部署在多个可用区的SLB应用服务集群作为服务资源。
(4)服务资源(ServiceResource)：即实际提供服务的集群。目前私网连接支持使用SLB作为服务资源
终端节点连接(EndpointConnection)：代表了终端节点和终端节点服务之间的连接。服务使用方创建终端节点时将起到终端节点服务的连接请求，服务提供方可以自动或手动接收连接请求。
流程：客户端通过自己的ip 访问终端节点，转发到终端节点服务；终端节点服务会映射成云服务的地址去访问slb。
注意:
(1)一个终端节点在一个可用区中只能有一个终端节点网卡。
(2)某个终端节点网卡的流量只会转发到在相同可用区的SLB服务集群。比如从终端节点A 上车，交换机A绑定终端节点就会给可用区A交换机的 SLB 。
这样就保证不再绕行可用区造成访问终端节点资源绕行的问题，减低延时。虽然在云内，我们同一机房内延时在2-3毫秒以内，严格来说大多都在2毫秒以内，如果能保证同一个上车点和同一个下车点，指的是终端节点、网卡、后端服务资源。当上车点和下车点在一起的时候可以避免绕行，也保证没有跨ac的流量产生。
Privatelink 的组成部分：终端节点网卡、终端节点、终端节点服务、终端节点服务资源。同时要把终端节点和在终端节点服务连接在一起的connect组成部分。
我的客户端、ecs也可以是IDC，我要访问一个IP地址，这样才能保证不冲突。然后 Privatelink 这个产品会在客户的交换机里面生成一个网卡。
6.高可用区高可用能力
高可用机制：通过域名解析实现多可用区高可用:
(1)对多个可用区中ENI的服务状态进行健康检查
(2)当某个可用区的服务不可用(包括故障场景中的3种情况)，自动
将不可用的ENIIP从解析结果中去除
(3)客户端根据更新的DNS解析结果，将请求发送到可用的ENIIP
客户侧要求:客户端必须使用服务的VPC域名访问服务，不能直接使用可用区域名或者ENIIP
如果只有一个 ENI 在可用区，客户去访问的时候，如果一个终端节点 ENI 挂掉了，就没有办法做高可用的切换。
高可用在 Privatelink 场景下的使用：后端提供 URI 。比如访问阿里pay，在客户端访问的是终端节点提供的域名，域名通过 DNS 会解析成两个私网的IP；客户端访问这个域名时，就会对应解析到两个IP，然后去访问到后端。
若 PVL 接入VSW 为可控趋势，无论后台 SLB 挂掉了，还是服务本身出现了异常，都会通过 DNS 解析去探测这两个点是不是活着。然后确认如果没有不在一个可用的状态，就把它从 DNS 中摘掉。此时客户端在这个 DNS 里面就只能拿到一个IP地址，就会实现一个绕行；或者说去访问备用的 ENI 实现高可用。
DNS 做探测时，探测的是上车点，就是看这个终端节点是否可用。如果客户端没有用 DNS ，访问的不是域名而是IP的话，高可用就自然而然的就不再高可用了。
就是说因为如果使用IP地址，那么就需要他有一套探测机制，能让 ECS 在异常的时候不去访问这个错误的IP，而去访问到正确的IP。为了避免客户自己去做一套，建议访问这个终端节点的时候，通过域名去访问。
故障场景：
(1)某个可用区/机房的PVL集群全部宕机：可用区挂掉了，可用区
级别的故障；客户后边的 SLB 服务集群出现了异常或 SLB 本身出现了异常。
(2)整个可用区/机房出现故障：自身 Privatelink 出现了异常。
(3)某个可用区的服务提供方的服务资源不可用。
高可用的前提是使用域名去访问。
7.小结
Privatelink 产品设计意义：为了不在破坏网络边界，在不破坏网络边界的基础上，提供云服务。服务可以是阿里云的云服务；可以是sv的云服务；可以是内部的网络内的公共资源服务等。
特点：
(1)通过私网通信，保证了安全。
(2)保证了客户端去访问时服务端单向的去访问。
(3)不同的账号不用去做单独的规划，集团间不用破坏网络设计；保证了双方的网络独立的设计与规划。
组成部分：
(1)终端节点-终端节点可用区和网卡（网卡属于可用区）
(2)终端节点服务：目前仅支持后端 CLB ，往后会提供更多的，比如 ENI 等等。客户可以通过后端去暴露服务器。
(3)终端节点连接：把终端节点和终端节点服务关联在一起
(4)安全管控和跨账号 UID ：在排错过程中进行讲解。
高可用：如果客户端要去保证访问终端节点高可用，就需要通过域名的方式去访问；变相说明是通过域名的方式去提供了一个高可用。
接下来会通过讲解一个案例和拓扑，来分析如何排查 Privatelink
相关的产品问题。
三、通过 Privatelink 理解遇云上网络空间排查方法
问题排查：北京 VPC 内的ECS 无法访问到上海 Privatelink
首先回忆一下在整个训练营的过程中，有哪些资源和内容。
在这个链路中，我们要把这个上面的拓扑抽象成下面的链路：首先当我是一个运维方的时候，或者说是一个过来协助排查的使用方，我要去排查为什么不通的问题。
首先从上面的物理拓扑中抽象出一个逻辑拓扑。
在逻辑拓扑中，客户端是什么？客户端是 ECS ，五个 ECS 属于 VPC 1；通过云企业网，到上海的 VPC 2；访问 Privatelink ， Privatelink 会变成终端节点的 ENI，即一张网卡。上述过程均属于客户1的网络。
到了中间节点 ENI 过后，会转发到 ENI 的后端，转化到 Privatelink EndPoint Service 转到SLB；再从到我们到真实的服务器。
我们已经把它的逻辑拓扑抽象了出来。如果说出现了不通，最简单的方法是去枚举，按照经验或按照判断，枚举出每一种导致客户端访问收入端不通的可能性。
结果如下：
此时就要分析每个节点的可能的情况
(1)客户端：自身有安全组、安全策略、容器的网段占据了 VPC 2网段，即占据我们刚刚上海的一个网段。它在它的网络边界里面是不去感知这个我们服务器内的一个组网的。更上层的网络是不去感知更下层的网络的。
(2)VPC 1：路由、网络NACL
(3)CEN：路由表错了、跨地域没有配置带宽包、带宽包不够用或占满；或者使用测试带宽包只有10KB的带宽.
(4)VPC 2：是 VPC1 的镜像。自身路由问题、网络 NACL
(5)终端点：无论 ECS 还是物理网卡、辅助网卡都需要创建安全组、服务没有正确的连接。
(6)第三方：排查出左边没有问题后，督促对接方去排查。确认终端节点连接服务有没有连接好、调查对客户端提供的 CLB 后端的健康检查情况、接入点、 QPS 有没有到上限。即看他的服务是否健康；后端 RS 自己的连接数、内核有没有丢包、一些应用配置导致的一些问题。
回到问题分析，我们通过穷举的方法判断了问题，并督促对方去查。整个链路是一个很标准的经验判断，就是把每一个可能性都去穷举了。
根据现在不通的这些现象，一点点去排查最高可能性的地方。这就是一种网络问题的排查方法，但是这种方法工作量会特别的大，因为要去穷举每一种可能性，并按照经验去判断。当新入门的同学，或者说是一个新手，刚接触阿里云的交接方，需要一点点进行判断，判断的过程也是学习的过程，去熟悉每一个环节有怎样的限制。
通过这样的判断，历史的经验告诉我们中间部分，终端服务节点安全组出现问题的可能性是最高的。此时就需要去控台上看。关于安全组、连接数则需要去看监控。
思路是左边叫客户侧，只能查自己的资源。对端需要服务提供方去查。就把问题说是简单的定界，先定界后定位。先要去做定界是在左边还是右边，那么进阶到左边过后，我们又逐步的定界最小的部分。整个链路比较长，我们可以通过各种各样的方法做问题的判断，同时提炼出一些对于云上网络安全问题的定位的方法论，不仅适用于做云上网络，其他的产品也可以沿用这一套方法论。学会看监控，以发现问题、解决问题。
四、问题判断方法论
1.Drill-Down Analysis Method-从错误本身逐层剖析
(1)Start at highest level 通常从应用报错日志开始：作为运维，首先看到的是错误日志。比如客户端报错看到的是客户端日志； NGX 报错看到的是 NGX 日志。
除此之外，还有一些访问日志去访问502、504，看其是不是存在扩张，在某一个时间点里是不是有增大，在某一个时间点里502变多了、504变多了或者客户端报错变多了。此时要看报错的意义、是如何进行计算的。例如在服务器里面close很多，则看message日志其中怎样的场景会记录overflow。从它本身开始就是应用层的报错。首先要知道报错是如何生成的、怎样做计数等。
(2)Examine next-level details 从应用层、容器网络层、内核层、虚拟化层逐层怀疑：网络丢包容易造成堆积，502的时间点502或504变得很多，此时需一层层怀疑。
(3)首先是网络是否抖动、 CPU 是否存在抖动。一层一层地往下，从应用到内核，到虚拟化、基础设施，基础设施包括服务器、网络、后端连接的一些应用是否有报错。从很高的界别逐层分析，找到最有可能的怀疑对象。
(4)Pick most interesting breakdown 排查可疑的现象 ：往深里继续看，需要每个层面都要有丰富的经验。要懂应用、代码、内核、基础设施、如何计算 CPU 、虚拟化、网络。逐层排查，才能解决问题。到了一个节点之后，需要理解节点是怎样计算的，就容易陷进去，使排查时间变长。
(5)If problem unsolved,go to 2：如果有最有可能的怀疑对象过后，但不能解决问题，就需要回到第二步重新进行排查。找到第二个最可疑的对象。从应用日志出发，一层一层排查，对个人的素质要求很高。
缺点：排查依赖于异常复现，在第三步时容易死磕一个很小的点。很多东西都需要一个积累，才能判断具体是什么问题。而导致忽视全局。
优点：在集团中经常使用，每个点对应的不再是一个人，而是多个团队，去判断问题，公司的人才比较全面，每个领域都有对应的专家；由一个知识比较泛、全面的人牵头，横向的人才带领这个团队查问题。这是一个从错误本身逐层剖析的方法，可以把问题查得非常的深、清晰。
2.Tools Method-从外围监控入手
(1)List available performance tools(optionally addmore)首先应有怀疑的方向，并了解对应方向的工具
(2)For each tool ,list its useful metrics 需要了解工具暴露的哪些指标可以佐证自己的怀疑
(3)For each metricist possible interpretation明确指标的含义
(4)Run selected tools and interpret selected metrics.
首先要有一个监控，通过尽可能多的性能工具调动 API ，可以看到 CPU、接口、或者说每个地方的一些性能指标。谁的性能指标最开始出现问题、最有异常，就开始查他。再用一些方式去分析、佐证从监控工具中看到的怀疑。佐证后，是系统存在前端或者后端的异常，到这里需要看每个监控的含义是什么。
知道含义是什么后就可以进一步进行定界。方法相对简单，就看大盘谁是最异常的，就先去看他。
缺点：该方法对我的线网非常的依赖，指的是大量的监控软件，网络要有网络监控，内核要内核监控，CPU要有CPU的监控，应用要有应用的监控。同时还需要这个运维方能读懂，能清晰的理解每个指标是什么含义，且能从这些指标里能去判断出异常。
如果是偶现的、或历史的异常，监控指标可能不全。目生产环境部署不一定能够部署大量的监控软件，话用场景有限。
通常云上也有许多监控软件，例如普罗米修斯，其自身也有很多的监控软件。如果是一个云原生比较依赖的，就已经通过云将监控都部署了。若为混合云的场景，或者说绝大多数的指标都在云下，此时监控系统就会非常的重，对运维方的能力要求也就越来越高。
两个方法会混合使用，对于线网主网的环境，建议大家先去部署更多更多的监控。监控部署的多，自然有相应的成本。了解自己的监控和其指标。
案例：
之前在一些重保的环境中经常出现客户的 QNS ，它的 AC K 有大量的502，或者某个时间点有大量的异常。那么通常正在压测的时候，就是业务上线前期去做一些探测。首先有问题现象：客户告诉你，或者业务方告诉你他有一个什么样的现象。现在在压测的时候出现了大量的502，接下来去梳理他的逻辑拓扑。
客户端c到对外提供的 SLB ，后端通常是一个 ACK ，即阿里云的QNS 。 ACK 他在某一时间点产生大量502，对他来说，客户应用是质，他应用是链接失败。他拿不到对应的请求，因为他拿到502，没有拿到他想要的东西。接着我们去梳理整个链路，处理这个链路进行流程判断，那么我们判断是一个 SLB 加 ACK 通过云服务对外暴露的服务；接下去要去捋出来 ACK 有什么，最简单的场景是通过一个 SBC 然后到 pod 。了解到整个链路过后，就要结合第二个方法，我们确认了看客户是哪个时间段异常最多。去找到异常的时间段，在这个异常时间有大量的502，伴随着它有大量的请求，因为刚才前提讲是一个压测的场景。接着我们注意看 SLB 和 ACK 的日志，发现 ACK本身上面的 pod里面并没有这么多业务请求， SLB 上的这个日志和这个后端的对不上。就是怀疑 SLB 和后端 notepod之间有异常。
有异常过后，要想这个异常最有可能是什么。最简单方法是去看这个 note、pod的一些日志啊。这里省略一些环节，我们看到note上面本身有碳层，很多摊位置的状态。到这里如果有一些比较丰富的经验的话，可以去开一些recycle，这样的参数去优化。但是对于我们而言，我们不能说这么草率的，让客户会让业务方去修改，我们需要佐证怀疑的对象符合我们的怀疑现象。
接下来，看一下为什么timewait导致我的客户端访问有大量的失败。在note上面抓一个包，我们会看到 SLP 和后端建联，后端并没有响应 cex 。什么样的情况下会反馈ack，首先去看监控去佐证一下，
我们产生这么多问题的原因是因为被建联失败啊导致给客户端发送504或者502。佐证过后发现响应app导致我不能正常建联，然后导致一些超时。深层的分析这个问题，为什么当我处于 TW 上的时候，我会我收到CEX。如果是对这个网络有相对比较深的感觉，会去看一些内核相同的代码，当理解了这个代码之后，他就知道怎么去解决。快速给大家讲一下，我会收到ack的原因，是因为当我处于TW状态时，我的状态既没有释放，我收到你的thing，我认为你是一个
不符合正常的连接，所以我会回一个ack，这个ack附带的是来自于上一个链接的，就告诉对方你不属于我这个链接，要不把这里reset
掉，重新发几个；要么就别来了。这样，导致他鉴别失败，那么这里是很抽象，不涉及讲源码。然后这个情况下，已经知道了是因为我的摊位算了很多导致的问题。
那么在容器环境里面，什么样的情况下，我可以解决摊位的问题。就是我们要去找这个组件svc，我们可以去看如果你的svc是IPVS做的，可以去控制IPVS TW的时间，让它快速的去释放TW；或者说去修改contract表，让他更少的、更快的去释放 TW ；还可以通过扩容的方式去解决，让我的每个后端能更轻的压力去解决这个问题，用更少的 TW 。
这是近期遇到一个比较典型的案例，通过了这些方法论去解决这样的问题，希望呢大家能将这个方法论用到自己今后的工作生活中。
六、回顾本期训练营
云网络的发展：经典网络：大型的二层网络-安全的、隔离的、独立的专业网络 VPC -全球互联的网络：把VPC IPC之间打通，引进了云企业网这个产品。
下一阶段呢就是即将去拥抱5G；拥抱 IOT ；拥抱更多的终端：车联网、物联网等。
后续我们会大家会看到越来越多的可视终端，或者一些这个自动售卖机会越来越多，包括一些智能家电。云网络下一个阶段就是会去拥抱这些，给互联网、车联网提供网络解决方案。
网络排查工具：mtr、traceroute等。这些工具在排查公网问题的时候非常有帮助。去如果愿意深入的去了解网络这个领域的话，可以什么可以什么可以去自己通过一些脚本写一些CPP、 Ut 。
