关于软件架构:蚂蚁集团技术风险代码化平台实践MaaS

📄

文|吴成辉（花名：清霄 蚂蚁团体高级技术专家 )

校对|陈真、庄晓丹、冯家纯

本文 6250 字 浏览 11 分钟

▼

咱们一起回顾下监控下层业务已经面临的问题：

• 烟囱式的监控剖析反复建设

在技术危险畛域，一度有超过 5 个零碎在做监控剖析的能力建设，大抵逻辑根本都是拉监控的 Raw Data，做根底的聚合、剖析解决后（相似同环比、阈值类的形式），依据一些以后的场景输出，联合一些算法能力，得出一个论断并触发一系列的 Action。相似这种烟囱式的监控剖析场景，都是比拟高级的反复建设，不足智能化、体系化。

• SRE 教训标准化积淀的问题

在剖析场景里也面临 SRE 教训无奈标准化积淀复用的问题，什么是 SRE 教训？拿交易付款上涨来举例，如果以后交易付款上涨 10%，SRE 通常有这么几个剖析门路，首先看下淘宝交易是否上涨（起源），再看交易创立，收银台渲染是不是上涨等，这一类咱们称为业务依赖。从全局看是否有大规模的压测、变更等动作，这一类称为变更关联，以及如何依据以后故障状况决策进行切流、限流等复原措施，咱们称为剖析后置操作。

• 长尾需要

比方比拟常见的，算多数据之间的成功率，流量损耗等等需要，通过产品化解决的老本十分高，而且用户不能疾速批改、定制相干能力。

同时咱们看到以后监控零碎本身面临的问题：

• 监控的数据应用简单

蕴含了几万张数据表、十几万张自定义数据表，数据类型超过 20+，以及跨站点、数据源异构等等问题。

• 监控服务不够凋谢

如何动静日志荡涤计算、如何做剖析后的时序存储、监控的时序检测能力如何复用等等。咱们须要把监控的数据、能力齐全服务化进去。

• 高效的可编程代码化平台缺失

没有一个高效平台帮忙 SRE 先积淀教训、再促成教训的标准化、复用，最初产品化。

基于下面问题，咱们提出了 MaaS 的构想（Monitoring as a Service), 监控能力服务化，凋谢、交融监控能力到技术危险各个领域，疾速实现 SRE 场景建设，积淀可复用能力，次要蕴含以下 4 个阶段指标：

1. 凋谢服务把监控的计算、存储、算法、视图等等能力凋谢进去。

2. 外围共建几个重点的技术危险畛域场景，比方变更进攻、压测引流、无损注入、定位应急等等。

3. 促成服务的标准化积淀，让更多的场景能够复用、独特建设这部分的能力。

4. 解决“监”与“控”之间的链接问题。

（咱们的这里的 AIOPS 更多指的是

一系列专家教训的汇合、积淀、继续保护优化）

PART. 1 平台技术概览

能力服务化

监控的服务化能力整体蕴含这么几局部，数据服务化、配置服务化、计算、存储服务化、算法服务化、告诉、云原生服务化等等，也包含一些内部能力集成比方音讯缓存等等。

我简略举两个服务化的例子来介绍下什么是服务化：

比方视图服务，当某个变更发动后，这个变更关联的 100 个利用指标、20 个业务指标中的 10 个指标呈现了问题，这个时候，咱们须要动静为这个 10 个指标创立一个数据视图，来剖析业务影响范畴，这个时候就会用到咱们的视图服务。

动静计算服务，比方我须要实时计算下某个利用在 A 机房（或某个 ZONE 如：GZXXX）的其中 5 台机器在 11:00~12:00 的接口办法调用状况，动静的计算服务就会派得上用场。

数据服务化

能力服务化中十分重要的一环就是数据服务化，因为数据是所有监控剖析的根底，数据服务化次要分成两局部。

• 第一步是监控数据模型化

咱们从数据的应用视角把数据抽象出数据虚构表、虚构表列定义、列关系。以及虚构表的实现绑定，蕴含指标数据，也蕴含关系元数据，最初把这些物理实现映射到监控具体的数据指标或者底层的元数据服务上。

• 第二步是服务模板化

咱们把一个数据服务形象出三类：

实体查问，比方查问一个利用或者一个 Tbase 的集群；

数据查问，比方查问一个利用的 Sofa Service 在 APP 聚合维度上的数据；

