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

本文内容节选自由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无法提供服务，导致业务故障。整体上关于链路，整个质量保证处于中间那一块，核心是从上到下访问链路，来解决质量的相关问题。

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

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

TOP100summit分享实录 | 如何构建一套全链路的故障追踪和故障自愈系统？ 1
本文内容节选自由msup主办的第七届TOP100summit,三七互娱运维开发负责人童传江分享的<三七互娱故障追踪和故障自愈系统>实录. 分享者童传江在维行业7年工作经验,做过网络管理,做 ...
如何基于RocketMQ设计一套全链路消息不丢失方案？
我们使用MQ作为消息中间件,传输一些消息的时候,必须考虑到消息丢失的可能.因为有的时候消息丢失了,会产生很严重的后果,比如消息计费数据,跟钱有关的消息. 这篇文章我们以RocketMQ为例来讲解,如何 ...
蚂蚁数字科技与梆梆安全达成战略合作共同构建移动端全链路的安全能力
近日,蚂蚁数字科技与北京梆梆安全科技有限公司(以下简称"梆梆安全")签署战略合作.双方将在移动应用安全领域进行技术研究与创新,共同构建移动端全链路的安全能力,为用户提供高质量的数字 ...
【白皮书分享】2020年短视频全链路营销白皮书.pdf（附下载链接）
大家好,我是文文(微信:sscbg2020),今天给大家分享央视市场研究股份有限公司移动用户指数事业部于2020年10月份发布的白皮书<2020年短视频全链路营销白皮书.pdf>,希望对您 ...
TOP100summit分享实录 | 数字化三支柱：企业数字化转型的众妙之门
喜茶凭借「喜茶GO」小程序跻身第七届全球软件案例研究峰会(简称:TOP100summit),为100个技术案例中唯一的非科技企业和唯一的零售餐饮企业. 本文为喜茶CTO陈霈霖在TOP100summit ...
TOP100summit分享实录 | 有赞程功夫：打造最具竞争力的SaaS解决方案
本文内容节选自由msup主办的第七届全球软件案例研究峰会,现任有赞产品总监程功夫,分享的<有赞在SaaS领域的产品设计观>实录. 本文为有赞产品总监程功夫在TOP100summit上的演讲 ...
TOP100summit分享实录 | 「来也」胡一川：吾来对话机器人解决方案
本文内容节选自由msup主办的第七届TOP100summit,「来也」联合创始人兼CTO胡一川分享的<吾来对话机器人解决方案>实录. 分享者胡一川,「来也」联合创始人兼CTO,本科和硕士毕 ...
TOP100summit分享实录 | JFrog高欣：Kubernetes is hard!JFrog的Kubernetes实践 1
本文内容节选自由msup主办的第七届TOP100summit,JFrog架构师高欣分享的<Kubernetes is hard!JFrog的Kubernetes实践>实录. 本文为JFro ...
TOP100summit分享实录 | 服务快消品牌的数字营销解决方案
本文内容节选自由msup主办的第七届TOP100summit,个推大数据产品咨询总监沈都分享的<服务快消品牌的数字营销解决方案>实录. 分享者沈都具备丰富的互联网研发和营销策划经验,善于通 ...

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

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

最新文章

热门文章