2018.12.28 丨 壹佰案例

TOP100summit分享实录 | 如何构建一套全链路的故障追踪和故障自愈系统?

2018.12.28 丨 壹佰案例


本文内容节选自由msup主办的第七届TOP100summit,三七互娱运维开发负责人童传江分享的《三七互娱故障追踪和故障自愈系统》实录。


分享者童传江在维行业7年工作经验,做过网络管理,做过应用运维,目前专注于运维开发,对于行业所要解决的质量、成本、效率、安全,有完整的交付和实践经验,爱好广泛,热衷于解决疑难问题和分享。



编者按:2018年11月30日-12月3日,第七届全球软件案例研究峰会在北京国家会议中心盛大开幕,现场解读「壹佰案例榜单」。本文为三七互娱运维开发负责人童传江老师分享的《三七互娱故障追踪和故障自愈系统》案例实录。


在实际运维过程中,因为业务系统越来越复杂,变更越来越频繁,总是存在各种各样监控未覆盖或者以前未知的故障发生。如何构建一套全链路的故障追踪和故障自愈系统,成了质量保证部门的刚需,通过行业标准化的PaaS平台模式和Trace追踪技术,从而实现整个架构的质量可控。


今天,我将从两个方面分享故障追踪的实例,第一方面,关于运维平台的整体架构,分别从成本、效率和质量三个维度解决的大致方向;第二方面,关于在链路追踪具体的案例实践。


运维平台的整体架构


现阶段,关于运维平台有三个大方向的问题需要解决:


第一个是成本,有些公司认为这个问题不是非常严重,但公司发展到一定规模,运维成本对于运维部门来说是一个非常大的挑战。像服务器、CDN、宽带的成本可以占到营收的百分之几以上,是一个很大的支出。运维成本核心要解决的是搞清楚具体钱花在哪个方向,并对这些成本问题进行优化。


第二个是效率,这是运维面临的主要问题。对于基础设施的交付、中间件的交付,或是代码发布,分解业务需求交付从上到下每一个步骤,并让每个一个步骤变得更快,这是我们要解决的第二个问题。


第三个是质量,这个问题很简单,业务是否正常、用户体验是否良好等,如果说有问题,到底哪里出现问题,这是运维部门要保障的。


那么,如何解决以上三个问题呢?


从技术方面来看,主要划分三个模块,第一个模块,对基础设施的交付;第二个模块,运维开发能力层面;第三个模块,前端接入层面。


从基础设施能力方面来看,因为运维的场景不同,现有情况在基础设施层面交付非常繁杂,有些应用需要裸机,我们就要直接进行裸机自动化系统完整交付;有些业务需要自动扩容,我们就要提供IAAS的平台;在基础设施方面,操作系统交付能力上有一个“封装”。将裸机,虚拟化IAAS,容器化IAAS,公有云统一向上封装。核心为提供操作系统能力。


从运维层面来看,第一块是CMDB,它包括了资产到应用,以及整个关联关系,所有需要关联到成本或质量的相关数据都存在CDMB中。第二块是任务通道,对所有下层交付的系统实现各种各样的自动化,通过任务通道来执行的,分化细节来看,提供了脚本执行、文件传输、配置分发、任务编排、定时调度、以及一套API。第三块是数据通道,以前的监控数据,日志数据、APM数据或者像交换机Netflow等各种各样的数据都在数据通道中。 数据通道的核心是做收集数据、传输数据、计算数据、存储收集、展示数据,数据通道核心在用一套逻辑,提供同一个数据处理能力第四块是第三方API,如上图所示,涉及到各种公有云,微信,DNS等平台。接入能力层面,主要是提供前端的WEB端,包括移动端app上的封装,关于API Gateway,我们现有的实现API网关主要做Web防火墙这样的应用规则。


现在,我们来详细看一下CMDB数据的具体模型。如下图所示:



CDMB主要分为两大块,第一块是资源,第二块是应用。资源是通用的,而应用这一块是应用分类、应用单体,这里要注意的是,所有的应用CMDB层面,我们是将它拆分到具体的PaaS平台,所有的应用和单体应用跑到中间件上面,而数据是记录在CDMB中的。如果说一个应用如果需要依赖集群,则需要Master、VIP各种各样的属性。实际上关联到基础设施的操作系统的进程上去了,所有运维的数据都是放入CMDB这张表里面,我如果需要解决成本问题,是可以依据一条链路的,先从业务出发,找到我的资产花费了多少,因为核心的成本在资产上,关于成本问题,我们可以通过CMDB将这个数据找出来。


关于效率问题,其实核心是在交付基础设施、交付中间件、交付代码做持续集成。通过基础设施的交付效率提升,中间件交付效率的提升,代码交付效率的提升,来实现到整体效率提升,所有的数据依旧是放在CMDB这张表里面。


关于质量问题,我们的业务依然是运行在中间件上,中间件运行在真实的资源上,在运维层面的上一层或中间一层保证业务的质量。