关系查问，查问一个实体的关联实体，比方 cif 关联的 Tbase 集群等。

• 最初，咱们实现了 5w+ 数据服务主动生成，分钟级别 SDK 更新的能力，咱们能够通过十分语义化的拜访形式来拜访监控的所有数据，咱们能够做到只有是监控体系内的数据，都能够通过咱们这套能力拜访到对应的数据服务，从而达到整个监控数据的服务化凋谢。

研发效力

• 大库治理，咱们设计了一种能够反对服务积淀、权限隔离（能够独立按目录治理 CR）、逻辑复用的代码构造，比方缓存 Tbase 的研发 + SRE 能够独特在 cache 目录外面定义缓存问题的发现、剖析、复原。同时能够复用到 core-service 外面的比方容器是否衰弱，网络是否异样等规范服务。平台可能提供统一的多环境调试能力，不便监控剖析逻辑能够间接运行在本地 IDE 环境中，咱们通过动静代理的模式把本地拜访的数据、函数服务代理到服务端，从而达到了本地跟线上完全一致的研发体验。这项能力极大地提高了研发效率，研发过程中能够间接 debug 线上数据，比传统的日志模式的调试形式有十分大的效率晋升，一个根底的剖析函数根本能够在小时级别内实现。

• 一站式公布运维，传统的 Serverless 公布模式大抵要经验这么几个阶段，从工程打包到 Jar 文件，耗时 1min，大略在 100-300MB，从 Jar 文件打包 Build 出镜像，大抵 10min，最初做镜像化公布整体耗时约 20min, 整体流程大略消耗半个小时。咱们研发了一套基于函数粒度的公布运维模式，以 MaaSFunction 为入口，做跨文件 Linker，如何做 Linker，看这个示意图，咱们从 MaasFunction 入口开始解析本类依赖的文件，比方这边依赖的其余函数，到上面的 service，再到 util 层的相互依赖，从而通过这种形式解析出业务代码片段，通过动静编译完 Jar 大小目前最大在 500KB 左右，依据代码大小个别在 5s 内，再通过热加载到指标机器上，整体能够做到 5s 级公布，1s 回滚，其余还有配套的日志、监控等等能力。

多语言 Runtime

咱们在初期建设的时候函数是都运行在一个集群外面，常常会遇到例如：死循环、OOM、线程频繁创立等等性能问题，因为业务代码不可控，CR 不能齐全杜绝这类问题，这样咱们就须要齐全隔离的函数运行环境，从图中能够看到，每个函数至多具备 2 个独立的容器（容灾的须要），函数 1OOM（Out Of Memory），不会影响到函数 2。这样咱们就能够根本做到函数级别的执行层隔离，咱们通过 SLO 的度量，平台稳定性有了十分大的晋升。

当咱们依照函数级别隔离的模式大规模上线的时候遇到了老本问题，底层 sigma 反对的 pod 调度的最小规模是 0.5c（底层物理网卡等等限度），如果 2 台容灾，基本上一个函数至多占用 1c 的物理资源，随着函数业务的大规模应用，这块老本是很难继续的。通过咱们的察看，绝大多数函数占用理论的 CPU10% 不到，甚至更低。咱们同 Serverless Paas 团队一起共建了函数的高密度部署模式，通过 0.5c 的 pod 中隔离 5 个 0.1c 的容器，而后通过容器 IP + 端口的形式绑定到函数的执行下来，这样整体的资源老本能够从 1c 升高到 0.2c，老本升高到 1/5。

最近咱们还反对了 Python 语言，下图是繁难的代码 Demo。

PART. 2 利用场景

变更监控

蚂蚁变更故障占比是整体故障占比的三分之一，而监控是变更过程中十分重要的一环，以后面临很多问题，当一个变更发动的时候，咱们拿到依据变更的范畴，自动化的生成外围的零碎、业务指标比方利用的 gc、CPU、服务成功率，谬误数据等等，解决第一个不晓得变更看什么指标的问题。咱们的 MaaS 计算服务会依据变更范畴动静生成一组指标的实时计算，（变更前、变更后，变更组、非变更组）等等，因为是依据变更范畴动静生成的计算，所以解决了监控粒度粗的问题，这些数据产出后，依据咱们的异样检测算法，得出本次变更过程是否有指标异样，解决不晓得怎么看的问题，咱们通过函数编排的形式同变更外围流程买通，整个过程无需用户参加，如果变更监控发现异常会主动触发拦挡阻塞异样。

