网站做信息流,做实验网站,百度小程序,网站设计的性能需求微博现在日活达到了 2 亿#xff0c;微博广告是微博最重要且稳定的收入来源#xff0c;没有之一#xff0c;所以微博广告系统的稳定性是我们广告运维所有工作中的重中之重。 作者#xff1a;孙燕来源 微博现在日活达到了 2 亿#xff0c;微博广告是微博最重要且稳定的收入…微博现在日活达到了 2 亿微博广告是微博最重要且稳定的收入来源没有之一所以微博广告系统的稳定性是我们广告运维所有工作中的重中之重。 作者孙燕来源 微博现在日活达到了 2 亿微博广告是微博最重要且稳定的收入来源没有之一所以微博广告系统的稳定性是我们广告运维所有工作中的重中之重。 图片来自 Pexels 微博广告的运维主要负责资产管理、服务稳定性维护、故障应急处理以及成本控制等多个责任。 微博广告运维发展经历了如下阶段从早期小规模的手工运维到工具化运维随着服务器数量的发展业务模型日渐发展开发、运营、QA 都参与到产品的生命周期中我们现在也进入了自动化运维的阶段在新的虚拟化技术、算法技术的驱动下我们也在朝着 AIOps 的方向努力。 在整个运维过程中我们遇到了很多痛点幸福的人生都是一样的不幸的人生各有各的不幸各家的运维都各有各的痛点。 我们的服务器在 3000 台以上业务线及辅助资源各种各样产品迭代非常快且依赖关系复杂流量变更切换损失不可接受。 在这种情况下我们面临资产管理困难、环境不统一、上线难度大、运维成本高的问题。 基于这些问题微博广告运维工作主要集中在以下四个方面 运维自动化弹性计算智能监控服务治理 运维自动化 一个健全的自动化运维平台必须要具备如下几个功能 基础监控资源管理事件集中分析配置管理批量运维工具持续集成和发布 基于这些功能和需求我们广告运维自主研发了 Kunkka 平台(微博广告运维自主研发的自动化运维平台)、资产管理、自动化上线等运维平台。 资产管理是基于公司 CMDB(公司级别的资产管理系统)获取到主机云服务器针对微博广告对资源的管理需求自建定制化的资产管理平台。 配置中心包括服务注册、服务配置等功能;自动化上线涵盖了开发在上线过程中所需要的节点和流程。 自主终端是行业变化的功能实现大家可以通过页面完成文件或命令下发、日志审计等各种工作。 Kunkka 基于主机和容器通过 Salt 作为传输层进行命令下发组件层包含开源软件操作层将命令页面化通过页面进行日常工作和管理。 这样的自动化运维平台基本上满足了运维的日常操作需求在 Kunkka 平台中还有自动扩缩容的功能我们针对这个功能进行延伸。 在自动扩所容的基础上根据时间段流量进行动态判断自动决策的扩所容够功能。 弹性计算 为什么需要弹性计算 首先在产品方面我们的产品线很多依赖关系比较复杂。 微博广告相当于一个桥梁左边连接的是广告主右边连接的是客户需要将广告主的广告计划转化为用户的需求让用户看到自己想要看的广告。 为了满足两边不同的需求产品的变更和发布非常重要且频繁。 其次在运营方面很多有推广需求计划的大型活动都有临时扩容需要比如 618 跟双十一对于我们而言这两个活动带来了很大的冲击。 在 618 和双十一大促之前为了加大自己的影响力各个广告主会增加广告计划微博广告这边再针对广告主的行为加大我们的曝光量实现广告主广告计划的转化。 在 618 和双十一大促之前为了加大自己的影响力各个广告主会增加广告计划微博广告这边再针对广告主的行为加大我们的曝光量实现广告主广告计划的转化。 传统的业务运维 按照传统运维模式扩容计划从立项到服务器上线会经过诸多的流程跟漫长的等待。 从结果上来看服务器扩容了而且对传统项目而言整体流程都是可控的这是它的优点。 它的缺点不言而喻有以下几点 首先它时效性太差如果按照新浪服务器的采购周期从审计到上线需要两个月的流程。两个月后服务器上线恐怕刚结婚的明星都已经离婚了突发事件流量都已经过去了。 另外它无法准确预估容量在传统的业务运维模式下范冰冰分手、双宋离婚带来的流量是无法实现的我们无法评估扩容量。 除此之外传统模式下资源利用率比较低服务器很难在业务间共享。 在这些问题共同作用下催生了动态扩缩容体系。 弹性计算实时动态扩缩容 动态扩缩容不是一个工具是一整套体系。它基于云服务包含了在线压力检测和消耗度评测的功能最终实现分级治理。 ①弹性计算架构 首先简单介绍一下弹性计算的架构弹性计算依托于 Kunkka 自动化运维平台以及 Oops 监控平台在业务压测的情况下获取业务指标监控将数据送到容量决策系统做出是否扩缩容的决定。 在云服务商方面我们常用阿里云、华为云跟一部分自建的私有云。DCP 混合平台是我们微博另外一个团队做了几年的平台它能够对接云服务快速生成云主机快速扩容。 今天的重点跟业务方有着最直接的关系业务上要不要扩容?什么时候扩容?扩多少?我们要解决这样的问题。 ②决策系统 在上文的架构中我们提到了容量决策系统容量决策系统实际上指的是计算系统会对我们获取到的业务指标进行计算、评估。 比如系统的基础信息、一些业务上日志来源的信息等得到当前业务的容量通过对历史数据进行同比、环比的分析得到流量趋势了解接下来流量会变成什么样子这两组数据计算结果会给出扩缩容的建议。 同时他们会计算这些数据并予以呈现提供一个辅助的 API 接口给上下游部门做扩缩容数据。 ③容量评估方法 这个业务的当前容量是什么样的?是不是健康的?这个指标靠什么来评估? 由于业务系统、业务形态、架构的不同选取一个实时且通用的指标是非常具有挑战性的我们也尝试了很久引入了 AVG-hits 的概念。 对于处在不同时间内的请求数进行加权、求和来拟合实际的单机消耗量这个代表的是在不同的区间的耗时数我们给它一个系数大于 5 毫秒小于 10 毫秒根据自己的业务给予耗时分区这样就能计算出来。 事实证明与之前传统的单一 QPS 负载对比起来综合的数据对业务的评估比这种单一指标是更加准确的。 在获得这个数据之后是不是就能够描述当前的系统容量呢? 回答是肯定不能AVG-hits 这个概念第一次接触确实是有点生涩举个简单的例子来帮助理解比如说某个业务消耗指标衡量非常简单需要通过内存判断消耗情况。 如果监控指标提示内存消耗到 80G那能不能用 80G 来描述当前系统的消耗情况? 这样问就比较容易理解回答肯定是不能的因为不知道服务器最大的内存是多少如果最大是 96G那么 80G 已经超过 80% 了接近危险值如果最大内存是 256G 则消耗不到 30%是非常安全的值。 道理是一样的仅拿到当前消耗值是不能对业务当前状态进行描述的还需要另一个评估标准。 这个业务当前能承载的最大容量是多少?如果是看内存就简单了可这是一个综合评估标准要怎么拿到它呢? 作为一个有经验的运维我觉得根据服务器当前硬件的表现猜测最大容量不是困难的事情但现在都 2019 年了靠猜是不行的我们通过压测获取最大容量值。 在实际环境中减少服务器数量减少到不能再少记录当前的容量值作为最大容量用压测开始之前的实际消耗值除以压测获取的最大容量得到整个系统的消耗比。这个消耗比就认为是当前这个系统消耗的画像。 压测压到什么情况下达到最大容量不能再压呢?是要压到服务器宕机? 我们接入了另外一个概念叫消耗比在耗时最大区间的 Ahits(请求数量)数(PPT 上显示慢速比100.0*当前容量(Ahits)/最大容量(max_Ahts))与总的请求数之比超过一定的比例则是影响用户的体现。 这个压力达到最大值就不能再压了就会记录当时的 Ahit 数作为这个接口最大容量。 ④分级治理水位线 现在拿到了一个非常重要的容量值及消耗比来进行容量评估用于描述当前的容量消耗情况。 拿到这个消耗比之后是不是就可以扩容了?还是可以缩容了?此处还需要一个评估标准是 30% 就扩?还是 50% 再扩? 我们基于历史数据给予分析制定了三条水位线包括安全线、警戒线和致命线拿当前消耗值与水位线进行对比在不同阶段采取不同的措施。 比如现在的消耗度远远低于安全线说明现在服务器部署有冗余我们可以进行逐步的缩容。 如果说现在已经高于致命线则需要扩容让这个值更加接近安全线保证系统的稳定性。 ⑤在线容量评估体系 现在自动扩缩容的三个要素当前消耗、水位线、容量决策系统都已经具备了我们如何把这三个点联动起来?如何让它串在一起完成扩容动作?这些环节都包含在在线容量评估体系内这个体系可以实现压测的过程。 我们刚才说了压测不是通过流量拷贝进行模拟测试的我们是针对目标服务就用线上的流量记录当前(Ahits)数开始减少服务器的数量一直到慢速比达到临界值的时候记录 Ahits 数作为本服务单元最大的消耗。 得到消耗值后和水位线进行对比调用决策系统做出是否扩缩容的决定接下来再对接云服务商就完成了扩容的动作。 ⑥实时演练体系 前面进行的数据采集、计算以及动作的串联都是为了完成最后一个目标服务扩容成功。 真正的服务器扩容到线上之后怎么样才能保证服务是健康可用的呢?我们还有另外一套辅助系统叫扩容演练。在实时演练过程中要注意以下几点 部署效率我们通过扩容演练来寻找整个扩容过程中的瓶颈比如我们下发是通过 DCP 对接云服务商来完成扩容的。 在真正的线上扩容过程中DCP 有时要同时承载几千台节点的扩容并发。DCP 的效率是否能够满足?在扩容演练过程中需要确认这一点。 带宽限制微博和云服务商之间确实是拉了专线但是微博和云服务商不只是微博广告的一个业务还有很多其他大户。 而且一般在流量增加的时候他们的扩容也是非常猛烈的所以带宽是否可用也是我们在日常演练过程中非常注意的现象。 依赖服务这方面有很多案例在这里简单分享一下2015 年春节自动扩缩容的流程才刚刚开始春节当天晚上我们扩容完几千个节点后忽然发现负载均衡加不上去。 之前做过演练但不会拿几千台云服务器进行扩容可能几十台确保功能可用就可以了到时候要让负载均衡的同事通过配置文件增加下 Memeber 就可以。 如果上千台的服务器没有办法增加到负载均衡设备那个时候大家手忙脚乱最后通过手动的方式扩容节点。 大家知道春晚的流量高峰很短但那天确实给了我们当头一棒。接下来我们在扩容演练过程中不仅会对负载均衡进行确认还会对我们依赖的服务进行确认。 比如每次发生热点事件时大家会说微博又崩了评论又崩了热搜出不来了。 其实应对峰值流量是件很头大的事情我把事情解决了兄弟部门没有解决兄弟部门解决了姐妹部门又出现了问题。 安全限制618 大促时京东的同学分享了在扩容的时候新增的服务器 IP 与 VIP 发生了冲突而微博主要的体现就是数据库会对很多业务的请求设置白名单可是云服务器扩容之后 IP 是随机的。 另外新浪对于通行证有很多 IP 限制所以我们通过扩容演练体系不断发现各个环节中的问题加以解决保证在扩容动作进行时能够顺利地完成保证扩容出来的云主机真正安全上线服务。 有了这个系统的加持截止到现在自动扩容服务都处于比较稳定的状态。 智能监控 在上文提到的自动扩缩容体系当中提到一个叫 Oops 的系统这是微博广告运维人员建立的智能监控系统接下来给大家简单介绍一下。 监控面临的挑战 说到监控不得不说监控遇到的很多问题。市面上有很多开源的监控软件比如说常见的 Zabbix在监控数据量少的情况下不管是基础监控还是业务监控这些开源软件都是可以直接满足需求的。 但是随着监控指标的增多加上我们的指标是实时性变化的数据要求又比较高这些原生软件不再满足我们需求了。 另外微博广告的业务数据有特殊性一般运维关注的数据是系统的性能系统的性能数据有时候来源于业务日志。 但是微博广告的业务日志是收入很多业务日志是一条都不能丢的比如说结算的曝光。 每一条曝光对于广告来说都是真金白银对精准性要求比较高单独通过性能监控的日志收集方法是不能满足需求的这也是我们面临的挑战。 另外监控系统一般都会具备告警功能有告警就会有告警问题接下来会详细地介绍告警问题。 还面临定位方面的挑战在监控越来越完善的基础上很多开发的操作情况发生了变化。 一旦发生问题第一个反应并不是上服务器看一下系统怎么了而是翻监控看看哪些监控指标发生了问题所以监控系统会越来越多地面向于问题定位这个方向。 Oops 整体架构面临的挑战 作为监控系统Oops 在架构上并没有什么出奇的地方所有的监控无非就是四个阶段 从客户端进行数据采集数据的清洗和计算数据存储数据展示 监控数据流向特点 所有的监控系统都逃不开这四个阶段只是根据业务的不同进行了定制化的工作。 针对广告业务的监控流向我们把数据分成两类有一部分精密数据的计算我们采取的是离线分析的方式通过采集软件将所有的日志采集到 Kafka通过计算的工具进行拆洗、计算计算之后落存储。 还有另外一个团队开发的针对于这一部分数据的页面展示化还有一个系统叫 Hubble针对精细数据的展现实现个性化定制的展现。 另外一部分是运维比较关心的数据今天来了多少流量?流量有多少是正常的?有多少是异常的?平均耗时是多少?针对这一部分我们采取了实时数据计算的方法。 在数据采集阶段发生了变化我们并不采集全量日志而是在客户端做了预处理进行分类计算。 比如说监控数据就按监控数据的方法计算;告警数据就按告警数据的计算。而且按照用户读取的需求进行分类存储保证了高并发数据的实时性。 海量指标监控系统流程 接下来详细介绍实时数据计算。 首先从数据采集上讲上文提到我们不采取全量的采集方式而是通过 Agent 对数据进行处理。 在数据采集阶段在数据产生的服务器上针对不同的需求按不同的时间进行分类聚合最终向后推送的数据是 key-value、计算方法这种模式推送给 Proxy。 Proxy 拿到已经被打包的数据进行拆包然后送给不同的计算结点再按照 Key 进行计算打时间戳。 这个数据并不精准但我们可以接受部分损失只需要保证数据的趋势是正确的。 另外关于分类计算不同的需求推送给不同的计算节点。存储也进行了分类实时性要求比较强的话会直接放到内存以最精细粒度进行存储。 前三个小时的数据是按秒存的按天计算的数据是按 10 秒、30 秒存的一些单机数据是按分钟存的。 另外一些历史性的数据需要出报表的比如说要看前一周的数据前一个月的数据按照大数据的方式存到 OpenTSDB 当中。 存储的数据提供一个 API通过 API 我们进行了分类计算、分类存储这种分类的需求来源于用户需要看用户有什么要求要什么样的数据。 比如Dashboard 的展示数据会直接被放到内存里。另外上文提到的在线扩缩容数据会相应获取数据给用户其他相关的获取需求 API 也会进行分类获取。 接下来我们计算过的数据还有一部分会存储到 Redis 通过 WatchD 作为告警中心的数据因为告警数据一般都只要求当前数据不会有人需要查看上个月这台机器的负载有没有告警。 所以 Alert 节点计算之后的数据直接存在 RedisRedis 把这个数据拿出来之后经过告警中心根据告警规则进行清洗通过各种方式推送到需求方。 同时有一个相对个性化的展示叫九宫格。我们的九宫格实际上是一个结合报警功能的监控它是一个页面但具备了告警功能。 接下来看一下监控图下面三张图是范冰冰宣布分手拿到的流量我们的反映是非常灵敏的平均耗时也涨上来了。 第三张图是拿到这些数据之后自动平台显示应该扩容了。蓝色跟绿色的流量线已经降下来了大部分量调到云服务器上。 下图是我们的九宫格因为时效性比较强正常来说是以产品为页面以业务线为格子每个格子记录的是单机的详细信息。 如果在这一组服务器当中单机故障数超过一定的比例这个格子会变颜色。 所以在正常的运维工位上都会有这样的大屏幕运维可以一目了然发现自己所有负责的业务线情况而不是让一台台机器在这里展现这样就没有办法看到业务线情况了。九宫格可以让运维更加直观地看到当前的告警情况。 告警 告警有很多的问题我们遇到的问题可以分为以下四个方面 ①告警数量巨大 运维人员需要关注所有部分从系统到服务、接口等等维度很多一旦有问题各种策略都会触发报警报警数量多到一定程度基本上等于没有报警。 ②重复告警率高 告警策略一般会周期性执行一直到告警条件不被满足如果服务一直不恢复就会重复报下去另外同一个故障也可能引发不同层次的告警。 比如我们有一个业务线叫超粉会有 360 台服务器流量高峰时 360 台服务器会同时发送告警这种告警的重复率很高。 ③告警有效性不足 很多时候网络抖动、拥堵、负载暂时过高或者变更等原因会触发报警但这类报警要么不再重现要么可以自愈。 比如一个硬盘在接近 80% 的时候开始告警了你让它告吗?好像得告但似乎不告也可以。 ④告警模式粗放 无论是否重要、优先级如何告警都通过邮件、短信、App PUSH 发送到接收人就像暴风一样袭击着接收人接收人没有办法从中获取到有效的信息经常会让真正重要的告警淹没在一大堆普通告警中。 针对这些问题我们采取了以下措施 ①抖动收敛 对于这种大规模服务器的维护抖动是非常常见的现象。网络抖一抖整个服务单元就会向你告警。 针对这种抖动我们增加了一些策略抖动的时候会前后比较监测重复性看看是不是具备告警的意义通过增加告警策略这种方式来进行收敛。 比如说流量突增的时候需要查看是不是同单元都出现了这个情况。 ②告警的分类和分级 详细定义告警级别发送优先级、升级策略等可有效减少粗放模式下告警接收量。比如一些低优先等级的告警会让它告处理的级别会低一点。 ③同类合并 同一个原因可能会触发一个服务池里面的所有实例都报警比如同时无法连接数据库其实只需要报一次即可。 ④变更忽略 我们的好多变更都是在 Kunkka 平台上操作的开发有时候会选中一个通知现在是变更告警请忽略。 以上措施能解决告警问题中 80% 的问题现在大家都在朝着更高级的方向发展我们也简单做了一些探索。 在原有告警数据流情况下引入了工具 SkyLine这个工具包含了多种算法在异常检测环节中能够通过它内置的算法将我们传入的数据自动去抖动提供平滑的数据等你再拿到这个数据时就不需要再检测是不是告警。 这个工具避免了人工操作通过 Skyline 将数据进行平滑提供一份准确的数据我们只需要通过这份数据进行规则判断决定是否需要告警就好了减少了对数据准确性判断的复杂过程。 接着是根因分析部分随着监控的覆盖面越来越广监控精确性越来越高。 等故障出现的时候开发人员就会去翻监控图去查看大概是哪些原因导致了故障。 随着 Dashboard 越来越多即便是经验非常丰富的工作人员也很难快速地定位到原因会出现哪个方面、该去看哪张监控图。 出现流量突增的情况时Skyline 会通过内部的算法 Luminosity 寻找相似的情况查看相同的时间内是否有其他地方出现流量异常并将根源问题展示在 TOPN 上。 这样就能够快速查看在故障出现的前后哪些业务也出现了流量变化方便对故障原因进行分析和定位。 服务治理 还有一项非常重要的工作——服务治理这里只进行简单的介绍。 为什么需要服务治理 微博广告现阶段所出现的问题主要有架构越来越复杂上文提到微博广告的服务器已经达到 3000 台。 所以在这种服务器数量情况下架构会越来越复杂稳定性要求也变得非常高;开发的多语言环境对上线发布也造成了挑战;资源使用是否合理对运维来说也是一个挑战。 低成本和高可用的平衡 针对这些问题我们进行了低成本和高可用的平衡争取用最小的服务器达到最稳定的架构。 在保证服务稳定的情况下将流量进行均分分到最小服务单元三机房部署为基本规则保障在一个机房挂掉的情况下另外 2/3 的服务器能承载全部的流量。 关于上下游之间调用的平衡尽量减少跨运营商的调用微博广告每一毫秒的消耗都会影响到收入。 我们的请求时间是 1 毫秒、1 毫秒地优化下来的这些损耗产生在网络和服务器上很难通过人力弥补因此在这方面我们也非常谨慎。 另外小功能会抽象出功能的共同点将这些功能服务化服务则按单元化部署。 服务发现及负载均衡 在服务治理过程中我们会根据服务的引入服务自动发现尽量减少服务变更环节的人工干预提高安全性和实时性自建负载均衡会有标准的数据输入和数据发布的过程可以大大提升后期的可扩展性和可用性。 服务治理成绩 经过近半年的服务治理我们达到了这样的成绩 架构更加强健容灾能力提高系统、数据、配置标准化服务器的合理使用成本控制 其中我觉得最重要的是系统、数据、配置标准化的过程。 今天好多分享的嘉宾也提到了 AIOps这些上层的建设都是依赖于整个业务标准化的过程。 中国有句古话工欲善其事必先利其器我们所有的标准化过程就是为下一步人工智能打下坚实的基础希望我们的工作能够以技术保证微博系统稳定助力微博广告的收入。 阅读目录置顶)(长期更新计算机领域知识https://blog.csdn.net/weixin_43392489/article/details/102380691 阅读目录置顶)(长期更新计算机领域知识https://blog.csdn.net/weixin_43392489/article/details/102380882 阅读目录置顶)(长期科技领域知识https://blog.csdn.net/weixin_43392489/article/details/102600114 歌谣带你看java面试题 https://blog.csdn.net/weixin_43392489/article/details/102675944