基于無服務器架構的鐵路應用開發資源共享與集成平臺設計

曹海鵬，唐偉忠，朱祎雯，湯欣宇，劉海寧

（中國鐵路蘭州局集團有限公司，蘭州 730000）

鐵路信息化歷經多年的持續建設，各專業領域信息系統已基本實現業務場景的全覆蓋，在運輸組織、調度指揮、客貨營銷、辦公綜合等多個領域發揮著突出作用。隨著信息化進入云計算時代，鐵路信息系統由第三代際向第四代際演進，對應用系統開發效率和資產復用等方面提出更高要求[1]。“十四五”鐵路網絡安全和信息化規劃中提出，要加強一體化信息平臺建設，優化集成服務平臺，構建業務和技術中臺，提升應用開發效率和管控水平[2]。

隨著面向服務架構（SOA，Service-Oriented Architecture）和微服務架構的發展，無服務器（Serverless）理念已成為云時代企業應用開發的主流發展方向[3]。無服務器架構是傳統云計算平臺的延伸，是平臺即服務（PaaS，Platform as a Service ）向更細粒度的函數即服務（FaaS，Function as a Service ）和后端即服務（BaaS，Backend as a Service ）的發展。無服務器架構將基礎設施與業務應用解耦，將軟硬件資源抽象為服務，將業務過程邏輯與表示邏輯進行分離，以松散耦合方式集成函數、第三方服務和微服務。它提供各類基礎服務，使開發人員在開發應用系統時只需關注業務邏輯實現，已成為一種基于微服務架構的企業應用研發、 部署、運維新范式[4]，促進了應用開發專業分工，有助于應用快速迭代和降低開發成本。

為提升鐵路應用開發的資源復用水平、交付能力和研發質量，本文利用平臺化、服務化、流程化的設計理念，研究提出基于無服務器架構的鐵路應用開發資源共享與集成平臺（簡稱：開發資源共享平臺）設計方案，提供統一的應用開發資源共享與集成方式，允許開發人員將應用開發資源以服務形式進行發布與集成，在共享既有鐵路應用開發成果的基礎上，快速開發新應用來滿足鐵路業務創新需求，加快鐵路數字化轉型和智能化發展。

1 設計目標

（1）建立鐵路應用開發資源公用服務庫

為鐵路企業內部及外部合作單位的開發人員提供共享服務管理平臺，方便開發人員將可復用的公用功能封裝成不同粒度的服務，包括登陸認證、日志、報表、低代碼、定時任務、數據資源、中間件等，建成鐵路應用開發資源公用服務庫；提供可視化服務編排操作界面，支持公用服務的低代碼開發；依托該公用服務庫，形成基于公用服務的鐵路業務應用開發模式，提高鐵路應用開發成果的可復用水平，減少重復開發，降低開發成本。

（2）提供安全可靠、規范高效的鐵路應用集成方法

提供簡單便捷的服務訪問和完善靈活的訪問控制，確保開發人員安全、合規、高效地訪問平臺提供的共享服務資源；支持多協議（主流的Http(s)、Web Socket、MQ、Nacos 等）、多網域（鐵路外部服務網、鐵路綜合信息網、鐵路安全生產網）的API 集成總線，提供統一的服務集成接口，實現異構信息系統資源的的互聯互通，方便開發人員完成多網域業務應用的集成、測試與上線部署。

（3）提供完善的運維支持，保障平臺及相關業務應用穩定運行

為服務提供者、服務調用者、平臺管理員提供服務資源調用日志查詢、服務使用監控、服務異常預警等運維支持，幫助相關人員及時發現和快速處置平臺及相關應用系統運行中出現的各類異常，確保納入平臺管理的所有服務、平臺自身以及基于該平臺開發的相關業務應用能夠穩定運行。

2 架構設計

開發資源共享平臺基于無服務器架構，通過建立鐵路應用開發資源公用服務庫，實現鐵路應用開發可復用共性服務的集中規范管理；依托公用服務庫，以API 網關作為應用集成總線，為開發人員提供基于服務共享與集成的鐵路應用開發新模式。在該平臺支持下，開發人員既可作為服務提供者將其應用開發成果發布為可共享的服務，也可作為服務調用者來使用公用服務完成應用集成開發。該平臺架構設計如圖1 所示。

圖1 開發資源共享平臺架構示意

