DevOps 最佳实践之海量资源技术运营

DevOps时代

发布于 2019-03-08 15:04:22

1.4K1

发布于 2019-03-08 15:04:22

说明：本文根据腾讯熊普江老师在 2018 DevOps 国际峰会 · 深圳站的分享整理而成，经熊普江老师审理发布。

作者介绍 熊普江，互联网技术精英俱乐部广州会长、云技术专家、资深架构师。2012年-2018年任腾讯布道师、腾讯云高级总监，负责公司云技术、解决方案布道及技术架构评审等工作。曾任上市公司太平洋网络，视频公司PPTV高管；获2016年度“运维工匠“、2016&2017年度”GITC专家顾问“等称号，在互联网技术圈颇具影响力。逾 20 年互联网从业背景，对大型网络架构规划与建设，海量用户平台规划与运营技术支持，超大规模业务资源规划与技术架构管理优化有丰富的经验。

今天我给大家带来的分享是《海量资源的技术运营》，这里有几个关键字，一个是“海量资源”，这个海量资源，不仅仅是指腾讯业务涉及很多海量资源，实际上它还与大家的脑海里的概念是不一样的，等下我会介绍。“技术运营”这个关键词则是我们今天都可以感受到的重要性，今天我还会给它加上一个新的定语，将它称之为“精细化的技术运营”，并且会用一系列案例带给解析。

我会从三方面给大家做这个分享。第一会介绍现在做技术运营会面临哪些趋势和挑战，第二会分享在海量资源背景下，腾讯有哪些技术运营的实践案例，最后我们会归纳一下在云时代下我们怎么样做好这个技术运营，并形成一个方法论。

1. 趋势与挑战

首先来看一下趋势与挑战。其中第一个变化趋势非常明显，就是大家都在上云。我相信在场的没有哪一位没听过云，或者说对业务上云的趋势不理解，实际上如果是做技术运营的，多多少少都在用了一些云，比如CMDB也是云的一种形态。

最近几年，随着云能力的不断提升和大家有数字化转型诉求以来，这个趋势更是非常明显。基本上现在包括我们的政府，我们的传统的工业制造都在探索数字化转型，探索业务在云上实现。也就是说云计算现在已成为一种真正的生产力。

2018年在广东，大家应该都知道“数字广东”的项目，就是广东政府的各个民生业务上云，这带给我们带来非常多的便利。因此，我们现在做业务也要思考一下，可否用云，可否云化。

第二变化趋势就是微服务架构，实际上它是移动互联网时代技术演进的必然结果。我们最早IT系统是集中式架构，有了互联网之后，我们就是开始分布式的架构，随着移动互联网的到来，不断增强的敏捷开发、快速迭代的要求，以及上云的要求，使得我们的业务服务都是进行微服务化。

微服务可以让我们很方便地快速迭代，并且在业务升级的时候，相互不会受太多的影响，这也是DevOps理念中最关键的一点。

通过微服务可让我们的研发和运维有很好的结合，当然它也会带来另外的问题，就是微服务化造成业务服务模块的数量以几何级速增长，这使得业务部署、容量管理发生非常大的变化，这个趋势非常有挑战。

第三个变化趋势是AI。AI现在非常火热，现在做业务如果不跟AI关联上都不好意思同别人讲。实际上现在不管阿里、还是腾讯或者是百度，都在加大投入AI。腾讯而言，这里的战略就是“让AI无处不在”。

这个变化趋势也跟移动互联网，5G以及IOT连接数据、及数据应用兴起是一样的。这个变化趋势也是我们要注意的。我们大量的数据怎么应用起来，怎么样能够与DevOps结合起来，这是我们要思考的地方。

而且云已有很多现成的AI能力，我们可以直接拿过来使用。

介绍完三个变化趋势，在这个背景下我们再来理解下什么是海量资源。

我们以往理解的“海量资源”无非是有海量用户、海量请求，在后端有承载海量用户和海量服务的资源，包括服务器、带宽等，通过刚才几个变化趋势，我们对海量资源的理解应该有点变化：

第一，微服务、个性化的需求也越来多，微服务也成为海量资源之一；其次这种服务也是容器化的，容器的数量也是数以千计。这种数量级的容器管理也是海量资源管理；另外，我们的海量资源，除了传统服务器数量多少、带宽多少、专线多少，实际上还包括云的资源（云主机、容器、服务，云函数、PaaS服务、SaaS服务都是），以及包括我们现在积累的那些海量的数据也是一种海量资源。

