共计 5784 个字符，预计需要花费 15 分钟才能阅读完成。
本文内容节选自由 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 无法提供服务，导致业务故障。整体上关于链路，整个质量保证处于中间那一块，核心是从上到下访问链路，来解决质量的相关问题。
以上内容来自童传江老师的分享。
声明：本文是由壹佰案例原创，转载请联系 meixu.feng@msup.com.cn
