关于运维:如何保障业务稳定性一文详解蚂蚁业务智能可观测平台BOS

随着业务规模的不断扩大以及 AI、云计算、大数据等技术的一直倒退，大量的企业心愿利用上云来减速其数字化转型，全面晋升可靠性、安全性和灵活性，并且升高经营老本。

不过对于大多数企业来说，全面上云是一项颇具难度的挑战。这外面起因有很多，无论是简单遗留零碎的迁徙难度大，还是数据安全性的思考等，都导致大多数企业面临着一部分利用处在云上，另一部分利用处在云下的简单场景，这给业务稳定性带来了新的挑战。

本文将从可观测性视角登程，剖析云上云下业务稳定性的难点，介绍蚂蚁团体的 BOS 平台是如何建设欠缺的解决方案来解决这些理论的痛点难点，并通过多个实际案例分享企业与机构如何利用 BOS 平台来实现云上云下全链路可观测性的需要。

一、可观测性的挑战

云上云下业务稳定性的难点包含以下几个方面：

• 分布式架构的复杂性：云上的利用通常以分布式架构为根底的，因而利用波及的不同的组件和服务可能运行在不同的服务器上，这会使得问题的定位和调试更加艰难。
• 利用实例的动态性：云上的利用能够利用云原生的能力进行灵便的迭代、公布与扩缩容的操作，因而须要实时的发现利用的变动并加以监控。
• 利用的多样性：迁徙上云的利用通常应用的技术栈和框架比拟对立，而后云下的利用通常应用着多种不同的技术栈和框架，这些多样化的利用对可观测性的接入是个比拟大的挑战。
• 基础设施的异构性：云上云下的基础设施通常也有很大的差异性，比方 CPU 架构可能横跨 X86、ARM 以及 Power 架构等，操作系统也可能横跨 Linux、Windows 以及 IBM AIX 零碎等。这些异构的基础设施也大大增加了可观测性接入的复杂性。
• 数据的交融性：很多企业在业务倒退的过程中，曾经洽购或自研了不少的可观测性组件，但这些组件产生的可观测数据格式各不相同，在迁徙上云当前，和云上的可观测性体系又会存在各种不兼容的状况，因而如何保障云上云下可观测数据的一致性，实现真正对立的全链路剖析能力，也是一个很事实的难点。

二、BOS 的实际

业务智能可观测服务 BOS（Business-Intelligent Observability Service）是基于蚂蚁大规模技术危险防控实际自研的一套运维平台，具备业务数字化运维、全息可观测定位、智能场景化防控、一体化数据分析和大规模实际等产品个性，将业务场景可视化和数据业务语义化，赋能云上 / 云下的异构利用开箱即用的智能可观测能力，为业务提供全方位的稳定性保障，建设业务观测新范式，让稳固更有力量。

针对云上云下全链路可观测性的场景，BOS 在对立元数据、异构利用接入、数据采集、数据标准化和兼容性等方面深刻耕耘，建设起了欠缺的解决方案，并且在和泛滥客户的理论案例中积攒了丰盛的落地教训。

以下将简略介绍下几大外围的能力：
1、对立元数据
元数据是治理各个监控实体以及实体之间关联关系的外围数据，BOS 基于蚂蚁的实践经验，总结了一套丰盛残缺的元数据模型体系，兼顾云上的云原生利用以及云下的传统经典利用，实现对立的元数据体系。

通过对所有监控实体进行对立的元数据管理当前，能够带来以下的价值：

• 进步数据品质和准确性：对立元数据管理能够确保可观测数据的精确性、一致性和完整性，从而进步数据品质和准确性。
• 进步数据可用性和可拜访性：对立元数据能够提供一个对立的数据字典，使得用户能够更容易地找到和拜访所需的数据，进步数据的可用性和可拜访性。
• 进步数据共享和互操作性：对立元数据能够确保数据的一致性和互操作性，升高数据共享和数据集成的难度和老本，促成数据资源的共享和利用。

除了模型的对立之外，BOS 的元数据的同步性能也对各种场景提供了不同的同步形式，比方：

• 对于云原生 Kubernetes 场景，能够对接 Kube-apiserver 来同步元数据。
• 对于已有 CMDB 的场景，能够对接 CMDB 来同步元数据。
• 对于其余场景，BOS 提供了 SPI 的形式来主动同步元数据。
• 此外，BOS 还提供手动录入元数据的能力，实用于极少发生变化的传统经典利用的接入。