因此，在云时代或者说数字化比重越来越重的时代，我们海量资源的运营和挑战包括这几个方面：

首先是始终要坚持用户价值。在座的可能很少花时间深入思考真正的用户价值表现在哪些方面？我认为价值表现之一是每做一个服务、或做一个产品，一定能解决用户的某个痛点或者某方面的问题；

价值表现之二是能够帮助用户提升效率或者是节省成本，即效率的提升；

价值表现之三是我们给用户带来的服务是非常稳定、非常安全的。

这个与刚才赵班长讲到的业务服务受DDOS攻击，实际上对用户的体验，对用户的价值已造成一定的伤害，我们要将防DDOS攻击的技术应用上。这是关于用户价值的挑战。

其次，随着业务用户规模的增长，我们用于承载服务的资源的必然上升，带来的运营成本就会一直增加。

做过预算的同学应该知道，实际上我们的运营成本基本上是呈梯形往上走的，今年最高成本消耗往往是下一年最低成本的消耗。这里促使我们要思考怎么样能够面对成本快速增长的压力。

最后，我们做技术运营的同学（或者做运维的同学），经常会收到来自于我们的领导或者我们其他的团队的质疑：就是这个技术架构到底是不是好的？外界同行是不是这么做的？当然我们也要经常自己思考，与其他竞品相比，是不是能够有技术领先性，这也是在新时代下面我们要特别思考的技术挑战。

2. 海量资源技术运营实战案例

讲完趋势和挑战之后，接下来我们来看看腾讯海量资源下面，对业务所做的一些精细化技术运营的案例。

在看这些案例之前，我们先介绍一个怎么样能够做好技术运营的理论依据。这其实是我们多年技术运营总结出来的最重要的观点：那就是通过技术架构的评审来帮助我们把技术运营做最好。因为技术架构决定了我们的运营效率和用户价值。

技术架构包括三方面：第一是技术框架，即业务系统采用了什么样的框架和技术；其次是业务逻辑的合理性，以往大家做运维可能很少考虑这块，今天我们的观点是大家要非常重视和理解业务逻辑，整个的业务逻辑是不是合理；还有业务的实现算法，我们以往只关注OPS那块是不对的，现在做看到DEV的算法。

关于运营效率方面，我们做运维，对业务后面的运营效率数据是有掌握的，我们知道的瓶颈在哪里，也知道单机性能，但实际上，我们现在还要往前走一些，通过技术架构厘清它是怎么影响我这个运营效率的。

最后用户价值这里，就是我们怎么能帮助用户的价值体现，能帮到用户效率的提高以及用户用的更放心，对使用我们的服务用的更放心。这是我认为的做好技术运营的理论观点，就是技术架构的评审会决定我们的运营效率。

第一个案例，是关于“微信业务”。微信业务很早就是微服务化的，我们知道微服务概念出来到兴起，实际上是2014年以后，而微信是2011年出来的产品，所以很早微信就主张微服务化了。

到现在，微信有超过5000个微服务模块，这些模块要应对10亿活跃用户的访问，其编排和调度肯定是要非常高效。微信使用自研的YARD系统实现容器的编排和调度。

YARD是两层架构：资源管理与应用调度，这两层可根据资源的状况将不同的业务进行合理与高效的调度。比如资源管理会判断与汇报自己节点的状态（包括健康的状态和资源利用率）情况。

在应用调度上，有哪些任务，怎么编排，怎么调度以及执行结果的反馈。目前来说，使用YARD系统进行微信业务容器编排和业务调度已经覆盖超过80%的微信微服务模块。

容器的编排和调度对于海量微服务非常重要，实际上它还带来一个技术运营效果：能够将节省大量的资源。因为我们每个业务功能不一样的，业务的特征及流量峰值也有可能不一样，如果调度效率非常高的话，我们就可以将不同业务峰值的业务进行错峰的调度。

左边是模块A的三张业务特征图，模块A有一个峰值点在凌晨00：00，在这个时候会发放新一天的游戏礼品，很多用户会在这个时候领取礼品，所以就造成了峰值（如果不扩容的话，这时集群里的主机CPU利用率都超过80%，实际上已经到了瓶颈；从另外一张快速拒绝请求数的图中，我们也可以看到是快速被拒绝的量很大，这个时候会影响用户的体验，因为一些服务被请求拒绝掉了）。这是A模块的业务特征。

