如何从繁杂的数据指标中精确识别出异常情况，是保障系统高可用的关键。

一、引言

近年来，针对电商的电信诈骗层出不穷。

不法分子借助非法手段获取到消费者的个人信息，假冒电商客服人员；利用“退换货”、“快递丢失”、“商品质量”等借口联系消费者，通过诱导消费者转账，开通借贷平台账户等方式骗取钱财。

这类“假冒客服”能够准确提供消费者姓名、电话、购买物品、购买日期等信息，导致此类诈骗防不胜防。

为了保护个人信息权益，规范个人隐私信息的合理利用，我国在 2021 年 8 月 20 日正式通过《个人信息保护法》，于 2021 年 11 月 1 日起施行。

《个人信息保护法》细化、完善个人信息保护应遵循的原则，开启了个人隐私保护的新阶段。

淘宝作为我国的知名电商平台，在保护消费者个人隐私方面潜心研究，力求在保障商品履约配送顺畅的前提下，实现消费者联系方式等隐私信息的保护。

为此淘宝与阿里云云通信团队深度合作，借助云通信号码隐私保护服务的底层能力，结合订单域、物流域、通信域的全链路改造，形成了一套面向电商的隐私保护方案——淘宝隐私面单。

淘宝隐私面单的核心逻辑是为消费者的每笔订单分配隐私号。

在交易履约的全链路中，商家、物流都是通过隐私号与消费者沟通，从而达到保护消费者真实手机号码的目的。

消费者创建订单时，为隐私号与消费者的真实手机号创建一组绑定关系，以商品配送过程中呼叫为例，物流配送员拨打隐私号，隐私号接到呼叫请求后，隐私号借助自身转呼能力，将当前通话转接到对应消费者真实手机号上，在不泄露消费者真实号码前提下实现通信服务。

这一核心逻辑的实现就依赖于号码隐私保护服务，这项服务是阿里云云通信团队在 2017 年推出的，致力于解决陌生人通信场景中号码信息的安全。号码隐私保护服务以隐私号为媒介实现通信服务及附加功能，已在外卖、打车、房产、招聘等不同行业进行了实施、推广。

自淘宝隐私面单上线以来，云通信技术团队不断优化产品细节，提升服务体验。与淘宝上下游团队紧密配合，不断扩大淘宝隐私面单的灰度范围。

为了提高客户的隐私保护体验、检验产品在大促场景下的可靠性，淘宝隐私面单计划在 2022 年首次参与双十一的大促活动。大促数倍于平时的订单量、秒杀抢购带来的瞬时洪峰，都是对号码隐私保护服务的巨大考验。为了保障在双十一大促期间，淘宝隐私面单解决方案平稳执行，号码隐私保护服务需要攻克以下技术难题：

1）大规模号码资源的调度匹配

面对淘宝海量订单、数周的长绑定周期，需要大量的隐私号码来支持淘宝隐私面单业务。如何为淘宝业务匹配合适的号码资源是首先需要解决的问题。

号码资源的调度匹配，不仅要考虑客户的行业属性、号码用量、服务指标、特殊要求，还要考虑号码质量、号码规格、平台稳定性、成本。科学合理的调度分配策略，不仅要为客户匹配符合应用场景的优质号码资源，还要兼顾资源的最大化利用率。

2）大促活动中高并发、低延时要求

在淘宝双十一大促期间，订单量会远超日常。整点秒杀、抢购活动，最高一秒钟可创建数十万笔订单。当前淘宝隐私面单链路中，要求系统必须低延迟、同步返回订单对应的隐私号。因此系统无法通过削峰填谷、异步处理的方式，解决高并发带来的系统压力。

面对此类瞬时高并发的挑战，号码隐私保护服务需要在保证资源合理利用、成本不大幅增加的前提下，通过系统架构升级、关键节点优化等手段，实现大促活动中高并发、低延时要求的支持。

3）长链路履约流程中的可观测性

