随着业务规模的不断扩大以及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。
本文作者：钱世俊（花名：月岩），蚂蚁集团数字科技事业群可观测图谱产品研发负责人。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
3.java 中的 clone 3.1. 什么是 “clone” ？ 在实际编程过程中，我们常常要遇到这种情况：有一个对象 A，在某一时刻 A中已经包含了一些有效值，此时可能会需要一个和 A完全相同新对象 B，并且此后对 B 任何改动都不会影响到 A中的值，也…