我们再看模块B，在00：00的时候看调用量不是很高，CPU利用率很低，不到15%。如果我们的容器编排和调度足够强大的话，就可以将A业务在峰值到来之前把它部署到B这个模块上面来，也就是说这里也提供A业务的服务，实现了业务的扩容。如果没有调度能力，这个A模块要加服务器。

如果有调度能力可以在之前把业务部署起来，我们看到，部署起来之后看到原来CPU利用率超过80%，现在只有60%。从业务的体验上来看，原来有很多的快速拒绝量，现在的快速拒绝量几乎没有了。

显然强大的编排能力能够快速调度与部署，可以大大节省运营成本，同时业务体验得到了提升。微信的这个业务编排能力当然大家还不能使用，但腾讯已将这个容器编排与调度部分能力在云上进行了开放，就是腾讯云上有的两个产品：TKE与CIS。大家有需要可以尝试，都是免费的，特别是当前微服务较多，而且希望加强这种调度能力的话，可以尝试这两个服务。

接下来看第二个技术运营案例：微信的收发消息。大家基本天天都在用微信，所以微信收发消息量是非常大的，现在每天收发消息的体量可能超过5千亿条。这肯定需要很多服务器资源支撑，业务的调用请求也是海量的。

我们通过分析微信收发消息的模块，可以看到其中的它是怎么微服务化，以及怎么针对性进行精细化的技术运营。即使是一个单聊消息（用户A发消息到用户B的过程），通过这张图可以看到也很复杂，一条消息从A用户发到B用户，它要经过接入层，发消息的逻辑层、帐号的查询、帐号的存储、帐号属性、反垃圾处理、通讯录查询、序列号生成、消息体、推送等等这么多过程。

显然发送一条消息，在消息请求处理方面会带来后面十多倍的放大。如果说操作系统层面的能力如果不优化足够好的话，单机的性能根本上不去，所以我们后面针对操作系统做了很多优化，最终使得单机处理这种海量请求，并发可以达到每秒达到200万次。

第二个精细化的技术运营手段是尽可能减少调用层次。由于调用放大的非常厉害，减少调用层次可以大大减少处理资源。因为减少调用层次，请求处理就少了，处理性能也上去了，消耗的资源也必然减少。

第三是均衡请求，因为我们的服务器性能多数情况下是有差别的，另外即使服务器是一样，但是分配到的请求数也可能是不一样的。所以请求分配不均，会造成同样的机器，有的机器负载高，有的低,而扩容往往是按峰值负载进行的；这种情况没处理好的话，就会导致我们有很多机器的利用率上不来，造成很多成本浪费。所以我们就有一个优化，专门针对把机器容量与负载能力，均衡其处理的请求。确保同样的机器，可以达到同样的处理能力，这非常关键。

还有很多精细化技术运营手段，比如怎么样合并一些请求调用，因为合并调用可以将多个请求做成一个请求下发下去；比如新业务使用新服务器。我们经常面临有新的微模块和新的服务上线，一般来讲要为新服务准备一些机器和资源来承载，但是这些新业务服务很难知道到底需要多少资源量，我们采用的方法是设立一个新服务资源池，任何新业务或模块上线都上到这个资源池中，除非其到了一定体量才考虑单独部署，这样就能够避免一些业务后面跑不起来（事实是很多情况下新业务都不如预期）的占用多余的资源。

接下来我们看微信朋友圈的案例。这个案例也充争体现了DevOps技术精细化运营。朋友圈内容大家知道是永久保存的。

朋友圈这个产品是融合了两个业务形态的：形态一是我们平常浏览的“发现”里面的朋友圈，那里面只会有2000条记录，它是一个时间线，从那里看到自己及朋友所发的东西；它实际上只是一个索引，而真正保存个人发布朋友圈的内容是在“我的相册”里面，这是朋友圈内容真正存放的地方，即形态二（相册），相册里的数据是永远保存的。

朋友圈的体量非常大，其中最多的是图片、视频，要知道朋友圈每天图片的发布量都是数十亿次。这里面临的挑战是，它是永久保存，而且增量非常巨大，每天都是几十亿张、上百亿次的请求，矛盾在于如果保证用户体验，必然要用很好性能的存储，而每天的增量又非常巨大，这个存储如果全部用高性能存储，成本增量又非常巨大，巨大到难以负担。

