QCon 北京：业务监控与 APM 技术实践

2016 年 QCon 全球软件开发大会北京站于 4.21-4.23 在北京国际会议中心举办，参会者对整体内容设置及安排反馈良好。这里我们梳理出了 23 号“运维与监控”厂商共建专场的重点演讲内容，为没能到现场聆听的小伙伴们奉上饱满的干货内容。（点击进入 QCon 北京 2016 大会官网，免费下载三天演讲 PPT）

参加技术分享的厂商有：好雨云、听云和汽车之家。演讲话题点包含实时分析、业务监控、移动端 APM、微服务架构等关键技术点，通过业务监控把问题在扩大之前解决，在移动 App 上实现端到端的性能管理，以及汽车之家微服务架构的演进和设计思路等内容。具体细节往下看！

实时分析 & 业务监控

来自好雨云公司的系统架构师 祁世垚在过去几年和团队通过实时分析解决了很多生产环境中的问题，在这里会分享宝贵的经验、心得。

首先，做业务监控的目的是为了能看到系统的性能值，了解服务是否是在真正高效的运行，以及是否真的需要去做资源扩充等等。那为什么要做实时分析呢？祁世垚以系统级监控为例，一个常规系统级监控参考价值已经不够了，无法真正的体现系统在 CPU 利用率高、磁盘读写量大、网络流量大的情况下，系统的消耗量和利用率。而基础的业务监控工作存在变数比较多，人工维护成本大，可能会掩盖一些真正的问题，导致团队对一些系统中出现的问题总是后知后觉。

那么如何解决这样的问题呢？开发优化代码、Dba 优化数据库、优化其它后端服务、扩充资源等等。如何去优化数据库等后端服务？这可能需要对数据库服务层做一些优化，用第三方优化过的版本根据自己的业务去调整一些数据库的参数，或者说提升数据库的硬件性能，再做逻辑上的一些拆分，比如说垂直分割、水平分区。但是与此同时，也要想想数据库是不是真的需要承受这么大的请求量，要对 SQL 请求做一些判断分析。

在对后端服务进行优化的时候，需要衔接运维和开发之间的沟通，运维需要了解承接如此多的请求是否必要，开发需要知道使用服务的方式有没有问题。

另外，开发和运维双方之间都需要在以下“可能会影响性能的地方”互相同步信息：

• 平时访问量不多的慢 URL
• 访问量不该如此大的 URL
• 该缓存到 cache 的数据库查询
• 该分离到从库的 SQL
• 未命中的 cache
• 未压缩的静态资源

运用实时分析能发现什么问题？当然，能发现例如在故障时间点快速确认问题来源、发现不合理的请求、找出可能成为隐患的问题点、对接报警系统，丰富监控项等等问题。那么如何实现对这些问题的处理，也是祁老师讲解的重点内容。

通过一套复杂事件处理的概念来处理大量事件流，匹配复杂的模式来分析出结果。用一个开源的用 Java 写的 Esper 基于内存来计算出结果，性能非常高，能达到每秒钟处理 100 万个事件数量。（如下图）

事件处理的流程图很简单，通过 Weblog 将前端过来的用户请求日志抽取过来，数据库 SQL 查询的请求也给取过来。比如说 Memcache 等等，在程序这边来生成的一些事件。中间通过一个传输层交给 Esper 统计分析，根据写好的规则统计结果，结果可以通过用 Websocket 推到前端来看，也可以到终端上用命令行来看，这对运维比较好，还可以对一些结果做报警，或者把这些结果记录下来，供回溯查看。

事件是如何抽取的？Lblog 是实时监控 web 的日志做格式匹配，抽象成一个事件。数据库相关的工具如 Mysqlsniff，mongosniff，以及对 key 的使用情况也会做一些日志。通过相关操作对日志的格式做一些匹配，抽象成一个事件。抽象成一个什么样的事件？比如说 URL，事件的主题可能是 URL 也可能是 SQL，也可能是请求的 key，一般 URL 和 SQL 会包含两个元素，比如消耗时间和返回的大小，或者具体的动作。

除了以上内容，祁老师还讲了关于事件属性映射、事件流的拆分、运算分析语句等方面的内容，感兴趣的可以进入 QCon 官网下载讲义或者观看后期推出的演讲实录视频。

端到端 & APM

来自国内较为知名的 APM 服务供应商听云的研发总监 杨金全老师讲了听云在 App 端、Server 端和 Web 端是如何实现性能管理的。APM 是 Application Performance Management 的缩写，意思是对软件应用的性能和可用性进行监控和管理，致力于发现和定位性能瓶颈和故障，以保证应用达到预期的服务水平（SLA）。

实现 App 端性能管理。App 性能衡量指标包括：崩溃率、ANR（应用无响应）、交互性能、HTTP 性能。而为了实现这些衡量指标，可以通过不同的技术，例如 iOS 开发可以通过 hook 技术来实现；对于安卓开发来说，可以通过 Dalvik/Class rewriting 方式来实现。

除了崩溃率、ANR 等这些情况，该如何解决呢？还有另外两种会影响应用的严重情况，一个是终端，一个是无响应。终端的意思是比如 APP 上的崩溃、ANR，或者浏览器上服务器不可用。还有一些交互慢的问题，也是影响用户体验的杀手之一。交互性能慢有两种情况，一个是慢动作，一个是慢交互。