（1）基礎設施層：提供平臺運行的網絡資源池、存儲資源池、服務器資源池，實現資源動態配置，提高資源利用率。

（2）存儲層：采用Oracle、Redis、MinIO、MongoDB 等多種數據庫存儲數據。其中，Oracle 主要用于存儲服務發布記錄、服務申請記錄等數據；Redis 用于緩存API 網關動態路由、網關閾值等需要實時更新和快速訪問的數據；MinIO 主要用于存儲服務使用文檔；MongoDB 用于存儲服務調用請求日志、服務調用鏈路記錄、服務編排操作記錄等數據。

（3）應用層：實現共享服務的發布、調用、集成、監控、評價全流程管理。提供服務管理功能，方便開發人員按規范發布共享服務資源；提供服務調用申請、接口路由配置、接口協議轉換、接口緩存等集成開發功能，方便開發人員利用共享服務資源快速開發應用；通過流量控制、合法請求認證、傳輸安全控制等服務訪問控制，支持高并發服務調用；提供API 網關監控、日志查詢、數據庫性能監控等運維工具及異常處置功能，保證平臺穩定性和高可用性。

（4）接口層：包括API 網關和統一門戶。API網關基于Nginx 和SpringGateWay 構建，為服務集成提供路由選擇、數據轉發和協議轉換；統一門戶為平臺用戶提供統一身份認證與權限管理。

（5）用戶層：基于Vue3 實現Web 端用戶界面，提供授權的服務管理、服務集成配置操作頁面，以及可視化監控頁面。

3 功能設計

開發資源共享平臺（以下簡稱平臺）實現服務發布、申請、審核、集成、監控、預警全流程管控，建立鐵路應用開發資源公用服務庫，支持開發人員安全、高效、可靠地共享與集成應用開發資源。該平臺功能層次結構如圖2 所示。

圖2 開發資源共享平臺功能層次結構

平臺用戶主要包括服務提供者、服務調用者、平臺管理員3 類。面向服務提供者，提供服務發布、服務編排、服務清單、服務調用監控等功能；面向服務調用者，提供服務申請、接口緩存、日志查詢等功能；面向平臺管理員，提供API 網關管理、異常預警、異常監控等功能。

3.1 服務管理

服務提供者通過填寫既有服務基本信息或者服務編排功能發布服務，待平臺管理員通過發布申請后，展示在服務清單中。

3.1.1 服務發布

服務提供者整理既有開發成果的相關資料，按要求填寫服務發布申請，平臺支持多種接口協議類型的服務。

（1）服務發布申請：服務提供者整理既有開發成果的相關資料，按要求填寫服務發布申請，包括服務地址、服務接口協議類型（可選擇Socket、Http(s)、MQ 或Nacos 微服務）等。

（2）服務變更申請：當服務地址、配置服務緩存或日志存儲有效期等信息發生變化時，服務提供者向平臺管理員發起變更申請。

（3）服務發布/變更審核：平臺管理員對服務提供者提交的服務發布申請或服務變更申請進行細致審核，符合要求的申請被批準后，對應的服務會被列入服務清單；對于被拒絕的申請，會返回審核意見。

3.1.2 服務編排

服務提供者通過對已發布的服務進行可視化組裝，將多個服務組合成更大粒度的新服務，并對新服務進行測試，經測試驗證合格的新服務按照服務發布申請與審核流程發布為新的服務。

（1）服務組裝：平臺提供可視化操作界面，服務提供者通過拖、拉、拽操作即可對已發布服務進行組裝和編排，定義和調整各服務的數據處理邏輯、相互間依賴關系及調用順序，實現邏輯更復雜、顆粒度更大的新業務服務，以快速響應業務需求。

（2）服務測試：服務提供者完成所編排新服務的測試，包括模擬用戶操作、異常測試、邊界條件測試等，還能對封裝在服務中的各個組件或功能項點進行獨立測試，檢查它們是否符合設計要求。

3.1.3 服務清單

按照服務性質，將服務劃分為應用服務和數據服務2 類。應用服務側重于數據計算和邏輯處理；數據服務側重于數據的采集與存儲。

（1）服務排名：以服務評分、穩定性指標、被調用次數的加權和作為評分值，按評分值由高到低顯示平臺上發布的所有服務排名列表。其中，服務評分是服務提供者對已申請服務的平均評分；穩定性指標主要依據服務發生異常的次數；被調用次數是指該服務在最近 3 個月內被調用的總次數。