这时精细化技术运营就发挥作用了，通过技术运营我们会朋友圈的数据访问冷热非常明显：朋友圈存储的数据中，针对一天之内的请求（即访问一天之内发的朋友圈）有70%，就是大部分访问都是访问当天的，70%的请求都是看这个朋友当天发的朋友圈，而一天内发的量占总存储0.3%。同时我们看到一个月内的请求占了90%，也就是说看朋友圈基本上90%的访问都落在一个月内数据中，这正说明了朋友圈数据的冷热是非常分明。

架构上实现能否实现：保证用户的体验，要非常快，将在一个月内的数据保存在很高性能的机器上面，这就是热数据集群；超过一个月就放在冷数据集群里面。这样的话，热数据集群几乎很少增长，因为一个月热数据也只占整个存储量的6.5%。

通过这种冷热分离架构，一方面尽力保证绝大部分用户请求读取的性能，同时大幅度降低运营成本。大家仔细思考一下，基本上热数据集群不怎么增长，主要增长来自冷数据集群，而冷数据集群相比热数据集群，量大但成本低（同存储容量的冷集群成本还不到热集群的1/3）。通过我们的架构优化使得用户体验得到提升和且成本大幅下降。

我们再看微信公众号的案例。公众号主要是图文消息，针对图文消息，技术运营上也有很多可精细优化的地方，特别是图文消息带宽资源的消耗，因为每天的公众号文章的阅读量是超过30亿次的。怎么精细优化图文消息的带宽资源呢？我们尝试把带宽流量细粒度分解，按访问的图片尺寸大小、每种图片类型访问，访问来源等等进行分解，我们了解到用户在哪里，看什么图片，看什么格式的图片，有针对性的优化。

当然我们还有很多维度的数据，这里没有展示出来。优化包括：如果用户上传的图片是低压缩率的格式，就进行重新编码转化，比如转化成WEBP或者HEVC格式，压缩之后会降低30-40%的存储量。

比如GIF是动图，在整个公众平台别然只占7%的请求量，但是GIF请求的带宽却占了60%的带宽，我们可以抓住GIF进行优化，可以减少真、颜色、还可以将它变成JEPG的图片，只要找到矛盾点我们就一定能够进行优化。

再看一个案例就是C2C视频。我们的微信消息里面，富媒体消息越来多，就是C2C视频越来越多。视频首先为保证体验，我们做了很多加速点，让用户就近上传、就近下载，中间还要保存很多份存储。由于用户下载收取视频量非常大，C2C视频的带宽资源消耗是非常大的，包括它占用中间的专线也非常多。

同样，精细化技术运营需要将它分解，我们怎么能够减少中间端线的传输，减少用户拉取的带宽，都有很多做技术运营的地方。C2C视频这块，我们做过这些：存储的格式进行优化：视频有H264格式，可以优化编码成H265的格式；质量系数，有些不需要那么高清的视频，比如说教学视频，帧率或压缩比可以下降一些，用户体验可以接受。高峰期的限数、下载去重、有害视频去掉等等。

我这里主要讲两个：一是边下边播。如果一直用微信的用户应该知道，以前发一个视频，在观看前需要先将这个视频下载完，但我们经常发现下载完成的视频是以前看过的，这时多数会立即关掉，这种场景实际上浪费了一次下载的带宽，而且在下载这段时间里，用户等待很久（体验较差）。

我们通过数据分析，就建议产品做一些优化，优化成什么呢？就是边下边播，做到点开就可以播放，关闭即停止。只要视步下载的速率快过播放的速率就可以了。这样如果是看过的视频，即使马上关掉，下载也终止了。这个优化实际上已经减少40%的带宽消耗，这是一个巨大的优化量。

另一个是视频外调。CDN带宽相对较便宜，我们会将热点视频调度到CDN节点上去，但当热点过去之后，CDN节点会清除这个视频（即CDN没有缓存了），如果此时来一个访问，CDN又要回到中心节点上再拉取一次吐给用户并缓存（注意此时浪费了一次回源带宽）。

这种非热点的CDN访问，是没必要让它再缓存一次，我们可以改变缓存策略：即用户从这里访问，发现这里没有，直接302跳转到源节点，并记录跳转频率与次数。当然这个当海量用户访问的时候效果比较明显。

再看一个案例，TDW平台的精细化管理。大数据也是一种资源，相信大家在自己的业务里面也在慢慢积累这个大数据，对大数据的管理也越来重视。然而大数据管理会有很多坑，比如说我们这个大数据会增长很快，但有一些数据我们搜集下来从来不被使用，这是一个“沉默数据”的坑，就是很多数据搜集了，但是从来不被访问到。

