阿里云云原生微服务可观测实践

作者：十眠、水彧

可观测介绍

彼得·德鲁克曾经说过：“如果你无法量化它，你就无法管理它。” 可观测性（Observability）是帮助微服务稳健运行的重要一环。“我们的系统是否还是正常的？”，“终端用户的体验是否符合预期？”，“我们如何在系统快要出问题之前主动发现系统的风险？”。如果说监控可以告诉我们系统出问题了，那么可观测就可以告诉我们系统哪里出问题了，什么原因导致的问题。可观测不但可以判断系统是否正常，还可以在系统出现问题之前，主动发现系统风险。

从系统的角度来讲，监控以 Ops 为主，聚焦在发现，确保系统稳定性。可观测性的目标是白盒化，注重 Recall+Precision，贯穿 Dev/Tester/Ops 等环节，通过多种观测手段，确保找到根因，防患于未然。

云原生下微服务应用可观测的挑战

目前，常见的微服务框架包括 Spring Cloud 和 Dubbo 等多语言微服务，并具备服务注册发现、服务配置、负载均衡、API 网关、分布式微服务等基本能力。其中，服务治理包括无损下线，服务容错，服务路由等能力。可观测性包括应用监控，链路追踪，日志管理，应用诊断等。

随着云原生到来，微服务架构得到越来越多的应用。由最初以机器为核心的云服务器 ECS 上云，到以容器为核心的容器化云原生部署；为了更加敏捷，阿里云开始以应用为核心的微服务化。如今，当微服务发展到一定应用规模，阿里云开始围绕业务核心，以提效稳定为目的的服务治理。

在云原生下的微服务可观测主要面临三个挑战：
• 发现难
从云服务器 ECS 到 Kubernetes，微服务架构复杂度提升，观测对象复杂度提升，监测数据覆盖不全。

• 定位难
随着多种治理能力深入，可观测要求高，服务框架复杂度增加，技术门槛提升，数据本身复杂度提升，数据关联性差。

• 协作差
随着组织角色变化，可观测不只是运维工作。

应用实时监控服务 ARMS 作为阿里云可观测产品，支持自动检测部分产品问题。目前已经覆盖五十多个故障场景，包括应用变更、大请求、QPS 突增等，诊断报告认可率高达 80%。

如下图所示，线上 7%的应用都在 Dubbo 的 RPC 上耗时，并由于埋点问题，无法定位出根因。

阿里云在为客户服务过程中，发现了很多问题。

• 服务发现
当前一些监测工具无法实现服务框架服务发现层面的问题诊断，导致遗留了许多服务调用问题难以排查，单看监控使得客户根本无从下手。因此，我们希望通过提供以下方面服务发现监控诊断能力，帮助客户及时排查服务发现领域出现问题导致的应用运行异常。

（1）监控客户端出现 no provider 问题；
（2）微服务应用连接的是哪个注册中心，服务发现链路调用示例图，大块内容有 Provider、Consumer、注册中心，点击对应组件可以看到详细相关地址；
（3）应用服务是否注册成功；
（4）应用最近一次拉下来的地址数量 & 内容；
（5）应用与注册中心的心跳是否健康；
（6）注册中心状态信息，如 CPU、内存等运行硬件状态信息，注册服务数目、订阅服务数以及服务内容等信息。

• 微服务生命周期
微服务启动慢，一个服务器花 3 分钟，5 个服务器花 30 分钟。我们希望应用启动过程中，从 Spring bean 加载、链接池连接的监测、微服务的服务注册、Kubernetes 的监测检查就绪；应用下线过程中，服务注册、在途请求的停止、定时任务/MQ 等取消、服务停机；例如：Spring bean 初始化异常，卡在哪个 bean 的加载上，哪个 bean 初始化耗时特别长。帮助用户分析启动慢的原因，自动给出修复建议。然而，目前整体过程是缺少相关观测能力。

• 调用链路
Consumer 调用超时、Provider 却快速返回。

除此之外，还有微服务配置混乱，不好梳理；微服务应用上 Kubernetes 之后，出现线程池满，却找不到原因等一系列问题。

那么，当站在微服务视角思考如何进行体系建设时，我们提出的微服务可观测性增强解决方案。站在传统监测方案之上还能再做哪些事情？

微服务场景下可观测的探索与实践

