众安在服务治理+可观测的可融合Agent演进实践

原创徐敏众安科技技术团队

“ 在过去的6个月，云原生的基础构建能力 + 服务下沉的OneAgent方案遵循着不可变基础设施，使用镜像插件化编排能力、动态配置能力，系统已经覆盖1000+微服务，数千POD的生产接入①，承载着百万级并发及日均百亿级观测数据压力，并随着服务进一步规模化接入，数据还将上升一个数量级。”

2022是众安保险架构团队开始探索云原生相关技术的第6个年头，也是大规模落地实践OneAgent融合技术的元年。从云原生的早期定义应用的容器化，面向服务的架构、容器编排等等，实践落地OneAgent是云原生深耕微服务标准化过程中的重要一环，也是基础平台团队探索出的符合目前众安架构演进的主要方向之一。

在本次的OneAgent融合演进中，我们分别融合了OpenTelemetry、Sandbox、Nacos、 Sentinel、ChaosBlade、Arthas的融合体系，同时各Agent也可在各场景中以独立插件形态存在。

背景

在基础设施方面，众安保险应用100%部署在云上。应用架构方面，业务系统统一采用类springcloud生态微服务架构，已经形成了较为完善的云原生生态建设，治理着超过上万服务的大规模集群服务。

众安架构治理正在给予云原生架构持续演进，从单体、经典RPC、微服务到云原生一体化，架构治理的主要矛盾从架构如何支撑业务发展变成了架构如何给业务带来技术红利，是一个从业务驱动转向技术驱动的变化，也就意味着在后云原生时代如何充分利用云原生的技术红利快速形成技术价值，同时也存在不可回避的客观因素，云原生技术的快速迭代面临着技术投入与稳定性的双重压力，特别对于金融基础架构来讲，就要做好回答红利与稳定的平衡性问题。

回到金融保险类业务架构治理有三个比较特殊的点②：

第一个是安全合规是红线，架构标准要设定技术合规下限，在业务设计帮助大家考虑合规需求的扩展性和一致性；

第二个是历史包袱比较重，这是一个巨大的风险挑战，但技术先进性会让一些业务的开展从不可能变成可能，而且金融创新是国家政策倡导和鼓励的课题；所以我们相信鼓励技术先进性探索，会成为架构治理重要环节。

第三个是治理过程中，对传统业务流程和组织结构带来的冲击，需要转变企业文化，打破部门壁垒，夯实数字化转型的群众基础。

在降本增效方面，资源要降本、效率要提升、业务要敏捷是目前中大规模团队面临的新时期的话题，在未来几年也将延续的工作目标之一，必然需要去回答要稳定也要红利。

40% 的云原生开发者专注于微服务领域《2022中国开发者调查报告》③

挑战

众安采用无侵入为主、多语言的异构体系为辅的技术方案。尽量避免对业务代码产生侵入，升级也能够做到尽量减少对业务这块的一些感知与影响。简单来说就是 Istio 配合 Agent，或者称之为 Agent 加 Mesh 双治理的体系。众安应用服务技术体系，虽说是拥抱多语言，但实际上更多还是以 Java 占据绝对的比例。目前众安使用这两种技术体系共同完成不同业务场景的覆盖，这也是金融保险行业比较先进的治理方式。

在大规模推广的业务核心系统中，我们更加倾向于使用JavaAgent的成熟方案，相较于传统服务框架，无侵入 Agent 服务治理有如下核心优势：

代码无侵入、业务无感知引入。业务无需对程序代码任何修改，配合发布系统（托管Agent 参数）实现一键使用。
多版本兼容。同时适配不同版本框架的应用。
微服务治理全家桶（Spring Cloud/Sentinel/Nacos/OpenTelemetry）。业务无需感知框架、版本等细节，获得SDK同等的微服务治理 All-In-One 能力。
接管主流注册中心（Nacos/Kubernetes）。打通服务注册中心，注册与发现全托管。
兼容全系 Java 应用。基础框架无限制，多JDK版本兼容。
模块化设计，可按需热插拔、升级。业务可按需加载、卸载功能模块，组件灵活演进、升级。
云原生方案的发布体系加持。实现无感的发布体验。

④无侵入 Agent 服务治理方式一定程度上对传统服务框架的组织与接入方式进行了重新定义，为单体应用、初步微服务化的应用提供了便捷的微服务治理套件落地方案。作为目前Java领域相对成熟的技术体系，这种设计的有效性、稳定性、长期性，对大规模推广提供了足够支撑。

无侵入 Agent 服务治理技术可以帮助企业业务高效完成微服务化改造，也为后续微服务架构的持续演进提供了技术基础。

OneAgent是基于Java Agent技术实现的统一的Agent接入、代码增强、配置下发、版本控制等一系列的功能叠加，也是这次融合演进在应用侧的功能主体，决定了演进方向的可实施能力，然而，大规模应用推广带来的挑战跨越了单个技术选型本身，从数据面的数据控制能力、控制面的配置下发到监控、治理数据的上报、加工、存储、分析、告警等，每个环节都需要应对百万级的并发以及TB级的吞吐能力。