慢动作是指从服务器端请求资源，请求数据，来渲染页面这一系列业务逻辑产生的响应速度慢。慢交互是指网络请求较多的时候出现了大范围的拥堵，访问一个 URL 的时间消耗了 4 秒，所传输的字节数以及调用了哪些堆栈，整个业务逻辑是什么样的，都可以通过一个慢交互的图看出来，也能够清楚的看到慢交互是因为什么网络服务问题而导致的。

Server 端性能管理。Server 端性能衡量指标包括：应用响应时间、业务性能，吞吐率，成功率、服务性能（SQL，NoSQL，API，外部服务）、代码效率、代码质量等等。这些 Server 端性能指标如果出现错误，那就有可能有十个用户受到了影响。另外，如果这个应用不支持调用像 AWS 服务或七牛云存储的服务，也有可能出现这些问题。

接下来就会涉及到通过什么样的技术来获取这些数据的问题，我们可以用哪些技术？通过一些 Agent 自动嵌码技术。对于 Java 技术，可以通过 Bytecode/Instrumentation/Classloader 等技术来获取；对于 PHP，可以使用 Opcode/Zend/Extensions/Xhprof 等技术；对于.net、Python、Ruby 可以进行方法级别功能的抓取。

上面已经讲了 APP、Server 端如何获取应用性能的问题，这些性能问题都是孤立的，如何在单一应用场景下实现端到端的应用性能的管理。如何实现端到端呢？这里就需要提到应用拓扑（如上图），应用拓扑是在整个架构里提供服务的，非常清晰的反应出服务架构、逻辑架构的内部情况。

除此之外，杨金全老师还分享了如何去追踪问题，怎么样去定位问题，怎么样去划清责任的界限等等相关内容。

Turbo & 微服务架构

微服务架构一直很热门，很多传统的网站开始从传统的架构迁移到微架构上，一方面是为了服务于服务之间能够更灵活便捷的互通，另一方面也便于架构的升级。来自汽车之家的架构师 石智中就给我们分享了汽车之家的微服务架构实践，主要讲两点，一是对微服务架构的了解，另一点是如何实现微架构的落地。

首先，我们需要明白，微服务架构能给我们带来什么，石智中从这几个方面做了说明：

• 分解：通过分解巨大单体式应用，为多个服务方法解决复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用 RPC- 或者消息驱动 API 定义清楚的边界。服务边界、模块化、服务化由此，单个服务很容易开发、理解和维护。
• 自由：每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供 API 服务。这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。
• 效率：自带敏捷光环，拆分足够细，对于团队协作来说是有很大的提高的，并行开发，最后再串联起来。
• 迭代：独立部署、迭代成本低。
• 弹性：微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。

而汽车之家为什么要实现微服务架构？原因就在于，在服务化之前整个网站上的论坛、咨询、产品库、口碑、软件、二手车、电商等产品之间关联性比较小，还有一部分是用 C#代码写的，部分设计、构架老旧等问题。那么微服务架构在汽车之家是怎么落地实现的呢？首先是选用了 Turbo。这是一套多语言适配的微服务化解决方案，提供服务发现、多协议 RPC、负载均衡、分布式跟踪、统一监控报警、自动化部署等功能。

这是一个简示图，从这个图上能看出汽车之家迫切想解决的问题，内部 Java 和 C#是并存的，所以根据这一点设计了一套通用的 Turbo 来实现架构，让两者实现客户端和控制端。通过后台可以管理和看到所有的节点，包括所有调用者和提供者，控制他们的上下线，看他们调用的指标，调用者同时会异步的传日志，通过 Spark 分析生成报表和指标性的数据。针对 Java 这方面要做基于 Docker 的自动化部署。

关于服务治理的分层架构的设计，主要还是为了应对多语言适配的问题，兼容多语言。首先最上层是配置层，XML 格式，再接下来是注册中心，这一块是用的 ZooKeeper，稳定性较好。集群这一层是比较主要的，会做集成发现、负载均衡、路由、固定感知的逻辑。再往下是 IPC，调用的时候用的是开源的 dubbo 协议。之后是传输层，支持 HTTP、NETTLY，整个是单向依赖的。

随后，石智中老师还讲述了在实现微架构过程中 Turbo 的稳定性和容错特性，包括：1、多机房部署 zookeeper 集群，主力机房 5 个节点 (leader/follower 集群)，其他机房各 2 个节点 (observer 节点)，保证性能和稳定性。2、Turbo 客户端服务端添加守护线程，定时校验本地缓存和 zookeeper 的数据一致性。3、Turbo 客户端会将缓存的服务信息持久话到本地，即使 zookeeper 挂掉或者重启也不影响正常调用。4、注册中心 zookeeper 的数据全部持久化到 DB 中。5、嵌入 Trace 客户端上报收集分布式跟踪日志。

写在最后

实时分析对服务运行的状态进行实时跟踪分析，可以帮助研发人员和运维人员时刻了解业务后台的状况，及时发现问题找出解决方案，将系统的使用效率最大化。而不管是 App 端、Web 端还是 Server 端的性能管理，其目的都是对基础设施性能最好的改良措施。在当前，广泛被采用的微服务架构必然会对开发、测试与运维带来挑战，而通过大数据技术更好的支持服务治理也是很好的途径。