號碼隱私保護服務：保障億萬消費者的隱私安全

如何從繁雜的資料指標中精確識別出異常情況，是保障系統高可用的關鍵。

一、引言

近年來，針對電商的電信詐騙層出不窮。

不法分子藉助非法手段獲取到消費者的個人資訊，假冒電商客服人員；利用“退換貨”、“快遞丟失”、“商品質量”等藉口聯絡消費者，透過誘導消費者轉賬，開通借貸平臺賬戶等方式騙取錢財。

這類“假冒客服”能夠準確提供消費者姓名、電話、購買物品、購買日期等資訊，導致此類詐騙防不勝防。

為了保護個人資訊權益，規範個人隱私資訊的合理利用，我國在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服務請求介面的指標，包括：總請求數量、成功率、耗時等。業務指標為號碼隱私保護關鍵行為節點的引數指標，如繫結成功、選號併發數量等。這三種指標分別反饋了單機、應用、系統三個層面的潛在問題，從不同方面反映系統的執行情況。

當多維度監控出現指標異常時候，應及時告警並觸發降級逃生。但如果業務量正常起伏、系統出現抖動就頻發告警，甚至觸發降級策略，會導致系統受損，能根據監控指標異動推匯出真正系統異常是十分重要的。

為此，我們訓練出一套智慧的異常決策系統。將異常點與當時的系統指標進行對映，利用監督學習獲取異常狀態與各類指標的對映關係。匯入異常決策系統，在接受到線上實時的監控資料時，根據多維度監控指標，決策當前系統的執行情況。不同的學習函式給出自身的決策值，透過投票判斷當前系統是否處於異常節點。出現異常及時傳送告警資訊，執行相應的的降級逃生操作。新識別出的異常節點又作為訓練資料，補充到監控決策系統的訓練中，經過多輪迭代，異常狀態與各類指標的對映關係會更加科學，監控的查準率和查全率也會不斷提高。做到系統異常及時發現，系統正常抖動不誤報。實現系統異常發生快速介入，問題及時恢復，保障商品的順利履約。

五、後記