因而对于云上云下的各种利用，BOS 可能提供对立的元数据，实时的发现利用的启停、缩扩容、漂移等各种变动，为全链路可观测性奠定了松软的根底。

2、利用接入
针对多样化的利用以及异构的基础设施，BOS 一直地扩大兼容各种基础设施的，并且实用于不同技术栈和框架的利用接入形式。目前曾经宽泛笼罩了 Java（业内当先的 Java 版本覆盖度，可能反对低至 1.6 和 1.7 的版本）、C/C++（业内当先的 ANSI C 语言的反对）、Golang、Python 等各种支流的编程语言，并且反对这些编程语言的各类型支流框架。除此以外，不少客户存在着应用自研框架的状况，对此 BOS 也可能疾速进行对应插件的研发，给全链路的可观测性补上各种缺口。

在扩大利用接入宽度（各种语言反对）和深度（各种框架反对）的同时，BOS 也继续的简化利用接入的复杂度，缩小客户的应用老本。

以后业内的可观测性接入计划次要有两类：

• SDK 集成计划：该计划通过业务利用接入相应的 SDK，并且进行一定量的代码配置，实现可观测性数据的生成和上报。
• Agent 计划：该计划利用一些编程语言的特点，实现无需任何业务代码变更，只须要批改启动命令，即可实现可观测性数据的生成和上报。

以上这两类计划都或多或少的须要客户批改代码或者启动命令，这给客户带来了肯定的接入老本。

BOS 针对这个痛点，深刻开掘操作系统和云原生相干技术，提供了一套残缺的兼顾云上和云下各场景的 OneAgent 计划，无需业务利用进行任何的批改，即可实现可观测性数据的生成和上报，大幅升高利用接入的老本，不便客户疾速进行大规模的利用接入。

3、数据采集
在利用实现接入当前，各类可观测性数据就源源不断的生成并且上报到 BOS，供各种数据分析、根因定位、AIOps 以及高可用体系应用。

为了更加全面的、从不同维度对利用进行观测，BOS 也在继续扩大可观测能力的边界，涵盖根底资源监控、集群监控、利用监控、业务监控、分布式链路、业务链路、日志、事件、利用性能监控、网络性能监控、网络设备监控、安全监控等等各种门类的可观测性数据，为客户提供全景式的可观测能力，为业务的安稳运行提供保障。

4、数据标准化和兼容性
BOS 领有一套标准化的可观测性数据格式，兼容业内的支流规范，比方 Prometheus 和 OpenTelemetry，因而通过 BOS 提供的采集组件收集上来的可观测性数据人造就是规范格局的。

然而正如之前剖析的那样，很多企业在业务上云的过程中，存在着或多或少的可观测性数据格式不统一的问题，这点在分布式链路方面尤其凸显。

分布式链路依据接入形式的不同，存在着各自的数据上报形式以及报文格式，更为要害的是他们反对链路上下文的规范也不尽相同，比方：

• OpenTelemetry：反对 W3C 和 B3 协定的链路上下文。
• Skywalking：反对 SW8 协定的链路上下文。
• Zipkin：反对 B3 协定的链路上下文。
• Jaeger：反对 B3 协定的链路上下文，局部编程语言反对 W3C 协定。
• SOFA：反对 SOFA 协定的链路上下文。
• Pinpoint：反对 Pinpoint 协定的链路上下文。

这些链路上下文规范的不同会导致链路的中断，深入分析这个问题会发现存在多种起因：

• 上游利用无奈辨认上游传来的申请报文头中的链路数据，例如 TraceID 和 SpanID，因而上游利用重建出新的链路上下文，导致链路的中断。
• 不同链路规范的字段格局不同，比方字段长度、字符格局范畴等，这会导致很多链路接入 Agent/SDK 的数据校验失败，进而重建出新的链路上下文，导致链路的中断。

因而针对上述因素导致的全链路串联的难题，BOS 提供以下的解决方案：

• 数据标准化：针对数据上报形式和报文格式的不同，BOS 可能反对上述提到的所有支流链路计划的数据接入能力，并且将链路数据转换成合乎 OpenTracing/OpenTelemetry 规范的数据格式，为后续的数据处理和剖析提供对立标准化的数据底盘。
• 数据兼容性：针对链路上下文规范的不同会导致链路的中断的问题，BOS 在大规模的实际中积攒了丰盛的教训，可能提供兼容性优异的 APM Agent，实现与不同链路上下文规范进行兼容适配的能力，将云上云下各种利用进行全链路串联，准确发现整个链路中的性能瓶颈点和异样点。