• 无效：全年累计拦挡实在故障 163 笔，变更监控拦挡 75 笔，占总体拦挡数的 46.01%。

• 通用：变更监控外围进攻服务对立，笼罩全站 87.74% 次要运维场景。

• 规模：日均 1.2w 次变更进攻，30w 动静监控创立。

业务链路报警剖析

常态状况下业务告警乐音的比例达到了 66%，对日常研发、SRE 同学的打搅十分高，不利于业务的应急流程、稳定性建设。其实 SRE 同学有十分多的乐音断定教训，然而降噪逻辑没法自定义，导致降噪十分艰难。

咱们通过与国内 SRE 团队深度共建，建设了一套告警剖析服务，流程能够简略概括为：

1. 构建业务链，拉数据
2. 做异样检测
3. 定位剖析
4. 推送异样、构建剖析视图

通过这个场景，咱们能够看到 SRE 教训是什么，什么是起源上涨、如何解决小流量业务，如何解决业务过程中失常的服务损耗，以及如何做业务的剖析定位等等。

• 告警有效率从 34.68% 晋升到 91.15%。
• 国内 GOC P1、P2 业务告警覆盖率 85%，S2 大规模推广到全站。
• SRE 从整体构思到第一个 Poc 实现只花了 2 周工夫。

配置代码化

这个场景次要是要解决批量化笼罩的效率问题，比方仿真建站，利用监控规定主动笼罩等场景，咱们通过服务化的形式把这些能力裸露进去达到一个提效的成果。简略拿利用监控规定笼罩来说，代码逻辑是通过先配置好模板，而后通过一些配置替换，最初批量大规模笼罩。在仿真环境建设过程中，做到了依据流量实时调整阈值，0 人工配置，重庆消金建站，5 人天的配置工作升高到 0 人工监控配置。利用规定自动化笼罩也是从今年 527 的几十人日，升高到 1 小时。

（中间件 SRE 同学的代码化案例：）

• 利用规定自动化笼罩：

全站利用规定笼罩升高到 1 小时，527 国内利用告警 0 人工配置。

• xx 业务建站：

中间件 10+ 产品 升高到 0 人工监控配置。

• 仿真环境建设：

仿真规定自动化笼罩、阈值动静调整，0 人工配置。

后续咱们会有更多的系列文章来详尽的介绍如何通过 MaaS 来做更多技术危险能力建设（尽请期待），这里先不开展叙述了。

PART. 3 写在最初

MaaS 将来布局次要分三局部：

• 平台能力建设，把监控的服务化门路复制到技术危险更多场景，动静弹性、以及研发流程标准化。

• 代码生态化建设、社区化建设，建设监控剖析畛域的服务目录（比如说容器 CPU 如何剖析、热点办法是什么等等），函数服务、利用市场的建设，来让更多 SRE 单干在一个畛域外面进行继续建设，最初是社区化的经营能力。

• 监控 + X（跨技术危险畛域）摸索，从咱们这两年的教训来看，监控 + 变更 = 变更监控、监控 + 演练 = 无损注入、监控 + 压测 = 性能剖析 等等，咱们看到了这些畛域一些质的变动，咱们心愿挖掘出更多这样的场景，比方监控 + 限流 + 容量，做精细化的限流能力建设等等。

如上图，MaaS 的 Logo 看起来像一个木头搭成的房子，象征着咱们心愿业务可能像积木一样疾速建设，M 又是两个小三角形，三角形象征着稳固，咱们心愿 MaaS 平台可能十分稳固地反对下面的业务。M 中还交融了曲别针的图形，象征着连贯。

平台的指标与幻想：有一天咱们剖析操作系统不再找系统部同学，剖析中间件不再依赖中间件同学，剖析缓存不再等着同学（支付宝一位负责缓存的 SRE 专家）给排查论断，过程起不来，配置核心连不上，都能够通过代码在线诊断的形式一键剖析，而不是简短低效、口口相传的文档，让技术危险常识能够真正通过代码的形式共享。

咱们幻想整个技术危险能力都能够通过 MaaS 平台实现 Auto 化。有一天，秒级压测熔断、变更进攻、流量精细化调拨、预案决策、自愈等等能够真正做到 Auto，真正的无人值守。