（2）服務詳情：用戶可查看服務相關詳細信息，包括服務簡介、服務調用情況、日均被調用次數、故障率、服務使用說明等。

3.2 集成開發

服務調用者通過提交服務調用申請來訪問平臺管理的公用服務庫，平臺提供路由匹配、協議轉換以及服務緩存等功能，完成合法調用請求的正確轉發。

3.2.1 服務調用申請

服務調用者根據業務開發需求提出服務調用申請，待平臺管理員審批通過之后，平臺自動生成唯一標識符返回給服務調用者。

（1）調用申請：服務調用者選中要調用的服務，設置自己用于調用服務的IP 地址，并按需選擇數據加密算法，然后發起調用申請。IP 地址支持單個IP、連續IP 段和整個IP 網段，加密算法可以是對稱加密算法或非對稱加密算法。

（2）服務標識：服務調用申請通過平臺管理員的審批后，平臺會自動為其生成一個唯一的統一資源定位符（URL，Uniform Resource Locator）與密鑰標識符，供服務調用者合法使用。

3.2.2 接口路由配置

平臺根據用戶操作記錄，自動實時更新API 網關的路由謂詞，將服務調用請求正確轉發。

（1）路由謂詞動態生成：平臺從持久層加載服務發布記錄和服務申請記錄，解析后生成路由謂詞（包含路由斷言和路由攔截器），并每隔30 s 更新一次，使路由謂詞處于最新狀態。

（2）請求轉發處理：當請求到達時，平臺根據路由斷言的請求匹配機制判斷路是否正確，并經過多級過濾處理后，轉發至相應服務。

3.2.3 接口協議轉換

平臺允許服務提供者通過多種主流接口協議（Http(s)、MQ、Socket 等）發布服務，而服務調用者則統一采用標準接口協議調用服務，由平臺完成接口協議的無縫轉換，實現接口協議規范化[5]。

（1）標準協議轉換：平臺根據服務提供者選擇的服務類型，將相應類型的接口協議與Http(s)進行轉換。

（2）數據轉換：每一種協議類型都有自身的數據格式，平臺將Http(s) 協議的JSON 數據轉換和映射為其它協議類型相應的數據格式和結構。

3.2.4 接口緩存

對于計算復雜、響應時間長、響應結果變化頻率較低的服務，平臺提供了公用接口緩存機制。在高并發服務調用場景下，接口緩存有助于縮短服務調用請求的響應時間，減輕目標服務并發壓力，使服務提供者專注于業務邏輯，而無需考慮并發性能需求[6]。

（1）接口緩存創建：利用分布式緩存技術，平臺以請求路由和請求參數的哈希值作為鍵值，以目標服務的響應結果作為哈希表記錄，創建具有預定義有效時間（緩存有效時間由服務提供者在發布服務時設置）的接口緩存。

（2）接口緩存使用：當服務調用者首次調用某個設置有接口緩存的服務時，從目標服務獲取響應結果后，在將響應結果返回給服務調用者的同時，會將響應結果寫入公用接口緩存中，供其他訪問該服務的服務調用者讀取。當其他服務調用者調用該服務時，若對應的接口緩存中保存著處于有效期內的響應結果，直接從接口緩存中讀取并返回給服務請求者，而無需將服務調用請求轉發給目標服務。

3.3 服務訪問控制

API 網關作為服務調用者和目標服務之間的一個中間層，提供了統一、安全、可管理的 API 訪問接口。通過流量控制，使API 網關能夠平穩應對高并發訪問，并結合合法請求認證與傳輸安全控制，保證眾多的服務調用者能夠平穩、合規、安全地使用公用服務庫。

3.3.1 流量控制

API 網關利用集群部署技術實現負載均衡，支持高并發服務調用請求；在出現突發的請求高峰時，服務調用請求可按需均衡、平穩轉發，保證平臺穩定運行。

（1）API 網關閾值調整：當承載API 網關的虛擬機資源發生變化或新增部署AIP 網關時，平臺管理員依據虛擬機的帶寬與計算能力的容量，及時調整API 網關的權重、最大每秒查詢率閾值（QPS，Queries Per Second ）和最大并發線程數等閾值。