三、案例剖析

上面将对几个典型的客户案例，具体介绍下 BOS 在云上云下全链路可观测性的实践经验。
1、某头部国有大行
某头部国有大行在从 IBM 大机集中式架构，向云上分布式单元化金融级架构的技术转型过程中，BOS 承载起了对立的可观测性入口：

• 将包含监控、链路与日志等在内的各项观测能力有机地交融在一起，造成数据真正的互相流通关联。
• 通过对立整合扩散在各自管控平台上的云产品 / 云平台以及云基础设施的监控数据，实现了从业务 -> 利用 -> 云资源 -> 云基础设施的下钻监控剖析，一站式的解决运维人员的痛点。
• 最初从业务视角登程，实现行方具体业务场景的梳理，通过数据化的形式主动生成各种业务场景下的链路，使行方业务流程走向可视化，并且通过对链路的强弱依赖、调用依赖等技术危险畛域模型的开掘剖析，使得业务流程具备了业务诊断和剖析能力。

在实现云上零碎的可观测性接入当前，BOS 胜利保障了业务零碎顺利的实现迁徙上云。紧接着，BOS 进一步与行方单干，逐渐将行方云下零碎的可观测性也进行了接入，实现全行级别的云上云下全链路的可观测能力。

整个我的项目有以下几个特点：

• 数据量微小
  作为国内顶级的头部大行，整个业务流量是十分大的，再加上测试环境频繁进行的大流量压测，这对 BOS 的整体性能都提出了很大的挑战。在我的项目施行过程中，BOS 在行方环境中进行了多轮详尽的性能压测，以优异的性能数据撑持起了行方各种压测和生产流量的监控需要。
• 利用规模宏大
  BOS 作为行方云上云下各利用对立的可观测性零碎，接入了不同部门的各种利用，在这种场景下，BOS 通过金融级的元数据模型，满足多种维度的数据隔离需要，解决了数据安全性的问题；此外通过优异的零碎架构设计，提供行方全量的、多维度的利用拓扑图，可能十分直观的发现庞杂利用调用间的各类问题。
• 无侵入革新
  行方针对外部应用的自研框架曾经研发了一套可观测性采集器，为了缩小行方利用接入的难度，BOS 间接对接行方的采集器，无需批改行方已有的部署形式，即可实现行方云上云下利用的全量接入，大幅升高我的项目的施行难度。

在无侵入接入行方宏大规模的利用之后，BOS 以优异的性能和丰盛的产品能力，撑持起了全行级云上云下的全链路可观测能力，为行方业务的稳固倒退保驾护航。

2、某省级农信社

某省级农信社随着业务规模的疾速倒退，零碎数量和规模一直地扩充，零碎拓扑构造与利用调用链路关系也日趋简单，因为不足从全链路视角对交易流量、日志、资源、指标、告警灯信息因素进行聚合展现和剖析的对立渠道，导致生产系统故障疾速定位与交易异样问题剖析较为艰难。

BOS 通过解决重重困难，帮忙行方实现了从多种客户端载体 -> 负载平衡 -> 异构服务端利用的残缺端到端全链路可观测能力。

• 端到端的全链路监控
  BOS 帮忙行方不仅实现了蕴含 Android、IOS、web 利用、小程序等各种载体在内的客户端利用的接入，还把客户端到服务端两头外围的负载平衡设施也进行了接入，最初再加上多语言异构的服务端利用的接入，真正意义上实现了端到端全链路监控剖析能力，并能将每一笔交易流水号与一条残缺链路关联起来，同时通过各类型可观测性数据的加持，实现上卷下钻的问题排查门路，实现交易等各类生产故障的疾速定位。
• 异构利用的反对
  行方的利用技术栈有很多品种，并且运行环境也存在着多套，既有 Objective-C 和 Swift 版本的 IOS 利用，也有运行在 IBM AIX 零碎上的传统 ANSI C 利用。BOS 针对这些异构场景，提供了各类语言和框架的接入反对，其中包含业内当先的 ANSI C 语言的接入计划，帮忙客户实打实的解决了接入难题。
