在实际运维过程中，因为业务系统越来越复杂，变更越来越频繁，总是存在各种各样监控未覆盖或者以前未知的故障发生。如何构建一套全链路的故障追踪和故障自愈系统，成了质量保证部门的刚需，通过行业标准化的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无法提供服务，导致业务故障。整体上关于链路，整个质量保证处于中间那一块，核心是从上到下访问链路，来解决质量的相关问题。

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