还有就是数据处理完了之后，这个数据或处理结果也不被访问，实际上这也是沉默数据。沉默数据如果不及时清理，会占据你大量的存储，达到腾讯这样体量的话，存储增长就非常可怕。

我们还看到一个坑是“生命周期”，我们进行大数据管理特别要求搜集的数据要有一个生命周期的管理，即存储数据必须指定数据保存多久，这是生命周期。还有其他一些坑，如大数据经常有数据分析任务，这些分析任务中有些任务处理的非常慢，处理占用很多资源，我们要把比较慢的任务找出来看看它是不是能够有优化，提升效率。

还要要将空的任务或者无价值的任务管理起来。数据平台上有不少任务在处理数据，但处理完了结果没有人看，那就是空跑空转的任务；还有就是一些任务因为数据或环境的原因，运行起来实际上都不成功；这些空任务与无价值任务都要清理，可以节省我们大量数据存储的服务器和计算的服务器，所以这块的话这种大数据资源我们怎么样能够有效的利用也是非常重要的。

最后再讲一个案例就是微信运动。相信很多也有很多小伙伴在用微信运动，它每天都有一个排行榜。

一般地讲，一个用户加入使用微信运动就会多了一个排行榜处理需求，我们的业务部门按照这个逻辑来进行推导支撑资源的需求，如果大量用户使用微信运动的话将会使用大量的资源，实际上这个算法是值得探讨。后来经过评审，我们推荐业务侧使用全局的排行榜。

以往有4亿人参加微信运动，可能要排序4亿次，如果使用全局排行榜的话，运算资源量会有少量增多，但全局排序完之后，所有的序都不用排了，因为其他单个用户的排序都是它的一个子集，即只要把这个用户的朋友抽出来就可以了。

通过算法的优化，基本上所有的业务量增长的支撑需求跟资源没有什么关系，这样的精细化优化节省超过80%的资源。

其他包括原创保护（微信公众平台推出的文章原创保护能力），需要对比文章“指纹”信息，是不是原创的，其实有点类似于我们的病毒库，这里有一些算法是可以优化的。

3. 技术运营方法论

刚才同大家分享了海量资源技术运营，可以有很多精细化的DevOps实践，我们总结一个DevOps背景下的技术精细化运营方法论。第一就是我觉得我们DevOps未来很多业务都要考虑上云。

上云的话，云的资源也变成我们的一个海量资源之一，我们怎么样很好的管理这些容器和无服务器计算，怎么样调度管理的，这个是大家要关注。

关于云的开发模式，幻灯片下部分有两个数据可以说明，未来这种云的开发模式可以大大提升我们的效率。

我们将云上的AI能力和技术直接拿过来用，可以大大提升我们的AI开发效率，比如说上传下载技术能力（左边是上传下载），用户通过云存储和调用我们可以提升571倍效率，比如说数据库读写技术能力（右边是数据库调用接口），这个效率来实现数据库查询和读写效率能提升上千倍。

第二点的是说实施DevOps要特别注意容器也是一种资源，云函数也是一种资源，怎么样能够有效的管理和调度，这是我们要思考的地方。

通过架构评审，可以帮助找到技术运营的细节点，能够有效的提升我们的运营效率，这就得出了我们技术运营的总体方法论，包括：不管是服务器资源还是带宽资源，还是其他海量资源，我们要做细致的分解，就像我讲的公众平台的带宽一样，分解清楚每个构成，给出技术架构图，关联的每个点都把它列出来；有了这些之后，我们就很清楚在哪几个环节可做优化。

优化也不是说面面俱到、每个都抓，而要抓某主要矛盾，就像跟我刚才说到GIF优化，70%的请求调用量占了60%的带宽量，肯定要先解决主要矛盾。通过技术架构梳理与深入了解、分析，平时就能够给开发，产品团队提出一些优化的方案，包括技术架构做一些调整，比如说冷热分离，比如说算法上使用全局排序方法，都能大大优化产品的体验，降低成本。

这个实现之后技术运营还要两手都要抓，一是抓产品策略，比如边下边播（过去是先下载过来看，等待体验稍差，虽下载完成了肯定能看，但会有资源浪费；但是如果改成边下边播就可以提升用户体验，当然也可能会产生卡顿的不好体验，但可以大大节省成本）。

另一手是抓技术，通过我们的技术手段和我们推进让产品经理去做产品策略的调整，都能够帮助我们提升用户价值。