企业官网建设流程全解析

中山企业推广网站制作,电脑版 做网站尺寸,网站建设哪家便宜,重庆的网站建设本文整理自民生银行总行科技部网络管理中心高级工程师冯晶晶在「清华大学云杉网络可观测性技术论坛」的演讲实录。回看链接#xff0c;PPT 下载 摘要#xff1a;本文讲述了民生银行的网络运维团队的工程师们在企业全面拥抱云原生的过程中#xff0c;如何与云杉网络 Dee…本文整理自民生银行总行科技部网络管理中心高级工程师冯晶晶在「清华大学云杉网络·可观测性技术论坛」的演讲实录。回看链接PPT 下载摘要本文讲述了民生银行的网络运维团队的工程师们在企业全面拥抱云原生的过程中如何与云杉网络 DeepFlow团队携手以 vTap 流量分发为起点逐步改变传统网络运维思路拥抱分布式流量采集方案引入 eBPF 零侵扰应用追踪技术并积极探索更多观测能力的发展历程。关键词DeepFlow、民生银行、可观测性、eBPF、云原生、全路径网络观测、应用调用链追踪、分布式采集、统一观测平台、WebAssembly一、前序作为一名资深的网络运维工程师多年来积累了大量网络相关的技术经验和心得体会今天以一种非常激动的心情向大家分享民生银行多年来从网络出发在云原生可观测性领域的建设实践。在银行做网络运维其实是一个很艰难、压力很大的工作因为银行对业务的连续性和稳定性要求极高任何一次故障或业务中断就可能会直接带来用户的资金损失无论是监管机构考核还是部门内部要求均是以安全生产为第一要务所以每一次故障处理的时候运维人员都是背负极大的心理压力。网络本质上就是用来为业务搭桥当业务发生问题的时候大家首先会怀疑网络有问题。当有业务中断时大家的第一反应总是“网络哪里出问题了”、“现在业务中断了抓紧查一下网络”当有业务慢了的时候大家总是说“查一下网络是不是网络哪块抖动了导致我们业务慢了”当业务有异常的时候大家还会说“我们这笔查询失败了看看是不是网络哪块有问题”……所有的问题首先联想到的都是网络问题所以网络工程师总是背锅侠不是在背锅中就是在背锅的路上。二、民生银行可观测平台概况图 1-民生银行可观测性平台概况那么怎么去解决故障边界不清晰这样的问题呢流量分析观测平台给我们提供了一个很好的方案民生银行在 7、8 年前开始建设流量分析观测平台在传统环境中通过交换机旁路镜像采集网络流量的方式将流量输送到流量汇聚平台过滤、标记后输出到流量分析观测平台实现全网络的流量视图监控。通过流量分析观测平台极大的缩短了故障定位的时间同时把网络流量数据通过数据服务的方式输出给各运维平台比如交易监控平台、安全运维平台、态势感知平台、大数据平台提供网络流量数据服务。在传统网络环境下很好的解决了这些问题但随着云原生时代的到来新的问题产生了。所有人都在讲业务要敏态交付所有的应用向微服务化转变云原生时代来了以后对流量分析工作造成了什么困扰呢大量的业务流量都在计算节点内部直接交换不会进入到物理交换机那怎么去分析容器内部、虚机内部的业务交互情况呢首先要感谢 DeepFlow 产品通过与云杉网络的深度合作利用第一代的 vTap 技术在每一个计算节点内分布式的采集容器内部、虚机内部的东西向流量从而弥补虚拟网络监控的观测盲区同时通过 eBPF 的零侵扰采集能力把应用数据采集并输出实现了我们真正的从设备级运维转变到基于用户、基于业务交互、基于用户体验、基于安全合规的场景化运维服务及数据服务能力。三、建设历程图 2-民生银行可观测性平台建设历程​​​​民生银行的可观测性平台是通过逐步摸索分为四个阶段一点一点丰富能力而稳步建设起来。第一阶段基本沿着传统的流量采集、流量分发的技术思路采用 vTap 流量分发方案通过部署采集器在计算节点上把容器内部、虚拟机内部的流量采集并分发出来解决容器网络东西向流量的监控需求这就是这个平台建设初期的目标。通过采集器采集出来的容器内部东西向流量特别大在流量突发的情况下对流量汇聚平台产生很大的压力于是我们进入了发展的第二个阶段采用分布式采集的理念在采集器中直接进行分布式的数据采集计算再把采集计算后的结构化数据上送到数据分析节点解决了整个流量分析系统分发带宽瓶颈的问题同时也实现了整个云原生容器网络的全路径的流量追踪能力。第三阶段积极采用 eBPF 技术通过底层 Linux 内核提供的 eBPF 编程能力捕获应用进程调用相关的数据实现应用调用链的零侵扰追踪将我们从网络观测能力提升到了应用的观测能力。现在民生银行进入新的探索期这个时期大力拓展 eBPF 的潜力并积极引入 Prometheus、Skywalking、听云等数据构建包含应用、网络、系统的统一观测平台数据底座并延伸到业务观测。3.1 初期——延续传统思路vTap 打开云网黑盒图 3-第一阶段建设方案——流量分发在传统的物理网络运维中通过对交换机镜像操作以获取负载均衡、防火墙、核心/边界、接入/汇聚的南北向流量并输送到统一流量汇聚平台通过统一流量汇聚平台按需输出到网络监控安全监控交易监控以及场景化数据服务。到了云原生时代在计算节点上部署 DeepFlow 采集器实现 vTap 的能力利用 Linux 的 cBPF 能力把容器内部以及虚拟机内部的流量采集通过 VxLAN 隧道把虚拟网络流量分发到统一流量汇聚平台弥补虚拟化环境的流量监控空白。现在虚拟网络流量的分发能力已经完整覆盖了总行和分行的全部测试集群、生产集群。3.2 发展——拥抱新理念分布式采集增强网络观测在传统物理网络环境中交换机等位置的南北向流量其实并不是很大相比较来说容器化以后所有计算节点内部的东西向流量规模则非常巨大如果全部输送出来会对中间流量汇聚平台造成很大的压力尤其是在流量突发时会导致中间的流量采集层产生丢包影响监控服务质量。图 4-第二阶段建设方案——分布式数据采集因此通过分布式采集的方式增强整体的网络观测能力也就是在已部署采集器的流量分发能力基础上在采集器内部采集到所有 Pod 或虚拟机的流量后直接分布式计算生成流量的指标、流量的日志、流量的追踪信息然后把这些数据上送到云原生流量分析节点通过分析节点统一分析、展示可以提供的运维能力包括整个云原生网络的流量全景分析、流量监控、云网络故障诊断分析同时在这个基础之上还可以识别容器、虚拟机的扩缩容、资源迁移等变更事件。在这个阶段落地的技术关键点包括分布式采集在采集端分布式采集流量性能指标、流量日志从而解决流量分发方案 CPU 需求瓶颈、物理网络带宽瓶颈全路径采集在容器网络全路径实现数据采集获取同一条 TCP 流从客户端 Pod 网卡到服务端网卡 4 个关键位置的性能数据全路径关联对流量数据标记位置信息对任意 TCP 流端到端路径实现全路径关联分析。图 5-分布式全路径采集及全路径关联分析利用分布式采集从无到有的打开了容器和云的虚拟化网络的全路径其次将容器内部的交互情况进行可视化分析、展示然后把容器网络的流量性能数据通过自服务的方式提供给其他部门。3.3 创新——落地新技术eBPF 实现应用观测图 6-第三阶段建设方案——eBPF 技术实现应用观测实现了容器网络观测能力之后又进入到了一个新的建设阶段即创新阶段在这个阶段中技术实现了从 cBPF 到 eBPF 的跳跃观测能力也实现了从网络观测、系统观测向应用观测的跳跃。通过 eBPF 技术对应用程序零侵扰的方式从 Linux 内核捕获应用进程的函数调用采集到应用进程的调用指标、调用日志、调用追踪数据并上送到云原生可观测性分析节点从而在原有的网络观测能力基础上实现了包括应用全景分析、调用链追踪、调用回溯、进程 CPU 剖析等应用观测能力。在这个阶段具体实现的能力包括eBPF 应用数据采集通过 eBPF 技术实现了对 Nginx、DNS、Redis 等无法插码位置的数据获取能力和观测能力观测延伸至进程对应用调用HTTP、DNS、MySQL…的观测能力从虚拟网卡延伸到客户端、服务端进程零侵扰调用链追踪无干扰、对入侵对任意一次应用调用的全链路进行追踪。图 7-eBPF 技术实现的应用观测能力通过这一阶段的能力建设不仅可以满足网络监控的需求还能够输出到应用运维部门。应用运维人员可以通过链路追踪、指标数据第一时间观测到整个应用程序的运行情况。通过 eBPF 的能力消除了 Nginx、DNS、MySQL、Redis 等应用服务的监控盲区并且将追踪能力由网络扩展到应用进程实现应用、网络的统一追踪、统一观测大幅度提高了问题定位和处置效率。做个简单的过程对比。大家可能都会在运维过程中遇到这样的问题比如某个系统报障说某个服务突然响应慢了在传统物理网络环境中网络运维会通过流量分析平台人工分析应用的响应时延指标定位到问题以后通过人工下载 Pcap 并读包的方式追溯整个业务的交互情况确定慢在哪一个环节。有了 eBPF 技术实现的调用链追踪以后通过火焰图形式的调用链追踪第一步输入服务名称第二步找到慢响应第三步点击调用链追踪就自动把慢响应的整个调用链过程包括网卡、进程在视图上展示并清晰的看出到底是哪个位置、哪个服务占用的时间比较长。以下是 4 个通过 eBPF 实现的应用调用链追踪处理的经典案例供参考。案例 1业务运营系统 Web 服务慢响应根因锁定图 8-应用慢响应的零侵扰调用链追踪在某一个业务排障中发现 Web 服务的某次服务响应时延长达 3.04 秒使用基于 eBPF 的零侵扰应用调用链追踪能力可以一键调阅这次 3.04 秒的应用调用的完整链条并快速、直观的在火焰图中通过不同 span 的长度确定慢响应的根因 span 是后端的 oms-app Pod。案例 2零售综合服务系统慢响应根因锁定图 9-应用慢响应的零侵扰调用链追踪在另外一个服务系统的排障中发现部分响应时延接近 500ms使用基于 eBPF 的零侵扰应用调用链追踪能力一键调阅慢响应的完整调用链从火焰图中可以快速发现是由于后端的 acuiagwapp 服务响应慢导致。相比较使用传统的物理网络的定位模式类似的问题需要多次抓包然后逐跳分析逐跳定位逐个 IP 跟踪才能定位到具体哪一个服务出现了问题但是通过调用链追踪能力可以直接可视化展示到具体的是哪一个服务、哪一个位置慢了。案例 3零售综合服务系统慢响应根因锁定图 10-应用 HTTP 502 失败的零侵扰调用链追踪决策分析平台客户端反馈出现了 HTTP 502 报错但是客户端不知道到底是哪一个服务导致的一个 502 报错通过调用链追踪可以直接发现在服务端向 DNS Server 请求域名解析的时候发生了 DNS 请求失败的异常从而确定 DNS 服务的失败导致了此次 HTTP 服务的失败。案例 4支付通道整合系统容器 DNS 潜在隐患发现图 11-DNS 异常的零侵扰调用链追踪对支付通道整合系统进行运维观测时发现大量 DNS 异常对异常 DNS 调用一键点开调用链追踪发现 tpp-pay-* 的 Pod 高频查询外部域名并且由于 kube-dns 的 DNS 查询机制导致需要多次遍历解析内部域名潜在影响交易性能从而发现了容器集群中 DNS 配置一些可以优化提升的技术点指导系统运维对容器 DNS 配置进行优化。通过这些案例会发现借助于 eBPF 实现了应用观测网络运维不仅具备了对网络问题的分析诊断能力还具备了对应用的追踪诊断能力具备了对 DNS、Nginx、Redis 等公共服务的追踪诊断能力。3.4 探索——拓展新功能构建数据底座现在民生银行进入到了可观测性系统建设的第四个阶段即探索阶段。在这个阶段的目标要做一个整体的观测数据底座把尽可能多的数据比如系统的 Prometheus 数据、应用的数据融入到数据底座中实现一个覆盖网络、应用、系统的统一观测平台消除整个数据鸿沟然后提高整体运维的效率。图 12-数据底座构建系统、应用、网络的统一观测同时也计划对 eBPF 能力进行增强实现应用进程的 CPU Perf 数据采集能力深入剖析包括应用进程内部的内核函数、库函数、业务函数在内的 CPU 消耗分布。通过这个能力开发人员可以快速定位到有哪些函数执行效率比较低并针对性提升或者优化程序代码。图 13-eBPF 技术实现的进程 CPU 性能剖析四、总结4.1 可观测性为我们带来什么图 14-从网络监控迈向全栈主动观测在传统物理网络时代通过网络流量分析平台首先实现了全流量网络监控能力其次实现了网络问题排障能力最后为其他部门提供了交易流量数据服务、网络性能数据服务。 到了云原生时代通过 eBPF 的零侵扰可观测性实现了主动的、全栈的观测能力。监控能力从网络的监控延伸到了系统监控、应用监控。数据服务能力除了面向网络人员的数据服务增加了面向系统运维、应用运维以及交易数据的输出。从网络监控迈向了全栈、主动观测4.2 未来展望下一步除了网络监控、系统监控、应用监控之外还需要对业务进行监控包括基于某笔交易流水号、某一类业务返回码、或者某个交易类型进行观测分析所以计划通过 Wasm 技术对数据包和系统调用进行深度的解码分析识别交易流水的情况从而实现面向业务交易的全景监控和可观测性分析能力输出。