在整个降本提效的大背景下，效率与成本的考量也显得十分重要，对于挑战本身的方案设计在本次演进方案中是高于功能设计本身去规划的，在部分已知功能设计选型前提下，哪些未知因素会成为未来实践落地的瓶颈便是日程上重点，如何在不同阶段不同问题下有对应的设计规划，架构本身的非功能性需求需要有一些PlanA、B。

挑战项	容量规划	当前方案容量
采样	100%	50%
POD数	万级	千级
容量	千亿级	百亿级
吞吐量	百亿级	十亿级

架构融合的调整是现阶段需要解决的挑战，但架构融合始终无法解决能力上的融合，但能给能力上的融合提供一道上升的台阶，这也是下一步我们重点规划的方向。如何突破数据孤岛建设可融合的能力平台依旧存在新的调整，特别在进一步演进AIOps过程中问题依次会被提出。

OneAgent的提出是在阿里开源产品OneAgent技术概念之上提出的。

演进方案

在分布式系统中，应用通常包含业务逻辑、非功能性需求（NFR）和中间件依赖（三方依赖）。

业务逻辑
中间件依赖（三方依赖）
非功能性需求（NFR）

在应用程序中，只有业务逻辑才承载具体的业务价值，NFR 和三方依赖是必要的非增值活动，不直接产生业务价值，但依旧需要耗费开发人员大量的时间和精力，影响业务交付速度。

在微服务架构中，主流的微服务框架解决了部分 NFR 和三方依赖的能力，提升了业务价值专注度，但是所有的能力都耦合在应用程序中，导致其扩展性和复用性收到严重挑战。

在OneAgent技术路线中，将 NFR 能力从业务逻辑中抽离出来，下沉到单独的组件中，实现 NFR 与业务逻辑的沉底解耦，进一步将开发人员从非增值活动中解放出来，更加专注于业务价值交付。解决了大部分的 NFR 的能力（如可观测性、熔断、限流、灰度、路由、负载均衡等），但是三方依赖（如 Mysql、Redis、MQ 等）等依赖于业务逻辑耦合，目前仍然需要开发人员通过SDK依赖方式在业务代码中进行集成。

三方依赖的能力下沉在Sidecar+Dapr的构建体系中包含。

选型

不过对于一个企业来说，想构建NFR的整体能力下沉，不是一蹴而就一步到位的。不同的企业类型，以及不同的行业背景，都有不同的侧重点和建设方式。相对于Agent的选型，存量业务切入，现状生态的成熟度，未来长期演进的定位都是参考因素。

可观测体系

站在长期定位上，功能融合导出未来能力上的融合，可观测就要解决数据孤岛问题。针对数据孤岛问题，可观测的最终目的在于解决故障，更高效的、自动化的排除故障。

目前行业内的一大趋势是：拥抱 OpenTelemetry。

OpenTelemetry 是由一组 API 和库构成的标准，由 OpenTracing 和 OpenCensus 项目的合并而来，服务于可观测技术的底层数据采集，最早由微软和 Google 发起，当下已经成为美国可观测行业研发的事实标准 —— 微软、Google、Datadog、Splunk 等企业全部采用 OpenTelemetry 完成底层的数据采集，而 OpenTelemetry 的主要贡献者也来自这些公司。

OpenTelemetry 的特点在于制定统一的协议数据格式，并提供底层数据采集器，目标是兼容所有的语言、所有的系统。

现阶段众安的需求如下：

维度

Traces
Metrics
Logs
Events（包含在OpenTelemetry定义中）

全链路组件覆盖

前端
WAF
Ingress
微服务应用

Java
Go
Python

稳定治理体系

云原生为众安提供了一套指导思想，在既有的容器化的基数设施和DevOps体系建设上，延伸出更加符合当前现状且可大规模实施的微服务架构和治理体系。在体系建设方面众安采用核心能力拥抱开源，针对不同场景提供了基于云原生的Ingress和Nacos的东西流量服务注册发现，在该架构体系上提供应用外的服务注册发现、熔断限流、安全校验、灰度发布、多级容灾，保障线上不掉流量。意味着需要将Nacos Discovery、Sentinel、RPC（Feign、Rest）调用的深度治理能力融入Agent体系，基于团队对Sandbox理解和阿里技术栈集成经验，采用了SandboxAgent作为Agent基座托管。

大规模集群支撑能力

动态配置下发
秒级的响应
实时监控上报与告警

增强内容

在构建基础可观测及防护能力上，极大提升了微服务应用的稳定性及存活能力，但基于标准且固定形态形成的基础能力难以覆盖运行时相对复杂场景的观测及诊断需求，服务生命周期中运行时覆盖了技术上的启动、运行、下线，也包括业务的功能上线、迭代、放量、新业务新流量的冲击，每一次事件变更都可能会成为一次新的故障根因，在此基础上，需要构建更具灵活性的事前事中治理能力。

「事中」应用洞察：基于应用诊断能力的动态的调试型信息采集，参考类似于去哪儿bistoury。
「事前」攻防联合：在一系列可预知的行为场景自动化、随机化，演练观测防护的响应机制。