（2）流量監測與限流：平臺監測API 網關的QPS、并發線程數和請求速率，當調用請求超過API網關閾值時，該API 網關自動降低權重，并進入限流模式，避免網絡擁堵，保護平臺免受惡意或高負載請求的影響。

3.3.2 合法請求認證

平臺根據請求源IP 黑白名單 ，確保服務調用請求的合法性，防范API 網關可能面臨的注入攻擊、掃描攻擊、篡改攻擊等風險[7]。

（1）合法請求識別：平臺解析服務調用請求報文中包含的服務請求來源IP、User-Agent、請求參數等請求頭信息，以服務調用者申請時提交的服務調用IP 地址，作為該唯一接口的白名單，來判斷服務請求是否合法。

（2）異常請求禁止：平臺判斷服務調用請求的接口路由是否為本平臺發出的可用接口，并自動識別爬蟲、SQL 注入、盜鏈攻擊、高頻惡意請求等非法請求，將識別出的非法服務調用請求IP 加入黑名單，禁止來自該IP 的服務訪問請求。

3.3.3 傳輸安全控制

針對數據傳輸的安全問題，平臺提供統一的數據加密、脫敏、植入水印、壓縮等處理機制，防止數據在傳輸過程中被惡意截獲或篡改，保證服務調用請求的完整性、機密性、不可抵賴性，避免服務請求被不合規的二次流轉，并實現服務調用請求版權宣誓。

（1）加密：使用特定算法對請求參數與響應結果進行加密，將其轉換為一段不易被識別或不可讀的代碼（即“密文”），以避免數據泄露、被篡改或濫用。

（2）脫敏：通過應用替換、重排等規則，對響應結果中的敏感數據進行隱藏，有效保護隱私數據。

（3）植入水印：以不可見或難以察覺的方式，在響應數據中加入特殊標識，在數據被傳輸、使用或共享時，追蹤數據的來源和版權信息。

（4）壓縮：在返回響應結果前采用數據壓縮技術，消除數據冗余，減少傳輸位數，降低數據容量及存儲成本，提高數據傳輸效率。

3.4 運行監控

面向所有平臺用戶，提供授權的平臺運行監控功能，主要包括API 網關監控、日志管理、數據庫性能監控，為平臺運維提供有力支持，保障平臺及相關業務應用平穩運行[8]。

3.4.1 API 網關監控

監控API 網關運行動態，及時發現異常并預警，確保服務調用請求能夠順利通過API 網關。

（1）實時監控圖：動態計算部署API 網關的虛擬機的內存使用變化率、存活線程變化、CPU 使用變化率3 項監控指標，自動生成 API 網關虛擬機的監控指標趨勢圖，幫助平臺管理員優化虛擬機資源和API 網關配置。

（2）異常預警：平臺監測API 網關監控指標，一旦發現異常情況，立即通過短信向相關人員發送預警信息。

3.4.2 日志查詢

平臺采集服務調用相關信息，并持久化存儲服務調用日志，為用戶提供授權的日志檢索與查詢功能，便于服務異常排查和風險朔源。

（1）日志記錄：在不影響服務調用過程的前提下，平臺以異步方式持久化記錄服務調用日志；根據服務提供者設置的日志存儲有效期，定期刪除過期日志。

（2）日志查詢：服務提供者可查詢自己所發布服務的調用日志，服務調用者只能查看本人調用服務的日志。提供多種快捷的日志檢索與查看功能，日志內容包括服務名稱、調用系統、調用服務來源服務IP、發生時間段等信息。

3.4.3 數據庫性能監控

平臺動態計算SQL 執行性能指標，并生成可視化的數據庫性能圖表，幫助平臺管理員發現平臺數據庫異常和性能劣化跡象，快速定位性能瓶頸，并開展性能調優，保證數據庫穩定、高效運行。

（1）指標計算：根據已執行SQL 的SQL 命令內容、SQL 行數、執行時間、更新行數、并發量信息，定時統計最大執行時間、最大并發量、錯誤執行數等SQL 執行性能指標。

（2）性能圖表：平臺基于SQL 執行性能指標，生成可視化的數據庫性能監控圖表，幫助平臺管理員分析數據庫性能狀況，指導數據庫調優和評估性能調優方案的效果。例如，通過分析慢SQL 趨勢，可以為數據庫擴容與索引優化提供依據。