从消费者创建订单开始，到商品配送完成，各个流程都需要号码隐私保护服务的参与，整个服务履约周期以周计算。在如此长的时间周期中，当某个节点出现问题，系统必须及时感知。

号码隐私保护服务除了提供自身平台级服务外，通信过程还涉及与运营商的交互，如何从繁杂的数据指标中精确识别出异常情况，是保障系统高可用的关键。号码隐私保护服务整体采用微服务架构，从大规模集群中快速定位异常节点，也十分考验系统的链路追踪能力。精准、智能的监控观测体系，对维护系统高可用，保障商品顺利履约意义重大。

二、资源虚拟化与智能匹配

1）隐私号资源虚拟化

隐私号绑定了消费者与订单，实现通信层的呼叫转接，是整个淘宝隐私面单链路中的关键资源。号码隐私保护作为平台级服务，不仅为淘宝电商提供服务，还涉足外卖、打车、房产、招聘等多个行业。不同客户对隐私号的诉求有所不同。面向供应链侧，隐私号规格制式繁多、支持的定制化功能参差不齐。为了实现客户需求的精准匹配、隐私号资源的合理利用，号码隐私保护服务对隐私号资源进行了资源虚拟化。

隐私号资源虚拟化，对不同的隐私号进行了抽象和标准化；通过资源池化，实现了隐私号从物理资源到逻辑资源的转化。隐私号资源虚拟化将隐私号抽象成线路资源、码号资源两部分。

其中，线路资源(channel)为呼叫链路所支持的行业场景、定制化功能、线路质量的集合。某些线路可以支持多种行业的业务，一些线路只能支持特定行业类型。某些线路可以实现某些特殊功能，一些线路无法实现。线路质量包括线路的通话接通率、故障频次等指标。上述线路的各类参数指标被称为线路的属性(attribute)，属性反应了当前线路可以支持的业务类型和定制化功能，以及在使用隐私号通信过程中的服务质量。

码号资源(no)是隐私号自身的属性和参数的集合。主要包括码号资源类型、号段信息、归属地、码号状态、成本等。上述码号的各类参数指标被称为码号的规格(spec)，通过码号的规格可以圈定符合要求的隐私号。将某个码号归属到一条特定的线路上，则线路资源、码号资源就组装成了具备特定功能的隐私号。不同属性线路资源与不同规格码号资源的关联组合，可以形成各种所需的隐私号。通过将通信属性和码号规格解耦，大大提高了资源的利用率，也为客户需求与隐私号资源的智能匹配打下基础。

2）需求与资源的智能匹配

在资源虚拟化完成后，为了实现需求与资源的智能匹配，还需要对客户需求进行标准化定义。

首先要确定客户使用号码隐私保护服务时所需要个性化功能，功能性需求主要来源于服务级别协议(Service Level Agreement, SLA)以及特殊功能要求(Special Function, SF)。功能性需求中一部分属于平台标准化需求(Platform Standard Requirements, PSR)，可以基于平台的标准化能力实现，如安全风控、语音转文本等，此类功能性需求只需通过平台的标准流程接入即可。一部分属于隐私号个性化需求(SecretNo Personalized Requirements，SPR)，需要基于隐私号的个性化能力满足，如号码制式类型，定制呼叫放音文件等，此类功能性需求需要匹配合适的隐私号才能实现。

将隐私号类个性化需求拆分为呼叫类个性化需求(Call Personalized Requirements，CPR)和码号类个性化需求(No Personalized Requirements，NPR)。呼叫类个性化需求与线路资源中的规格相对应，码号类个性化需求与码号资源中的规格相对应。通过此映射关系，即可为客户匹配到符合需求的隐私号资源。

明确了满足客户需求的隐私号资源类型，根据客户的号码采购计划（SecretNo Purchase Plan，SPP）就可以进行平台的资源调拨，号码采购计划以各归属地所需隐私号数量的形式给出。