综上所述,我们大致介绍了一个平台最开始的整体架构,包括CMDB的详细解释。接下来,再介绍一下,在这个模型上如何对成本、效率、质量问题如何具体解决?


关于运维成本,CMDB简化了逻辑关系,固定资产存在账单,我们的业务存在收入,并不是说一个业务它的运维成本高,就一定有问题。实际上,我们是按一个收入占比的,运维成本高,收入也随着增加。基于以上,我们可以非常清晰的得到一个财务数据,这个财务数据的核心是某一个应用收入了多少钱,它的收入占比是多少。当然,因为有详细的关联数据,依然可以知道各种各样的钱花在了什么地方。


关于提升运维效率的大体方向如何解决?



我们对整个业务做了抽象,第一块作为基础设施,第二块是中间件这一层,第三块是持续交付,真实的业务在最上面。IAAS如何提升需求?我们在对于IAAS实现交互就像实现云平台一样,操作系统安装不管做自动系统安装还是云API,其他的IAAS提供一套统一的API/用户界面自己申请/自己获取基础设施的资源。


关于效率PaaS平台,在中间件这层,我们会使用MySQL。在产品集群把MySQL做成云化模型的管理模式,主要是在改变思路,以前的业务需要一个MySQL,DBA会给它一个MySQL。但实际在进行云化模式管理的时候,我们会将普通的MySQL实现成一个云化的产品,在业务需要时,它将自己进行申请。所有的自动化能够将一个MySQL集群实现成云化模式的话,核心需要的技术能力主要还是运维能力、开发能力、交付能力、平台能力。CMDB、数据通道和第三方API,我们只能使用基础的运维能力层,能够实现到类似于把普通的MySQL实现云化,比如,腾讯云、阿里云一样的MySQL集群,看一下详细界面,云化监控或是需要人工接入的都把它云化成云平台模式,提供给业务方块,自助操作。


在运维效率方面的提升,从IAAS、PaaS层面我们核心要做的是,虽然现在没有能力从技术能力、各个组件开发成一个云化产品,但实际上,我们在运维能力上能做到在产品层面类似于云的产品,提升运维的效率。


现在,我们详细介绍一下关于运维质量的方面。

关注质量解决的方式主要分为四大方面,如上图所示,我们对于应用依赖的模块做了抽象化,因此,下面两块是通用的;第一块,保证的是我们在IAAS层面或是操作系统层面的质量;第二块,我们所有业务都是跑在中间件上,虽然中间件是用了通用的开源软件,抽象化后依然是云平台;第三块,是关于链路追踪,这在下面会详细解释;第四块,是常规的业务本身的监控,比如,游戏行业有可能会游戏登录、注册、充值。对于IAAS、PaaS层面,主要核心是接入CMDB数据,让Open-Falcon数据和业务关联,实现最开始的监控。


链路跟踪技术的实践


链路跟踪是什么样的技术?我们在质量保证层面分为四块,IAAS、PaaS到业务本身再到链路跟踪,这项技术是基于中间层面的。

在微服务时代,任何一个应用完成时都要通过其他接口共同实现。如上图所示,如果这里是一个登录业务A,用户来登录这个业务时,先调用第三方API、D和E、存储、各自的中间件。用户A在登录的流程中,每一个细节都可以进行链路回放,能够清楚的知道,一个用户A完整的登录过程,以及具体细节。因为链路跟踪技术完成的整个细节,业界关于链路跟踪技术有非常多的实践,但我们在自己实现时,还有很多的困难。


想要完整的实现一个链路跟踪的基础,有哪些问题需要解决呢?


第一个,性能。我们现在是一个用于解决用户质量的辅助功能,在引入这个功能时,最好不要影响到业务,特别是有些业务对消耗性能非常敏感,引入链路跟踪后,为了保证用户质量而影响业务的性能,会不能被接受。第二个,应用无感知。我们现在引入一个新技术,对于质量保证,需要开发来配合。应用不需要知道跟踪系统的存在,也不需要开发二次配合接入。第三个,扩展性。业务随着规模增长,整套链路跟踪系统依然要能够满足对于系统需求的完成。


现在,我们来详细分析基于PHP链路跟踪自实现原地。在Java或是其他语言中,语言本身/社区本身对于链路跟踪技术是比较成熟的,我们可以直接拿来用,但是对于PHP技术,已实现的大部分都是侵入式的,侵入式需要开发配合做代码修改。


在只有维护没有开发的情况下,会出现一些老旧的业务,这会导致无法接入,特别是侵入式,开发团队比较忙或是不愿意接入你的链路跟踪,那么,整个跟踪的实际效果会大打折扣。


上图左边是一个常规的PHP代码,这是Curl函数的实现,右边是真实的Curl扩展的源代码,这个扩展最终是一个C函数,我们想要实现的链路跟踪是访问函数的时候,能够知道代码的顺序、函数的输入/输出以及像调用时间。


基于以上PHP函数的实现以及扩展性基于C语言的实现,我们可以实现到什么?