3.5 異常處置

針對各服務可能出現的異常情況，平臺監測服務調用過程，提供服務異常檢測、異常處置、異常通知等功能，實現服務異常快速捕捉處理，確保平臺平穩運行。

3.5.1 異常檢測

平臺通過監測服務異常度量指標，及時發現服務異常，并進一步分析判斷異常類型。

（1）服務異常檢測：采用服務平均響應時間、單位時間內異常比例、單位時間內異常數3 個指標來衡量服務穩定性，平臺動態計算服務異常度量指標，據此判斷服務是否出現異常情況。

（2）異常類型判斷：當平臺檢測到異常時，會根據自身與目標服務建立連接的所花費時間、服務響應時間及服務響應結果，自動分析和判斷服務發生異常的原因，如服務宕機、服務負載過高、服務下線（即服務進程處于激活狀態，但卻不可用）、服務處理過程異常。

3.5.2 異常處置

當平臺檢測到某個服務出現異常時，根據服務異常類型，自動進行熔斷或降級運行。

（1）服務熔斷：當某個服務下線或在處理過程出現異常時，該服務被開啟熔斷；一個服務被熔斷后，調用該服務的請求不再被轉發給該服務，而是由平臺直接調用fallback 方法來返回異常響應。

（2）服務降級：當被調用服務的負載過高時，該服務被開啟半熔斷，僅允許少量請求被轉發給該服務；根據服務調用請求執行的實際情況，決定使該服務恢復正常 ，或繼續保持半熔斷狀態。

3.5.3 異常通知

當平臺檢測到異常時，立即通知相關人員，提醒其快速排查和處置異常。

（1）通知格式定義：平臺管理員根據異常分類，設置預定義的異常類型，定義異常類型對應的通知格式，并指定接收通知的相關人員。

（2）異常通知發送：當平臺檢測到異常時，根據異常類型和預定義的通知格式，自動生成異常通知，以短信形式發送給相關人員（服務提供者、服務調用者或平臺管理員），提醒其關注異常事件。

4 關鍵技術

4.1 API 網關

API 網關是實現服務共享與集成的關鍵，負責服務的請求轉發、監控預警、協議轉換、安全控制、異常響應、監控日志采集、服務緩存等。所有服務調用請求都要先經過API 網關，由其根據路由謂詞將請求轉發至相應的服務。此外，API 網關還需要采取安全保障措施來提供平臺內外的安全隔離，以拒絕外部惡意訪問，避免身份和信息的泄露[9]。

Nginx 是一種開源的反向代理服務器與負載均衡器，具有高并發性、穩定性和安全性；SpringGateWay是構建微服務應用的重要組件，利用異步非阻塞編程模型來處理高并發請求。本文基于Nginx 和SpringGateWay，設計了具備高并發訪問負載均衡能力的API 網關，API 網關多級過濾處理過程如圖3 所示。

圖3 API 網關多級過濾處理機制示意

（1）Nginx 將高并發服務調用請求均衡地分配給SpringGateWay 集群進行處理，以提高API 網關的數據處理能力和可用性。

（2）基于SpringGateWay，建立流量控制、異常請求禁止、合法請求識別、異常響應等多級斷言，用于服務調用請求的合法性檢測和鑒權。

（3）在轉發服務調用請求或響應結果之前，多級過濾器依次對請求參數或響應結果進行加密、壓縮、植入數據水印、脫敏、監控日志采集，實現服務調用過程的安全防護和運行監控。

（4）在轉發服務調用請求或響應結果之前，完成Http 與其它類型接口協議的轉換。

4.2 服務調用請求全鏈路追蹤

服務調用全鏈路是指從源端用戶發起服務調用到最終獲取響應結果的過程中，服務調用請求經過的所有處理環節及涉及的相關組件。在云計算時代，應用中包含的組件類型不斷增多，組件間調用關系較為復雜，服務調用全鏈路的可視化跟蹤分析有助于增強故障檢測與定位能力[10]。平臺通過分析服務調用請求日志，追溯服務調用請求全鏈路，并據此自動構建服務調用全景圖，完整揭示服務間調用關系、每個服務被調用的頻率和每次調用的執行內容等。服務調用全景圖可用于指導性能調優和發現業務系統間依賴關系，為異常處置和故障分析提供參考。平臺使用監控日志過濾與鏈路關聯技術，實現服務調用請求全鏈路追蹤，具體流程如圖4 所示。