在号码隐私保护系统中，每个归属地在各平台上的隐私号分配比例，是基于智能匹配算法求解得到的。号码隐私保护平台设计了一套平台服务质量的评价指标，从号码数量、平台稳定性、成本、接通率等多个维度着手，将各类指标总结归纳为成本型指标、性能型指标两类可定量分析的参数。将不同类型的参数进行归一化处理，转化为可比较计算的平台属性信息矩阵。基于 santy 标度法，设置平台属性标度，求解出当前归属地在平台上的隐私号分配权重。完成资源与需求的智能匹配，将目标资源调拨给目标客户。

三、十万级并发的系统设计

在双十一大促期间，整点秒杀、抢购活动会在瞬间产生巨量订单。在无法通过削峰填谷缓解系统压力的情况下，如何应对这类尖峰型的瞬时高并发，是系统设计要解决的问题。提升系统的并发能力主要从性能、架构两个方面入手。

从性能方面入手，可以提升单机的性能，如升级 CPU、扩容内存、增加硬盘容量。也可以增加服务器数量，实现系统性能的水平扩展。机器的升配和扩容不仅会导致 IT 成本水涨船高，此类方式所增加的并发量还存在边界，往往会卡在系统的单一瓶颈点上。

因此在进行机器性能升级的同时，号码隐私保护平台着重从系统架构方面入手，通过高并发系统设计、关键节点自主研发，在低成本前提下实现系统的低延时、高并发。

1）隐私号调用链路架构

下图为隐私号调用链路架构示意图，系统将隐私号的使用场景区分为核心功能与控制台数据查询两类，核心功能主要包括订单绑定、呼叫查询、话单推送等功能，控制台数据查询包括隐私号使用情况、绑定关系数据的汇总统计。

整体系统基于微服务进行应用拆分，利用负载均衡和 RPC 服务实现应用间的通信。为了解决数据库的性能瓶颈，号码隐私保护服务对数据库进行拆分，解决海量数据的存储和查询。针对控制台上复杂数据的汇总统计，系统采用读写分离的策略，通过单独的数据库支持，减少主库的并发压力。

整个淘宝隐私面单并发压力最大的环节，是客户下单时为订单选择隐私号。为了更好支持此类数据高频变化的场景，号码隐私保护服务基于 Redis 内存数据库，自研隐私号选号引擎。

由于 Redis 作为支撑系统并发的关键节点，如果出现问题会造成全局的不可用。为避免这一情况，平台采用了热备的方式进行兜底。设置了主、备两套 Redis，主节点用于线上服务支持，备用节点实时保持与主节点的数据同步。在线上并发压力超过上限时，可以通过流量分散的方式，让主、备节点按比例承担部分流量，减少 Redis 的压力。

2）隐私号选号引擎

针对大促超高峰值的订单绑定并发数，号码隐私保护服务自研隐私号选号引擎，实现隐私号的存储、检索、绑定等功能。基于 Redis 内存数据库的特性，通过合理设计数据结构、舍弃中间态数据等多种优化手段，保障了特有业务逻辑实施过程的效率，提高选号并发能力。

Redis 作为内存数据库，可以为选号服务提供大连接数下低延迟的数据读写服务。在设计选号应用时，应充分考虑到 Redis 的技术特点，合理设计存储结构和选号流程。通过巧妙设计数据的存储结构，起到缩小存储空间，同时提高搜索效率的效果。

以淘宝隐私面单中扩展码的存储为例，系统采用符号数的方式存储扩展码。符号数 1 表示该位置的扩展码生效，符号数 0 表示该位置的扩展码失效。在进行绑定(bind)时，随机选取一个数组的起始位置，向下遍历，找到第一个存在符号数为 0 的数组位置(target index)。查找该数组中，任意符号数为 0 的位置(target pos)。通过位运算将该位设为 1，当前生效的扩展码为 Ext=index*size+pos。当需要对绑定关系解绑(unbind)时，扩展码 Ext 可以计算出采用符号数所在的数组下标 index=Ext/size，位置下标 pos=Ext%size，通过位运算将该位设为 0。这种基于符号数的存储方式，相较于传统字符和数值的存储方式，可以极大的减少存储的数据量。同时符号数的数据变更可以采用位运算的形式，降低服务时延。