微服务可观测增强解决了什么问题

一句话概括就是：全面增强微服务场景下的可观测能力。

让一线运维人员具备微服务诊断基本能力，可以排查 80% 的微服务常见问题，快速进行性能分析诊断。

ARMS 微服务可观测增强方案回答了以下问题：

• 为什么服务启动很慢
从 Pod 创建到应用初始化再到服务注册应用启动，端到端分析出应用启动慢的根因，补齐应用启动生命周期的可观测能力；

• 依赖是否存在隐患
为 SpringCloud/Dubbo 依赖的 Jar 包进行分析，定位是否存在 Jar 包依赖冲突等问题；

• 配置分析
微服务场景下配置分散且冗余，提供应用运行时配置可观测能力以及配置优化的专家经验；

• Dubbo 调用链增强
覆盖寻址，序列化，网络等阶段的埋点，一眼看出 Dubbo 调用的时间都去哪儿了。

为什么服务启动慢？通过从 Pod 创建到应用初始化再到服务注册应用启动，端到端分析出应用启动慢的根因，补齐应用启动生命周期的可观测能力。

通过将整个流程串联，实时观察到每个点的耗时，可观测视图把问题剖析出来。上图是 ARMS 容器启动分析功能。左边是服务启动，系统将启动过程中的每一块时间拆分出来，从而清晰看到微服务启动慢在了哪一步，增强了其可观测性。

微服务引擎提供了无损上线的能力。控制台动态配置，实时无损上下线可观测视图，完整解决方案无需改一行代码。在微服务启动的全流程进行各种方案的保护与治理：预建连接阶段通过提前异步创建连接保证不会阻塞在连接建立的过程中；服务注册发现阶段通过并行注册与订阅能力进一步提升应用的启动速度；在小流量预热阶段通过调整客户端的负载均衡能力保证新起的实例中流量缓慢增长。

由于微服务配置的覆盖关系较为复杂，需要进行配置分析。

上图为 Dubbo 官方提供的配置覆盖关系，可以看到其具有一定顺序先后性。很多时候很难判断配置是否配错地方，是否生效，是否被覆盖。微服务场景下配置分散且冗余，我们提供应用运行时配置可观测能力以及配置优化的专家经验。

我们提供了为 SpringCloud/Dubbo 依赖的 Jar 包进行分析的能力，帮助定位是否存在 Jar 包依赖冲突、依赖的 Jar 是否存在安全、性能风险等问题。

一次 RPC 调用时间到底去哪儿了？一次 RPC 调用有路由、限流降级、序列化、网络等各个环节。从客户端来讲，需要经过路由、filter、invoker、serialize、remote。从服务端来讲，需要经过 serialize、Proxy Invoke、filter、impleme。

上图是一次 RPC 调用流程图。其中包括寻址、负载均衡的建立连接时间，打包的序列化时间，解包的返印值反序列化时间，服务端处理时间和等待服务端处理返回的时间。

如上则是我们给出的答案，将调用链在 RPC 框架内进一步细分，一眼看出路由、序列化、网络、代理、服务端处理等耗时的细节。

总结

微服务可观测增强方案站在传统的可观测性方案之上我们进一步从微服务的视角出发，扩展传统可观测覆盖的 Tracing、Logging、Metrics 等数据，结合微服务专家的诊断经验。

从前端、应用至底层机器，应用实时监控服务 ARMS 实时监测应用服务的每次运行、每个慢 SQL、每个异常。与此同时，提供完整数据大盘监控，展示请求量、响应时间、 FullGC 次数、慢 SQL 和异常次数、应用间调用次数与耗时等重要的关键指标，时刻了解应用程序的运行状况，确保向用户提供最优使用体验。

阿里云微服务引擎 MSE 全新升级，在治理中心 MSE 提升了微服务开发效率和稳定性。支持近 5 年 Spring Cloud 和 Dubbo 应用，及多语言异构微服务体系。提供无损上下线、全链路灰度、离群实例摘除、服务鉴权、等差异化能力。在注册配置中心，MSE 拥有全托管 Zookeeper/Nacos/Eureka 服务。默认高可用：多可用区部署、自动探活。配置鉴权，加密和灰度发布。在云原生网关方面，MSE 集成监控告警、链路追踪、限流降级、证书管理。流量网关于微服务网关二合一，成本下降 50%。