圖4 服務調用請求全鏈路監控流程示意

（1）監控日志過濾器從API 網關抓取日志數據，并按統一命名規則為服務調用請求所經過的所有結點命名：API 網關中各個SpringGateWay 以其運行的IP 地址和端口作為標識，目標服務以其發布服務記錄時生成的唯一標識ID 命名，源服務以其申請處理記錄時生成的唯一標識ID 命名。

（2）監控日志過濾器將抓取的日志數據放入RocketMQ 隊列中， 供監控日志記錄進程從RocketMQ 隊列讀取，實現了兩者之間通過異步方式傳輸日志數據。

（3）監控日志記錄進程將服務調用日志以異步方式持久化，并按服務調用請求的日期將服務調用鏈路記錄表劃分為多個子集，以分區形式存儲在MongoDB 數據庫中，以提高查詢性能，便于快速生成服務調用鏈路和服務調用全景圖。

（4）鏈路關聯進程從MongoDB 數據庫讀取服務調用日志記錄，利用節點的標識信息，分析節點間調用關系，將服務間調用依賴關系動態關聯起來，生成服務調用鏈路記錄表（包括請求源、請求時間、響應結果等信息）。

（5）可視化監控頁面從MongoDB 數據庫讀取服務調用鏈路記錄表，并基于完整服務調用鏈路快速顯示服務調用全景圖。

（6）根據服務發布者維護的被調用服務日志存儲有效期，創建日志清理任務，由開源定時任務調度中心XXL-JOB 定時觸發該任務，自動完成過期日志的清理，保證日志查詢效率。

4.3 API 網關可視化監控

完善的運行監控與報警功能是保證服務穩定運行的基礎[11]，也是平臺運維的利器。平臺為用戶提供簡單、直觀的監控與預警信息展示，自動生成性能指標監控圖表，方便平臺管理員、服務提供者、服務調用者監視API 網關的健康狀態及服務使用情況，隨時掌握系統運行狀態，快速響應異常情況。

Prometheus 是一種開源的服務監控系統和時序數據庫，提供了快捷數據采集、存儲和查詢功能；Grafana 是一款開源的度量工具和可視化套件，支持多種數據源以及豐富的插件庫，常用于系統數據分析和監控。基于Prometheus 和Grafana，設計可視化監控API 網關，如圖5 所示。

圖5 API 網關可視化監控

（1）開啟API 網關的Actuator 功能，使其主動暴露與API 網關運行有關的度量指標數據。

（2）在Prometheus 服務器（Server）中配置好需要監控的API 網關的IP 地址和端口號，利用服務發現機制檢測已上線的API 網關，并通過Pull 方式拉取運行度量指標數據。

（3）在可視化監控頁面中使用Grafana 創建儀表盤，選擇查詢Prometheus 數據源中運行度量指標數據，設置自定義圖標顯示方式和樣式，實現 API網關虛擬機及服務調用請求可視化監控圖表。

（4）在Grafana 中配置好預警規則，當單位時間內服務接口異常、請求時長、并發數等超過一定閾值時，通過短信提醒服務提供者予以關注。

5 結束語

為適應云計算時代的發展要求，本文設計了基于無服務架構的鐵路應用開發資源共享與集成平臺；在建立鐵路應用開發資源公用服務庫的基礎上，以API 網關作為應用集成總線，為開發人員提供了一種基于服務共享與集成的鐵路應用開發新模式。該平臺通過流量控制、合法請求認證、傳輸安全控制等服務訪問控制，支持高并發服務調用；提供API 網關監控、日志查詢、數據庫性能監控等運維工具及異常處置機制，有效保證平臺的穩定性和高可用性。該平臺的應用將有助于提升鐵路應用開發的資源復用水平、交付能力和研發質量。

目前，該平臺僅可支持服務調用者向服務提供者主動請求獲取響應結果的單向通信，尚未實現服務提供者與服務調用者的雙向通信模式。后續將研究雙向通信的服務集成模式，擴大平臺的適用范圍。此外，為進一步增強該平臺應對單點瓶頸和網絡安全風險的能力，將繼續深化平臺安全防護、API 網關集群部署、系統運維保障技術研究，不斷提高平臺的安全性和可靠性。