瞬时大流量冲击很容易造成单点性能问题，导致系统运行异常。针对此类问题，号码隐私保护服务放弃中间态数据全一致性，只保证数据关键属性的最终一致性；以此减少系统内部并发数，降低系统压力。

此处中间态数据(Intermediate Data)指在某一系统环节、特定范围内变化的数据；这类数据在特定范围变化，该系统环节运行效果一致。与之相对的是终态数据(Final Data)，这类数据在特定范围变化，该系统环节运行效果会发生明显变化。

需要指出，中间态数和终态数据不是绝对的，是依据对应所处的系统环节判定，在特定范围内生效。如在隐私号选择环节，需要从 Redis 数据库中检索到可用的号码。每次绑定、解绑都会导致隐私号的绑定数数量的变化，绑定数会在 0 到最大复用次数 Max 间来回变化。当隐私号的绑定数没到达最大复用次数 Max 的临界值时，一个隐私号已绑定了 1 次，和已绑定了 10 次，对于选号系统来说，性质是一样，都表示该号码仍可以继续绑定。此处[0,Max-1)范围内的绑定数变化不会对系统决策产生影响，可视为中间态数据。当绑定数从 Max-1 增加到 Max 时，则需要从可选号码集合中清除该号码。当绑定数从 Max 减少到 Max-1 时，则应该将该号码重新添加到可选号码集合中，因此[Max-1,Max]是检索可用号码过程的终态数据。

这种状态数据的定义是充分基于对业务核心依赖的考量，通过放弃中间态数据全一致性的方式，大幅度减少读写和数据同步的频次，缓解了系统的并发压力，降低了系统异常的可能性。同时节省的资源开销，减少了资源成本的投入。

四、多维度监控观测体系

号码隐私保护服务采用微服务架构，通过系统组件化和服务化，提高了整体系统的敏捷性和扩展性。但同时微服务也为系统运行的跟踪监控、故障的识别定位带来挑战。号码隐私保护服务涉及的服务器数量众多，一次完整的请求处理依赖多个应用的通信交互，这给定位故障点带来很大困难。在淘宝隐私面单服务履约的长周期中，系统指标变化每时每刻都在发生，如何能从各类指标变化中精确识别异常是监控体系设计时首先要解决的问题。

因此，号码隐私保护服务不仅需要保证系统自身的高可用，减少系统发生异常的可能性。在发生异常时，还要能综合各类参数指标快速发现，及时决策，触发告警。在异常排查时，能借助链路追踪等手段，快速定位故障点，实现异常快速响应和恢复。

1）业务全链路追踪

微服务系统的可观测性依赖于应用日志(Logging)、统计指标(Metrics)和链路追踪(Tracing)三大部分，其中链路追踪是完整反映系统间调用路径和执行过程的最有力工具。

链路追踪中最重要的两个概念是 trace 和 span。一次完整的调用链路用一个 trace 来记录，当开始处理一个请求时，系统生成一个全局唯一的 traceId，通过 traceId 将整条调用链路串联起来。一个 trace 中包含多个 span，一个 span 记录着一次远程调用中应用的处理状况，如描述信息、时间戳、附加日志信息等。span 中有两个关键标记值：spanId、parentSpanId，spanId 是全局唯一的，用于定位当前调用在整个请求中的坐标，parentSpanId 则是上游请求发起方的 spanId。通过 span 间的父子关系和 trace 的整体串联，就可以得到一个请求响应的整体拓扑图。哪个应用响应超时，那个方法处理报错，都可以方便的排查到。

当前业界主流的链路追踪协议栈有 Jaeger、SkyWalking、Zipkin，基本都是基于 Google 的 Dapper 衍生而来。遵循以 trace 和 span 为核心的链路追踪方案，但在协议和具体实现上有所区别。