• 传统调用协定的反对
  行方不仅存在异构的利用，此外还存在很多不同的调用协定，针对这些调用，BOS 提供了灵便的链路反对计划，通过简略的配即可实现这些调用的可观测性接入，实现与 HTTP/ 自有 RPC 调用等同的监控能力，顺利完成各种不同协定的链路上下文兼容和串联，将整个端到端链路残缺的串联了起来。

通过残缺的端到端全链路可观测能力的建设，打消了以往的监控盲区，全方位地保障不同业务零碎的可用性与可靠性，帮忙无效地升高了 MTTR（均匀修复工夫），晋升了运维效率，改善了经营体验。

3、某大型城商行
某大型城商行是国内最早一批实现外围零碎从传统的集中式架构向分布式异地多活架构降级的商业银行，基于金融级云原生架构 SOFAStack 建设的云上零碎，人造由 BOS 负责全量的可观测性数据的采集、计算和展现剖析，为云上零碎的稳定性提供松软的根底。

不过行方也存在着不少云下的业务零碎，云下零碎通过云上企业服务总线 ESC 与云上零碎进行通信，云下业务零碎内还存在着传统企业服务总线以及新型的微服务零碎。这些云下零碎和云上零碎的可观测能力是割裂的，无奈将云上云下互相相用的链路进行残缺的串联和展示，因此在故障定位能力和运维效率等方面都存在较大的有余。

因而通过产品和技术计划的调研，行方最终选定将 BOS 的产品能力进行扩容，纳管云下业务零碎，实现云上云下对立的全链路可观测能力。

在我的项目的建设过程中，BOS 针对行方的零碎架构，冲破了一系列的关键技术难点：

• 低版本 Java 利用的无侵入反对
  行方云下零碎是基于异构的语言进行开发的，并且应用的语言版本也并不相同，其中 Java 利用就横跨 1.6、1.7、1.8 等多个版本。如果大家对业内支流链路计划有所理解，就会晓得目前以 OpenTelemetry 和 Skywalking 为代表的链路计划都只能反对 Java 1.8 及以上的版本，因而 1.6 和 1.7 的低版本 Java 利用的无侵入接入是一个普遍存在的难题。

BOS 克服困难，提供了反对 Java 1.6 和 1.7 版本的 APM Agent，反对无侵入的利用接入能力，并且同样兼容支流的链路上下文协定，因而低版本 Java 利用在无需降级 Java 版本的状况下，也可能融入云上云下全链路可观测图谱中。

• 行方自研框架的反对
  行方在业务的长期倒退中，研发和应用了一些自研的框架，并且在云下的几个重要零碎中宽泛应用。为了使这部分自研框架产生的调用也无侵入的纳入可观测性的范畴内，BOS 联结行方研发了针对性的接入插件，打消了这块的监控盲区。
• 云上企业服务总线（ESC）与传统企业服务总线（ESB）的链路串联
  云上企业服务总线（ESC）是负责云上和云下零碎间互相调用的外围零碎，传统企业服务总线（ESB）则是云下零碎间调用的外围零碎，因而这两个零碎是整个云上云下全链路的关键所在。BOS 具体调研了这两个零碎的技术栈以及应用场景，针对不同的特点提供了灵便的可观测性接入形式，将云上和云下的不同链路上下文协定进行了相互之间的兼容性反对，使得任意两个零碎之间的调用都不会呈现链路上下文的中断。

通过冲破这一系列的关键技术难点，BOS 将各种异构的利用、自研框架以及外围网关和服务总线纳入了可观测性体系里，将 BOS 金融级可观测能力的笼罩从最后的云上零碎扩大为全行的业务零碎，最终建设起了云上云下全链路的可观测能力，通过 BOS 这个对立可观测平台疾速辨认任何一个零碎异样点和性能瓶颈点，为业务的稳固运行和性能优化提供松软的根底。

四、写在最初

在云上云下全链路可观测性的一直实际中，BOS 继续在各个技术畛域深刻耕耘，建设起了欠缺的解决方案，积攒了丰盛的落地教训，并且一直致力于提供更加繁难的接入形式与更加丰盛的可观测能力，一直拓宽产品能力的边界，为更多的客户提供残缺的全链路可观测能力，为企业数字化转型助力。

后续咱们会继续分享可观测产品能力继续演进过程中的实际与思考，对产品或技术感兴趣，能够浏览产品官网 https://antdigital.com/products/biosp，也能够分割 hengyang.mhy@antgroup.com。

本文作者：钱世俊（花名：月岩），蚂蚁团体数字科技事业群可观测图谱产品研发负责