• END –

2019 年双十一之后，咱们开始了 MaaS，一晃近两年了。到目前为止，MaaS 无效研发用户近 200 人，函数服务超过 1000+，日函数调用达到 1000w，剖析近 200 亿数据点。咱们的 MaaSHub（社区化产品）、多语言反对等等也在疾速迭代中。

• 质疑

MaaS 在最晚期推广的时候（包含当初依然存在），为什么要用这个平台？其实大多数同学是带着质疑的，最常见的几个反诘：我的代码为什么要写在你的平台；你们平台当初还不成熟，我的业务很重要；我只是想拉个数据而已，还要学你这么简单的货色等等。这个过程比拟艰巨，然而通过咱们的疏导和反对，用户曾经能够自助地在平台上做各种函数研发，并且用户之间开始自发推广流传，不是咱们平台牛逼，而是咱们有监控松软的数据、计算、存储、算法能力，有整个 Antmonitor 40 人团队作为咱们最动摇的后盾。

• 获客老本

代码化的产品是人造区别于产品化产品的，在晚期时候，服务化能力匮乏，单个用户的转化留存，至多要花费 2 人 / 周的研发老本，能够设想这样昂扬的付出促使咱们会如许珍惜现有的 200+ 用户，需要根本都是当天研发到预发，次日上线。让用户有了安全感、信任感，能力留存。

• 平台生态

生态这个词比拟大，比拟空。用写实一点的话来形容，如何建设 MaaS 生态，须要答复好上面几个问题：

1. 如何让用户的代码缓缓转换为平台的积淀，缓存的诊断代码到底什么时候可能做到标准化、疾速复用（缓存是咱们单干比拟久，绝对曾经是比拟成熟的畛域），这个很难，然而须要去做，或者说咱们须要建设一种机制让这个通道变得可能、简略。
2. 平台的积淀如何再反向促成平台用户的倒退，平台有了十分多的剖析能力，如果疾速推介到用户，让用户感知到，应用起来，让用户构建场景更加简略、疾速。
3. 如何复用用户场景，用户解决的问题是一个特例问题，还是一个通用问题？如果是通用问题，是不是能够间接通过复用用户场景，达到通用问题解决方案的逻辑复用。

当然整个服务化的过程是十分乏味、干燥的。将来咱们想从监控逾越到技术危险，那么更多技术危险平台的服务化集成是条必经之路。然而如何疾速集成内部零碎的服务化能力，这块咱们也正在做一些摸索，并且已获得了一些成绩。

• 大库模式 & FaaS 模式的生产实践

为什么采纳大库，大库次要解决代码透明性的问题，透明性的指标是为了促成代码积淀、更高层次的复用，所以咱们摒弃了传统 FaaS 平台的单函数单库模式，因为咱们的首要指标是代码的积淀复用，其次是高效的函数研发平台。

FaaS 模式还是太超前了，绝大多数同学还是习惯于传统的 Project 模式，各种三方包、TR、反射满天飞，不太适应函数的研发模式，在这个过程中咱们也做了十分多的兼容，让函数也能像传统利用一样应用各种性能，然而在 Serverless 还没有遍及的明天，FaaS 将来的路是还须要更多的摸索与实际翻新。

• 剖析型 DSL

咱们已经破费大力量尝试设计了一套本人的剖析 DSL，如下图一个支付宝交易异样的剖析 case：

尽管咱们始终想尽量拔高剖析的档次，然而能够看到还是无奈防止地裸露了很多细节进去（如检测的阈值、工夫、比照操作符，返回值类型等等），一旦裸露细节之后，离咱们的初衷就会有比拟大的偏差。

DSL 之所以无奈落地推广的起因，其实就是上图的层次结构了解问题。DSL 不适宜形容细节，DSL 的善于畛域是无限的表达能力，而咱们当初真正缺失的是大楼的地基（也就是一二三层），远远没达到 DSL 的档次。

• 代码化 VS 产品化

代码化的止境是产品化，两者是不矛盾的。

特地是监控畛域的各种剖析能力，剖析能力还没有就焦急落地相干的剖析、定位产品是十分危险的，咱们在这个下面也吃过亏。当初咱们的门路是先落地代码剖析能力，再把这个代码化函数服务形象成一个 Controller，把必须的参数形象为产品化的输出，反向行之。最初变成一个稳固、牛逼的剖析产品。