号码隐私保护服务是一个多应用混合的复杂系统，各应用的技术栈和实现方式有所不同。针对不同情况的应用，系统采用无侵入探针和 SDK 两种方式接入阿里云内部的链路追踪系统，实现调用周期内运行数据的自动收集关联。

无侵入探针基于 JavaAgent 实现，在系统运行态自动注入监听逻辑。无需修改业务代码，自动实现信息的采集，适用于容器化部署的 Java 应用。SDK 方式是利用链路追踪系统所提供的 SDK 组件，实现数据的收集和上报，有一定的配置接入工作量，适用于非 Java 应用以及早期上线的历史应用。

接入基础的链路追踪可以实现请求出入参数和异常堆栈追踪能力，但仅凭这些基础能力是难以快速定位线上问题的。号码隐私保护服务在绑定、选号、呼叫等核心方法处进行插桩埋点，记录单个方法执行层面耗时、状态等信息，从更细粒度感知系统运行情况。单条请求的处理情况不仅与其自身所经过的链路相关，也与系统水位、业务逻辑有直接关联。号码隐私保护服务通过日志标记的方式，将业务数据关联到 trace 的生命周期里。

业务数据与链路追踪相结合，可以更清晰的判断系统问题的产生根因。通过更详细的数据呈现及业务数据的主动关联，实现淘宝隐私面单整个业务的全链路追踪，当异常发生时能够快速进行问题定位，对系统可观测性的提升具有重要意义。

2）监控决策系统

业务全链路追踪可以在问题发生时，帮助我们更加准确、快捷的定位问题点，但却无法做到异常的主动发现。为了能在异常发生时准确的感知，号码隐私保护服务建立了智能化监控系统，可以在异常发生的第一时间感知。

针对可能发生的异常状况，号码隐私保护服务对各类指标参数进行细化，设计了一种基于系统指标、接口指标、业务指标的三维指标监控方案。

系统指标为服务器、数据库、各类中间件的性能指标，包括：cpu 利用率、内存利用率、GC 次数、连接数、读写 RT 等。接口指标为单个 RPC 服务请求接口的指标，包括：总请求数量、成功率、耗时等。业务指标为号码隐私保护关键行为节点的参数指标，如绑定成功、选号并发数量等。这三种指标分别反馈了单机、应用、系统三个层面的潜在问题，从不同方面反映系统的运行情况。

当多维度监控出现指标异常时候，应及时告警并触发降级逃生。但如果业务量正常起伏、系统出现抖动就频发告警，甚至触发降级策略，会导致系统受损，能根据监控指标异动推导出真正系统异常是十分重要的。

为此，我们训练出一套智能的异常决策系统。将异常点与当时的系统指标进行映射，利用监督学习获取异常状态与各类指标的映射关系。导入异常决策系统，在接受到线上实时的监控数据时，根据多维度监控指标，决策当前系统的运行情况。不同的学习函数给出自身的决策值，通过投票判断当前系统是否处于异常节点。出现异常及时发送告警信息，执行相应的的降级逃生操作。新识别出的异常节点又作为训练数据，补充到监控决策系统的训练中，经过多轮迭代，异常状态与各类指标的映射关系会更加科学，监控的查准率和查全率也会不断提高。做到系统异常及时发现，系统正常抖动不误报。实现系统异常发生快速介入，问题及时恢复，保障商品的顺利履约。

五、后记

在 2022 年的淘宝双十一大促中，号码隐私保护系统全流程平稳运行，有力的支撑了淘宝隐私面单业务，为上亿订单的履约保驾护航。通过隐私通话线上布防拦截了大量诈骗通话，为消费者构建起一道防火墙。截至目前，号码隐私保护服务已经有超过 1 亿用户使用。后续阿里云云通信团队还将持续钻研，为广大消费者提供更加优质、便捷的号码隐私保护服务。