架构设计

在架构设计上，OneAgent的探针身份贯穿了整个数据面，并跟随POD能力进行弹性伸缩，大规模的系统设计中，复杂度从探针侧转移到了后端服务收集器侧和分析侧上，吞吐量和算力决定了流量和告警响应的实时性，架构升级上我们也从早期的Flink+ElasticSearch架构切换到目前的Flink+Clickhouse组合。

精准治理

精准治理离不开数据的完整性要求，更离不开控制面对于治理粒度的精确支持，同时治理粒度过细又提高了应用的管理成本，分级治理是平衡能力与成本的一种较好的方式，同时对于应用接入和治理提供了一个可递进的能力。特别是在大规模实施场景下，应用的迭代、变更都将对管理成本提出新的挑战。

控制面的分级治理包括：

全局：对应基准的能力配置，可覆盖至全部应用；
组：对应场景实践的分组治理，比如核心链路、强弱依赖划分；
应用：针对服务本身的配置，优先级高于组和全局；
发布单组：对某一次发布的应用标签，可覆盖多个应用。

维度和指标

一份报告都由维度和指标组成，但这些维度和指标的数据都分散在系统的不同环节中，距离原始信息越近的指标数据将会越准确，对于后续的采样平衡了整个系统的存储和算力成本，在整个系统环节中，主要设计了以下指标计算点。

Agent-Point

Sentinel2Metrics
JMX2Metrics
OpenTelemetry2Metrics

Flink-Point

Span2Metrics
Log2Metrics

DB-Point

ClickhouseMV2Metrics

实践

对于大型的自研或开源系统定制落地，系统的大规模推广非常考验团队对于工程流程的制定和遵循，特别是作为统一的基础能力项目被集成在全司的服务之上。在实践上我们提出了可达成实施的协作机制，主要围绕2个时态2个关键点。

流程化

开发态

版本

流程

发布态

上线发布三板斧：可灰度、可监控、可回滚。

版本 & 流程

基础设施

在基础设施侧，可以通过常规的服务编排方案，也可以通过DeamonSet进程拦截注入方案。

正式版本

apiVersion: apps/v1 kind: Deployment metadata: annotations: creator: "" labels: app: xxxx app_id: "7376" appversion: 1ceb71ff-xxx-t55cj base_name: xxx flow_id: 62100d54fd34 initcontainerset.kubecloud.io/sky-one-agent: "" prime_department_id: "xxx" project_id: "2365" publish_version: v1-xx

实验版本

apiVersion: apps/v1

kind: Deployment
metadata:
  annotations:
  	creator: ""
	labels:
    app: xxxx
    app_id: "7376"
    appversion: 1ceb71ff-xxx-t55cj
    base_name: xxx
    flow_id: 62100d54fd34
    initcontainerset.kubecloud.io/sky-one-agent-experiment: ""
    initcontainerset.kubecloud.io/sky-opentelemtry-agent-experiment: ""
    prime_department_id: "xxx"
    project_id: "2365"
    publish_version: v1-xx

规划

架构升级要回答能力、效率、成本多重问题。经过半年的实践，在过程中回答了路径设计的正确性，在数据上回答了目标设计准确性。未来，降本增效进一步迈向深水区，找技术要红利的门槛越来越高。

在云原生的基础加持下，OneAgent将大规模Java微服务的非功能性能力下沉，符合目前阶段的架构预期，但接下来依然要回答一系列的后续问题。

Agent作为固定资源消耗对于POD的影响，提升资源使用率，集群下最大可用资源率，最佳资源配置是什么。
在接入门槛上降低使用门槛，功能的确定性应用在场景的不确定性下，排列组合式的复杂度难获得使用上深度体验。
在演进上，未来ServiceMesh能否随着稳定性的提升，门槛的进一步降低，在金融核心架构领域得到大规模实践推广，稳定性的提升，成本的进一步降低，目前还没有准确的答案，在统一控制面的趋势下，同样需要回答上述的问题。

AIOps将是未来的方向之一，下阶段规划也将聚焦以下2个方向：

深度资源编排，自适应性的资源和集群配置。
架构融合到能力融合，以根因分析+治理推导的全局视角。

摘自

① ②基建规模《一年 100% 云原生化，众安保险架构演进的探索与实践》

众安的基建规模，众安这边的主机规模，按照 4C8G 这种机器的规格去计算的话大概是在一万加以上，应用规模是一千多个，技术人员的规模大概是在两千以上。众安技术架构在转向云原生之后，结合资源弹性编排带来的成本节省，以及 DevOps 体系建设和落地，有效提升了需求交付率，缩短了交付周期。从统计的数字上来看，21 年众安发布次数在 12 万次以上，相交于云原生之前增长了 22 倍，关于转向云原生，众安还是获得了非常明显的收益。

③CSDN《2022中国开发者调查报告》

参考https://www.infoq.cn/article/KNp1ibj40vS8IIZCizMW

④https://mp.weixin.qq.com/s?__biz=MzIzNjUxMzk2NQ==&mid=2247512421&idx=1&sn=b944aa40ad828da59169fc64df379439

继续滑动看下一个