我们依然调用了PHP的Curl的函数,这个函数本身对它进行替换,依然访问C函数,但函数本身对它做了一个替换,请求该函数的时候,是指请求我自己的函数,自己的函数本身会调用原始函数,对原始函数进行返回,经过简单的封装后,我们能拿到Curl任何一个函数的参数;关于函数的返回值,我们要知道,访问一串代码函数,在一串链路中,可以获取到参数和返回值,在中间插入最终ID。因为参数有请求时间、返回时间,所以基于这样一个更改实现,就可以知道扩展函数调用参数、调用返回值、调动时间,我们可以对这个参数返回时间进行更改,并植入另一个ID。对于这些函数做的更改,在PHP代码中再调用函数时,就可以像一条链路一样从上到下,把整个链路接入。


关于单台Server,如果跨机器识别,传输链路ID如何传输?



如上图所示,基于PHP实现大部分都是Web开发的,在HTTP中追踪一个ID,可以实现多台机器之间。假设同样是一个Login请求,一个请求的传递,基于以上的实现,我们就可以实现到类似于第一块,最开始Curl是一个扩展,我们开启了新扩展,任何一个PHP语言只需要打开一个新的扩展包,并植入到PHP中就可以实现链路跟踪了。


实现本身是接入到一个开源软件,我们实现的过程中做了一些更改,更多的是函数支持,那这是什么意思?最开始讲到实现原理的核心是做一个函数替换。我们会在测试过程中发现,如果没有函数,我们可以增加更多自己的函数,类似于Curl Post参数抓取,增加了这个功能。我们基于链路跟踪获取到数据码,再进行V2格式进行输出,最后修复bug。


接下来我们看一下真实的基于链路跟踪输出的详细数据。



上图所示,左边是一个常规的PHP代码,右边是链路输出的数据,我们详细分析一下PHP代码,这一串链路追踪最终核心截取了一个函数细节,函数的耗时时间、函数的参数,我们基于最开始的函数替换原理实现到的是,任何一个PHP函数,它在运行时可以将输入参数、返回值和调用时间,获取到这一串代码整个执行的链路。


当然,因为做了数据替换,所以会出现性能损耗,我们需要通过采样率规避这个问题,根据实际业务做到一个测试数据。关于以上内容都是作为单机处理的,那么,如何实现扩展到几百台或几千台规模机器?



首先,对PHP做一个扩展,再做函数替换,实现基于Zipkin-V2数据写入到文件,数据平台有一个数据日志,将日志写到平台中。用到Vipkin-V2协议将隔离转化格式后,再做数据转换,如果只是用来查询,它是非常简单的Web页面,HTML的页面进行重写插入到平台里面。在实现过程中,有几个细节需要注意,第一块Logstash配置,需要做一个重命名操作,第二块ElasticSearch搜索,一般不进行索引,我们可以进行字符串查询,查询到指定的API或指定的数据类型链路跟踪。


当加了链路跟踪后,最终解决什么业务问题?


第一块是性能统计,我们通过函数替换可以知道输入、输出的时间,和MySQL、API接口访问时间。虽然数据可以在第三方系统查到,但也可以在MySQL集群或是自己的系统、API性能分析中查到,如果能查到链路跟踪,这是非常贴合业务的。



第二块是应用拓扑,如上图所示,我们可以非常清晰的看到,在通过链路跟踪的时候,我们可以知道语言目的地,并把拓扑画出来,如果仅仅只是基于链路跟踪画拓扑图,是不适合现实情况的。


一个8001Web端口,MySQL有50提机器,仅仅基于链路跟踪画出来的数据图,50个Web介点连接MySQL,在运维层面属于集群的概念,但只是链路跟踪的话,画出来的拓扑图可能不适合运维层面。MySQL比较简单,基于链路跟踪的数据看到的ID只是VIP,架构图对于运维制造,是想了解真实访问到哪个集群了,基于这样的实现,我们之前详细介绍到CMDB,VIP数据和MySQL是有关联的。关于这两个数据的结合,可以非常轻松的知道运维的构架图。



上图是一个简化过的两地三中心的架构,这不是单机Web,只是一个Web集群。MySQL依然是最开始业务所支持的中间件MySQL集群,基于链路架构图画出来,包括应用跟踪可以实现到的错误故障或耗时,可以实际的展示到图表上,这种应用拓扑其实是真实的反映了现有业务运维架构。



第三块是链路回放,上图是Login页面,一个用户登录需要完成什么?所有的程序调用会像链路一样展现出来,例如,调用第三方API、传入、传出、消耗时间、连接中间件、插入的数据、反馈的数据等。主要核心是做故障定位,例如,基于应用层面,某一个业务登录发生非常严重的下降,我们在链路跟踪中打开登录页面,就能详细的知道,API无法提供服务,导致业务故障。整体上关于链路,整个质量保证处于中间那一块,核心是从上到下访问链路,来解决质量的相关问题。


以上内容来自童传江老师的分享。

媒体联系

票务咨询:赵丹丹 15802217295

赞助咨询:郭艳慧 13043218801

媒体支持:景    怡 13920859305