這是2024年的第30篇文章
（ 本文閱讀時間：15分鐘 ）
01
前言
時序資料庫管理系統（TSDB）近些年受到較多的關注，在性能監控場景更是起到了至關重要的作用。Khronos是阿裡目前規模最大的時序存儲引擎，由智能引擎事業部自研推出，為集團業務提供時序資料的存儲能力和實時分析能力。我們之前的技術文章對該引擎進行過系統性的介紹，感興趣的讀者可以閱讀回顧：《Khronos: 面向萬億規模時間線的性能監控引擎建設實踐》在本篇文章中，我們将着重介紹Khronos在實時索引建構優化上的實踐。
我們定義時效性延遲為使用者寫入資料到資料可被檢索到的時間gap。在TSDB中，使用者期待實時寫入的名額資料立即可見（秒級實效性），然而我們發現通用的Log-Structured Merge-Tree（LSM）架構在segment切換時，由于索引建構壓力加劇，會出現寫入實效性延遲到分鐘級别的抖動，嚴重影響使用者體驗。本文首先通過實驗分析了基于LSM架構資料實效性延遲的原因，并針對性地提出了補集索引的設計思路，即依賴前序建構好的索引，僅對之前未出現的時間線建構索引，減少索引建構開銷。第二，我們設計了基于Minimum Excluded（Mex）的索引結構高效的複用前序segment建構的索引。第三，我們利用補集索引無備援的特性，提出了查詢中間結果複用的方案避免查詢過程中索引的重複周遊。最後，我們提出索引補全政策避免過長依賴帶來的查詢和記憶體開銷。
實驗證明Khronos提出的補集索引方案大幅降低了實效性延遲，系統的最高實效性延遲從分鐘級别降低到秒級，同時和業界時序資料庫InfluxDB和TimeScaleDB相比，Khronos寫入吞吐提升至少4倍，查詢延遲降低至少6倍。補集索引的設計也被資訊檢索領域頂會之一CIKM2023接收。
論文題目：《Khronos: A Real-Time Indexing Framework for Time Series Databases on Large-Scale Performance Monitoring Systems》
論文連結：https://dl.acm.org/doi/10.1145/3583780.3614944
【文末點選閱讀原文即可跳轉哦】
02
背景知識
KMonitor是阿裡集團搜尋推薦業務廣泛使用的資料監控平台，它具有實時性、巨量metric和多名額運算性能的特點。經過多年的穩定運作和不斷優化，KMonitor 已經廣泛部署于集團電商業務的核心叢集中，并且逐漸替換成為基礎系統監控的主力。支撐KMonitor的核心是Khronos時序存儲引擎，自2020年起，為KMonitor平台提供了強有力的後端支援，滿足了業務每年呈倍數增長的需求。Khronos已經連續四年穩健應對“雙十一”期間的查詢和寫入高峰，累計存儲了超過數十PB的監控資料，同時確定了秒級的響應時延。
2.1 資料模組化
監控資料一般被模組化為多元度時間序列。圖1 (a)展示了我們的資料模組化方式，series key唯一決定一條時間線，由metric名額名和一組tags（tagk:tagv）組成。同時每條時間線還包含一組時間點序列，每個時間點由一個時間戳和多個field值組成。例如圖(a)中最後一行表示部署在機器10.10.10.5上的khronos的應用，每10s會彙報cpu各個核的使用率。tagk一般表示被監控實體的屬性和次元（例如app，tenant，host）。
2.2 查詢模式
時序資料的查詢通常包括一個名額名，一個時間區間和一組tag條件，tag條件又可分為直接比對和模糊比對。例如：
在上面的查詢中，我們期待召回時間10-35區間，khronos應用下，機器ip滿足一個正規表達式的cpu使用率。app="khronos"就是直接比對而host=Regex(xxx)即為模糊比對。
2.3 時間線索引
在Khronos中我們對每條時間線建構倒排和字首樹索引，如圖1（b)所示。每個時間線配置設定唯一的seriesId（圖1(a)的第一列）。對于反向索引，我們将seriesKey拆分成metric和tagk:tagv的token，将seriesId寫入對應的倒排清單（如圖1（b)上）。對于字首樹索引，我們将seriesKey拆分metric-tagk-tagv的token插入字首樹（如圖1（b)下）。反向索引一般用于直接比對而字首樹索引的作用是為了模糊比對和查詢下拉提示等。
2.4 寫入負載分析
- 時間局部性：性能監控場景的時序資料通常具有時間局部性，即一條時間線通常會穩定的按照某個固定的時間間隔彙報資料，例如每台實體機每10s彙報其cpu使用情況。
- Series churn問題 [1]：随着時間的推移，不斷有時間線消亡（也就是不再有新的時間點寫入），同時也不斷有新的時間線産生。這就意味着資料庫中的時間線總基數會随時間不斷增長，而活躍的時間線規模遠小于總基數，業界通常稱其為series churn。Khronos中我們發現時間線的生命周期通常小于1h（如圖2右），這通常是由于任務自動排程或者定時的短期任務導緻。
- 例如圖2左上，taskB任務首先排程在host 1.1.1.2上，彙報了紅色的三條時間線，某時刻由于負載均衡等原因taskB被排程到新的機器上host 1.1.1.5，生成了新的不同host tag的黃色時間線。而原機器上的時間線（紅色）不再彙報，變為不活躍（消亡）。Series Churn問題意味着，在一定時間T内活躍的線（活躍指的是線的生命周期與指定時間範圍T有交集）的比例遠小于資料庫中總時間線數量。
- 例如圖2左中時間60-90區間，僅有4條時間線活躍（taskB 3條黃色和taskA一條藍色），而資料庫中總線數是12條。
2.5 布局存儲
全局索引（GL）
在這種資料負載下，全局索引将會引入極大的讀放大。一方面寫入過程中需要判斷每一條消息是否是存量的時間線，如果是則不需要建構索引，如果不是則需要配置設定seriesId，建構對應的索引。而查找的效率随着全局索引的規模增大而逐漸降低。另一方面，雖然絕大部分時間線在資料庫中已經消亡，活躍的時間線集合很小，但查詢過程仍需要在全局索引中召回滿足條件的時間線，讀放大明顯 。圖3左展示了Khronos中部分租戶的時間線基數。圖3右中我們測試了基于全局索引的InfluxDB，我們發現其寫入性能和查詢效率随着資料庫中累計的時間線基數增加而逐漸下降，系統隻能支援30M的基數，完全無法滿足我們線上萬億時間線的基數規模。
時間分區的LSM索引（SL）
是以對于性能監控這種高基數場景，通常采用根據時間區間分segment的資料組織方式。寫入資料根據時間範圍劃分segment，每個segment是自解釋的，包含其對應時間區間的局部索引和時間點資料。實時寫入資料先在記憶體中建構，當segment大小或時間區間超過門檻值，會seal該segment，進行整理刷盤，同時記憶體中開啟一個新的segment接受實時寫入。
這種類LSM的設計避免了全局索引的放大，也更好的适應使用者查詢。首先最近的資料一般通路頻率更高，其駐留在記憶體，查詢性能更優。而且在查詢過程中，可根據使用者指定的時間區間通路對應的segment，避免GL中對消亡線的索引周遊。
03
Motivation
3.1 實效性延遲抖動分析
然而在SL的設計中，每個segment啟動時，segment從空開始建構，也就意味着此時每個寫入消息都會被認為是一條新線（即不在SL索引中），需要建構索引，例如圖5中
和
在
啟動時需要建構索引（雖然這兩條線已經在
中建構過索引了）。是以在segment啟動階段索引的建構壓力飙高（圖4左上所示）。而索引建構相比于資料點的寫入引入了更多的計算和記憶體通路，是以索引寫入能力更低。綜上，SL的設計在segment啟動時會導緻巨大的索引建構壓力，超過系統處理上限，進而導緻資料堆積，資料實效性受到影響（圖4左下所示）。在生産環境我們發現，這種資料實效性抖動每30分鐘觸發一次，每次持續幾分鐘，極大的影響了使用者體驗。
3.2 現有解決方案
- 加資源 [2, 3]：最直接的方式是增加更多的計算資源，但是在segment啟動時啟動更多建構線程會搶占查詢的cpu，影響實時查詢效率，同時我們測試發現索引建構開銷是寫入點資料的10-15倍，理論上需要加10-15倍的計算資源才可解決實效性延遲問題，非常浪費。
- 強schema [4-6]：業界的另一種方案[2,3]是通過強制schema限制tag和field的數量，進而控制時間線基數。然而這種方案限制了使用的靈活性，每次加入一個次元都需要更新配置，同時也增加了配置管理的難度。
- 定期清理消亡線 [7]：Prometheus采用定期起任務從實時索引中删除不活躍的線對應的索引來解決series churn問題，然而删除操作會阻塞實時資料寫入，引入了新的實效性延遲，如圖4右側。
3.3 補集索引的設計思路和挑戰
SL索引實效性問題的關鍵在于索引的備援建構：如果一條時間線的生命周期橫跨多個segment，那它會在每個segment中被重複建構索引，比如圖5中線
。我們分析資料特征可發現，由于時序資料的時間局部性，相鄰的segment間的時間線至少70%是重疊的，也就意味着對這70%的時間線我們可以儲存他們在上segment中建構索引的引用，而真正的索引建構由另外30%的新線觸發。如下圖所示。
由此在Khronos中，我們提出了補集索引（Complementary index）的概念，即僅建構不在上個segment中的時間線。每個segment的補集索引包括兩個部分（a) 在目前segment中新線建構的索引（局部索引）和(b) 對上一個segment的索引的引用（依賴索引）。例如在下圖中對于
，其補集索引包括（a)
和（b）
,
。
圖5展示了GL、SL、和補集索引的索引建構部分。和GL相比，SL根據時間劃分segment，避免了GL的讀放大問題；和SL相比，SL去除了備援索引的建構進而避免了實效性延遲的問題。補集索引結合了GL索引無備援的優勢和SL索引極低的讀放大的特點，取得了更好的tradeoff。
然而補集索引的設計也帶來了諸多挑戰：
- 索引組織：為了複用之前segment的索引内容，索引的結構需重新設計，例如seriesId的配置設定。全局seriesId很容易突破4位元組的位寬，影響存儲和壓縮效率，而segment内自編号則可能導緻反向索引複用時出現seriesId沖突。
- 查詢效率：補集索引需要從多個依賴的segment中周遊索引，有可能增加查詢延遲。
- 索引依賴：在segment間連續的索引依賴形成了一條依賴鍊，例如圖5中的索引實際隻在中建構，和隻存儲其索引的引用。是以依賴，而依賴，形成了一條長度為3的依賴鍊。如果依賴鍊無限延長，就趨近于一個GL，過長的依賴鍊會增加記憶體使用，同時也會影響查詢效率。
至此，我們已經介紹了補集索引的基本思路，即通過減少備援的索引建構降低實效性延遲，而後續的部分我們将詳細解釋補集索引的實作細節，例如索引的引用如何實作，索引如何組織來支援segment間索引的複用，查詢如何保證高效且準确，過長索引依賴如何處理等。
04
系統架構
圖6展示了我們的資料處理流程，從被監控實體采集的時序資料定期發送到Khronos，每條消息根據series key被散列到不同的partition，每個partition之間互相獨立，互不通信。在每個partition中，建構線程将實時寫入資料寫進building segment，其中點資料寫入buffer，并且為新線建構補集索引。
記憶體資料采用追加形式，支援實時查詢。一旦building segment的時間區間超過一定門檻值，系統會自動建立一個新的空segment用于接收實時寫入，而之前的segment轉化為dumping segment由異步線程進行整理、排序、去重，索引補全等操作，形成immutable segment，交由異步刷盤線程寫入遠端存儲或者本地磁盤。同時離線會定期觸發compaction任務進行資料整理，将flushed segment合并/拆分為時間區間無交集的compacted segment，減少查詢通路的segment數量。
圖7展示了我們的查詢流程。查詢首先(1)通過QRS被廣播到全部partition。每個partition中，我們隻會(2)通路與查詢時間區間有交集的segment。在segment内，查詢線程(3)周遊補集索引召回滿足條件的seriesId。然後(4)根據seriesId取線和點資料，(5)相同時間線在不同segment中的時間線段會根據時間戳進行歸并排序。(6)排序好的資料在傳回QRS進行聚合，最終傳回使用者。segment内部索引部分的查詢細節将在後續章節介紹。
05
基于Mex的索引組織
5.1 寫入流程
我們首先介紹一下Khronos的資料寫入流程（算法1），我們為每個時間線配置設定一個點資料buffer。當
從空初始建立時，我們首先判斷輸入的series key是否存在于前序
中，如果存在，我們将其在
中配置設定的seriesId作為引用存儲到seriesIdList結構中，僅将點資料p寫入buffer（算法4-6行），進而減少備援索引的建構。反之，我們會通過Mex函數計算seriesId，并實際建構索引并插入點資料（算法8-11行）。在算法1中，seriesIdList可以看作一個特殊的倒排清單，其記錄着寫入segment的全部時間線（包含上個segment的引用和實際建構索引的時間線）。
seriesIdList在查詢過程中起到了過濾不相關時間線的作用，我們在下一節詳細介紹。
5.2 seriesId的配置設定方式
為了保證查詢能準确的召回，seriesId的配置設定應該遵循以下原則：
- seriesId應該單調遞增以支援倒排清單的插入和高效的求交/求或計算。
- 對于之前已經存在的時間線，其seriesId應該和上一個segment保持一緻以複用反向索引，也就是有依賴關系的segment的倒排清單可以直接求交求或而無需轉換seriesId。
- 新的時間線配置設定的seriesId應該保證和上一個segment的seriesIdList無交集以避免沖突。
基于以上原則，最直覺的方式就是配置設定全局遞增的seriesId，然而随着資料庫中存儲時間線基數的增加，全局seriesId很容易突破4位元組位寬的限制（尤其是在khronos這種單租戶萬億基數的場景下），增加存儲成本同時也降低了壓縮效率。是以我們引入了Mex函數來計算seriesId。Mex(S)傳回集合S中最小的不在S中的整數。
例如Mex({0, 1, 3, 5}) = 2。在Khronos中，我們為每條新時間線配置設定最小的不在上一個和目前segment中的seriesId，即算法1中第8行。圖8展示了全局遞增（Max）和Mex seriesId的配置設定方式。其中方框内的字元辨別時間線，而方框豎直對應的id辨別其被配置設定的seriesId。例如
中
的seriesId被配置設定為4。圖9展示了補集反向索引的建構流程（和圖8對應）。
Mex設計的精髓在于它安全地複用了不活躍的seriesId。在圖8和9中，seriesId 2在
中被配置設定給線
，然而
的生命周期并沒有延續到
。seriesId 2在和
求交之後可以被輕易的過濾掉，是以seriesId 2對于
來說是不活躍的。基于此，對于
來說，不在
和
中的seriesId都可以安全的被複用。Mex索引的另一優勢是其通過複用seriesId減少了倒排清單内id的gap值，更利于壓縮，例如圖8中，對
，Max的
而Mex方案的
，gap值大大減小。
06
補集索引查詢流程
在本節中，我們将介紹補集索引的查詢流程，其中我們提出了中間結果複用的方案避免重複的索引周遊，保證準确的結果召回。在介紹補集索引查詢之前，我們先了解單個segment内部索引如何配合，根據使用者查詢召回滿足條件的seriesId集合，如圖10所示。
其中我們召回應用khronos，部署在特定機器上的cpu名額。(1) 我們周遊字首樹索引，得到所有tag host以10.10.12為字首的tagv；(2) 通過正則過濾器過濾出10.10.12.11和10.10.12.15兩個tagv；(3) 根據查詢指定的metric和tag條件構造一棵查詢樹，每個葉子結點對應一個倒排清單，中間節點代表and/or操作；(4) 根據查詢樹和對應的倒排清單執行求交求或操作得到滿足條件的seriesId集合{0, 2, 3, 7}。而後可根據seriesId在segment取出對應時間線的點資料進行歸并等後續操作。
對于補集索引，我們首先在每個segment的局部索引中進行上圖所示的索引周遊得到一個滿足條件的seriesId集合
。為了保證召回結果的完整，我們還需要沿着segment的依賴鍊周遊所有依賴的segment的索引。我們先從一個簡單的例子開始，假設查詢隻需要通路一個segment
，其索引隻依賴
，那麼
應召回的完整seriesId集合
可表示為：
其中
是
周遊局部索引（也就是實際建構的索引）的召回結果，流程如圖10。我們首先将
的召回結果和
求交，過濾掉不屬于
的不相關時間線，再将結果和
的局部召回結果
合并，即可得到完整準确的seriesId集合。之前提到
記錄了segment内的全部時間線，可通過與其求交過濾掉那些隻屬于前序segment的時間線。對于字首樹，由于索引複用，召回的tagv集合可能會存在false positive，但後續的倒排計算可保證最終召回seriesId集合的準确性。
接下來我們考慮複雜一點的情況，假設
依賴
，而
依賴
，那麼
的完整召回結果
可表示為：
首先和
求交，過濾掉不在
中的時間線，在這步操作後，那些不活躍的seriesId将不會向後傳遞繼續計算，是以這部分seriesId可以被安全的在
中複用。上述公式進一步證明了Mex索引的正确性。舉例來說，對于圖9，如果我們想要從
中召回token A，
需要注意，對于依賴鍊的初始segment，例如
，
。
讓我們考慮更複雜的情況，假設查詢召回多個segment的資料，也就是查詢的時間範圍和多個segment有交集。在SL索引模式下，每個segment互相獨立，相同時間線的索引會在多個segment内被重複的建構，查詢過程也會被重複的周遊，有很大浪費。反觀我們的補集索引設計中，上一個segment的召回結果
是目前segment召回結果
的一部分（參看上面公式1）。
是以在每個查詢session中，我們按照依賴順序處理segment，并将上個segment得到的中間結果緩存下來用于下一個segment查詢。通過這種方式，在每個segment中，我們僅需通路建構的局部索引，而無需重複周遊每個segment前序依賴的索引，進而避免了SL模式下重複索引的周遊。圖11展示了中間結果複用的流程。總結來說，補集索引一方面減少了建構過程中備援的索引建構，提升了資料實效性，另一方面也減少了查詢過程中重複索引的周遊，是以有明顯收益。
07
索引補全
在本節中，我們會分析索引依賴鍊帶來的額外開銷，并提出了細粒度的索引補全政策切斷較長的依賴鍊。
7.1 依賴鍊開銷
上面的章節我們都在讨論依賴鍊帶來的收益，比如去除了備援的索引建構和周遊，這些收益其實都是全局索引GL的優勢。假如依賴鍊可無限延長，那就退化回了GL版本，又會帶來之前提到的series churn負載下的讀放大問題。較長的依賴鍊将會帶來如下開銷：
- 記憶體膨脹：最新的資料會被高頻通路，同時希望保持極低的查詢延遲，是以最近資料一般會保留在記憶體中，對于補集索引，這也就意味着實時segment的所有依賴資料都需要留在記憶體中以保證查詢延遲，如果依賴鍊過長，這部分記憶體會不斷膨脹。
- 查詢遞歸開銷：在上一節的查詢流程介紹中，雖然我們減少了重複的索引通路，但是引入了額外的遞歸開銷，也就是我們由于索引依賴通路了前序segment中不屬于我們的資料。例如在圖9中當我們在中召回token A對應的seriesId集合時，和無關的seriesId 5因為索引依賴也會參與倒排計算。而依賴鍊越長，這部分額外的遞歸開銷越大。當依賴鍊無限大時，這部分遞歸開銷就等同于GL索引對消亡線索引的周遊。
是以，我們需要在特定的時候補全segment中的索引，斬斷前序依賴。
7.2 索引補全算法
在Khronos中，我們選擇在dump階段進行索引的異步補全。之是以在dump階段處理，是基于以下原因：(a）記憶體segment依賴磁盤segment的索引會引入額外的I/O開銷，增大查詢延遲；（b）持久化的segment保持自解釋的特性有助于資料的遷移的導出。
算法2介紹了我們的補全過程。我們先将series key按照metric排序。對于字首樹索引，我們按照metric粒度進行補全，當某個metric對應的資料都補全完畢，原始字首樹索引中的對應metric子樹可立即釋放，減少補全過程中的索引膨脹。而對于反向索引，我們以倒排清單為粒度補全。查詢會儲存正在通路索引的引用，避免查詢過程記憶體的釋放。
之前我們提到在查詢過程中，補集索引相比SL方案，可以減少重複的索引周遊，但同時會引入額外的遞歸開銷。在論文中我們證明了當相鄰segment間時間線的重複度超過一定門檻值，補集方案的查詢效率更高。具體細節感興趣的同學可以閱讀論文Section 7的部分。在Khronos的線上租戶中，相鄰segment的時間線重複度一般在70%-80%，去重複索引周遊的收益遠高于額外的遞歸開銷，因而補集索引查詢效率更高。
08
實驗總結
在實驗中我們比較了SL版本和補集索引版本的寫入吞吐、實效性、查詢延遲和記憶體開銷， 測試了不同寫入和查詢場景的收益；同時我們還和業界知名的開源資料庫InfluxDB[8] 和TimeScaleDB[9] 就建構和查詢性能進行測試。和開源TSDB相比，Khronos寫入吞吐提升至少4倍，實效性延遲降低近百倍，查詢效率提高至少6倍，證明了Khronos的高效性。
8.1 實效性延遲
SL方案是Khronos在補集索引方案上線前的原始版本，而CPL是補集索引方案上線後版本。圖14展示了更新前後在segment啟動期間寫入吞吐（上）和實效性延遲（下）的變化。我們可以看出，在SL方案中，當segment啟動時，由于索引建構壓力加大，實效性延遲抖動到5min，持續了近8分鐘，同時由于索引建構的開銷更大，寫入吞吐也有大幅下跌，見橙色線。而CPL補集索引方案中，在segment啟動時，實效性延遲保持在1s以下，相比SL有大幅提升，見藍色線。
2022年下半年補集索引優化上線後，雙十一實效性延遲相比2021年有幾百倍的下降（實作了分鐘到秒級的突破），大幅提升使用者體驗。
8.2 查詢效率
圖15展示了不同租戶ASI、HI（Hippo Docker）、IG（IGraph）、TPP在使用補集索引前後的查詢延遲，查詢按照時間區間分桶，注意延遲縱坐标是指數增加。圖中箭頭辨別CPL方案相比于SL方案的延遲降低比例。表3展示了不同租戶召回的時間線和點的資料規模，結合圖15和表3，我們可看出當召回上千條線，百萬個點的情況下，引擎依然可保證低于200ms的查詢延遲。具體分析補集索引的延遲收益，我們可以對比同顔色的實線和虛線。
對于絕大部分查詢，補集索引都會帶來正向的延遲收益，至多19%。我們發現對于時間範圍小于半個小時的查詢，查詢通常隻通路一到兩個segment，在這種情況下，補集索引減少重複索引周遊的優勢很難發揮，反而由于額外的遞歸依賴降低了查詢效率至多6%（見HI租戶）。而當查詢時間區間超過3個小時，大部分會通路本地磁盤或遠端存儲，是以補集索引的收益比例不那麼明顯。
引文
[01]Fabian Reinartz. 2022. Writing a Time Series Database from Scratch.
https://web.archive.org/web/20210622211933/https://fabxc.org/tsdb/
[02] Franco Solleza, AndrewCrotty, Suman Karumuri, Nesime Tatbul, and Stan Zdonik. 2022. Mach: A Pluggable Metrics Storage Engine for the Age of Observability. In Proc. CIDR.
[03] Rahul Potharaju, Terry Kim, Wentao Wu, Vidip Acharya, Steve Suh, Andrew Fogarty, Apoorve Dave, Sinduja Ramanujam, Tomas Talius, Lev Novik, and Raghu Ramakrishnan. 2020. Helios: Hyperscale Indexing for the Cloud & Edge. Proc. VLDB Endow. 13, 12 (2020), 3231–3244.
[04] Colin Adams, Luis Alonso, Benjamin Atkin, John Banning, Sumeer Bhola, Rick Buskens, Ming Chen, Xi Chen, Yoo Chung, Qin Jia, Nick Sakharov, George Talbot, Nick Taylor, and Adam Tart. 2020. Monarch: Google’s Planet-Scale In-Memory Time Series Database. Proc. VLDB Endow. 13, 12 (2020), 3181–3194.
[05] 2022. Timescale: Time-series data simplified.
https://www.timescale.com
[06] Zhiqi Wang and Zili Shao. 2022. TimeUnion: An Efficient Architecture with Unified Data Model for Timeseries Management Systems on Hybrid Cloud Storage. In Proc. SIGMOD. ACM, 1418–1432.
[07] 2022. Prometheus-Monitoring system & time series database.
https://prometheus.io
[08] 2022. InfluxDB: Open Source Time Series Database.
https://www.influxdata.com
[09] 2022. Timescale: Time-series data simplified.
https://www.timescale.com
作者:劉欣瑀(欣禹)
來源-微信公衆号:阿裡技術
出處:https://mp.weixin.qq.com/s/sdcOaN8nCntKn83pwZ46Xw