华为云DevOps系列之 —— 持续运维与监控（四）应用性能管理

为什么需要应用性能监控

业务爆发式增长

• 在云时代，分布式微服务架构下应用日益丰富，用户数量爆发式增长，纷杂的应用异常问题接踵而来
• 传统运维模式下，多套运维系统上的各项指标无法关联分析，运维人员需要根据运维经验逐一排查应用异常，分析定位问题效率低，维护成本高且稳定性差
• 海量业务下应用运维面临以下两个方面的挑战
  • 大型分布式应用关系错综复杂，分析定位应用问题困难，应用运维面临如何 保障应用正常、快速完成问题定位、迅速找到性能瓶颈 的挑战
  • 应用体验差导致用户流失，运维人员不能实时感知并追踪体验差的业务，未能及时诊断应用异常，严重影响用户体验

微服务化趋势明显

• 微服务对业务进行拆分，微服务数量增多，研发运维管理对象过成倍数增长、对业务应用的性能和容量带来新挑战
  • 管理对象增加
  • 版本多、变更更为频繁
  • 服务调用复杂性增加、故障概率增加、问题定界定位困难

什么是 APM

• APM（Application Performance Management），是对应用程序的性能和可用性的监控管理
• APM主要是针对企业关键业务的 IT 应用性能 和 用户体验 的监测、优化，提高企业 IT 应用的可靠性和质量。旨在确保最终用户获得高质量的体验，降低 IT 总拥有成本 TCO （Total Cost of Ownership ），包括产品采购到后期使用、维护的成本。这是一种公司经常采用的技术评价标准
• 常见的应用性能监控管理包括 应用的接口性能和错误监控，分布式调用链路跟踪，以及其他各类用于诊断(内存，线程等)的监控信息，随着云管端的不断延展，已经延伸到了前端，手机 App 端，IOT 等领域监控，并且与容器监控、服务器监控，以及其他平台组件如中间件、数据库等层面的监控一起协同起来，将整个应用给看护起来

分布式链路跟踪

• 目前市面的系统基本都是参考 Google 的 Dapper 来做的
• 跟踪业务请求的处理过程：完成对应用系统在前后端处理、服务端调用的性能消耗跟踪，通过汇聚业务系统各处理环节的实时数据，实现对应用的全链路性能监测

分布式调用跟踪原理

• 在分布式系统中，一次请求会包含很多的 RPC 调用，迫切需要一些可以帮助理解系统行为和分析性能问题的工具，需要诊断具体哪个服务性能容量存在问题，从而对整个系统造成瓶颈
• 例如，下图展示的是一个5台服务器相关的服务，包括前端（A服务），两个中间层（B和C服务），两个后端（D和E服务）。当一个用户（这个用例的发起人）发起一个请求时，首先到达前端，然后发送两个 RPC 到服务器B和C。B会马上做出反应，但是C需要和后端的D和E交互之后再返还给A，由A来响应最初的请求。对于这样一个请求，简单实用的分布式跟踪的实现，就是为服务器上每一次你发送和接收动作来收集跟踪 标识符(message identifiers) 和 时间戳(timestamped events)
  

Google 基于标注的方案（annotation-based）：

• 分布式系统要做的就是记录每次发送和接受动作的跟踪标识符（message identifiers）和时间戳（timestamped events），将一次请求涉及到的所有服务串联起来，只有这样才能弄清楚一次请求的完整调用链

主流 APM 产品的对比

• Zipkin 由 Twitter 开源，调用链分析工具，基于 spring-cloud-sleuth 得到广泛使用，非常 轻量，使用部署简单
• Pinpoint 专注于 链路和性能监控，韩国研发团队开源，埋点无侵入，UI 功能较强，但毕竟是小团队，不知道会不会一直维护着，目前版本仍在更新中
• Skywalking 专注于 链路和性能监控，国产开源，埋点无侵入，UI 功能较强。能够加入 Apache 孵化器，设计思想及代码得到一定认可，后期应该也会有更多的发展空间及研发人员投入。目前使用厂商最多。版本更新较快
• CAT 是一个更综合性的平台,提供的监控功能最 全面，但研发进度及版本更新相对较慢

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