目錄

醫療行業：智能診療的加速引擎

?電商領域：數據依賴的破局之道

?金融行業：運維可觀測性的提升之路

物流行業：智慧物流的創新架構

綜合業務：服務依賴的優化策略

---

醫療行業：智能診療的加速引擎

在醫療行業邁向智能化的進程中，NVIDIA 推出的面向醫療應用場景的系列微服務（NIM）堪稱一大創舉。它融合醫學影像分析、自然語言處理等尖端 AI 技術，在藥物研發、醫學影像解讀、基因組學分析等多個醫療核心工作流中發揮著關鍵作用，實現從篩查、診斷到治療全程的智能化輔助 。

在藥物研發環節，時間就是生命，每縮短一秒研發周期，都可能為無數患者帶來生的希望。NVIDIA 的微服務套件中包含生成式化學模型 MolMIM、蛋白質結構預測模型 ESMFold 以及幫助研究人員了解藥物分子如何與靶點相互作用的模型 DiffDock 等。這些模型就像一個個不知疲倦的科研助手，通過對數以萬億計的藥物化合物進行快速篩選與分析，能夠精準地預測藥物的活性和潛在副作用，極大地加速了新藥的研發進程。過去，研發一款新藥可能需要耗費十幾年甚至幾十年的時間，而現在借助這些微服務，研發周期有望大幅縮短，讓更多救命良藥能夠更快地推向市場。

醫學影像解讀一直是醫療診斷中的重要環節，但傳統的人工解讀不僅效率低，還容易受到醫生主觀因素和疲勞等影響。NVIDIA 的醫療微服務憑借卓越的圖像識別能力，能夠在腫瘤診療等階段實現精細到微觀層面的病變識別。通過對 X 光、CT、MRI 等醫學影像的深入分析，它可以敏銳地捕獲其中的微妙變化，比如極其微小的腫瘤病灶，為醫生提供更詳盡精確的病理分析參考，讓疾病無處遁形，大大提高了診斷的準確性和及時性。

基因組學分析對于了解疾病的遺傳機制、實現個性化醫療至關重要。NVIDIA 的 Universal DeepVariant 微服務相較于在 CPU 上運行的普通 DeepVariant，可將基因組分析工作流中的變體識別速度提高 50 倍以上。這使得科研人員能夠更快速地分析患者的基因數據，找出與疾病相關的基因變異，為精準醫療提供有力支持。例如，在癌癥治療中，通過對患者腫瘤基因的分析，醫生可以制定出更具針對性的治療方案，提高治療效果，減少不必要的治療副作用。

?電商領域：數據依賴的破局之道

?

在電商的供應鏈系統里，商品、訂單、采購這三個微服務緊密關聯，牽一發而動全身。在設計這個系統時，需要滿足兩個關鍵需求：一是能夠根據商品的型號、分類、生成年份、編碼等信息查找訂單；二是可以依據同樣的商品信息查找采購訂單 。

起初，按照嚴格的微服務劃分原則，商品相關的職責被存放在商品系統中。在查詢訂單與采購單時，如果查詢字段包含商品字段，就得按照特定順序進行查詢：先根據商品字段調用商品的服務，返回匹配的商品信息；接著在訂單或采購單中，通過 IN 語句匹配商品 ID，再關聯查詢對應的單據。但隨著業務的迅猛發展，商品數量呈爆發式增長，匹配的商品越來越多，訂單服務中包含 IN 語句的查詢效率急劇下降。商品服務作為核心服務，依賴它的服務與日俱增，商品數據量的不斷膨脹讓其不堪重負，響應速度越來越慢，甚至頻繁出現請求超時的情況。由于商品服務超時，相關服務處理請求也經常失敗，業務方每次查詢訂單或采購單時，只要帶上商品關鍵字，就會遭遇查詢效率低下且頻繁失敗的問題。

為了解決這些問題，數據冗余方案應運而生。簡單來說，就是在訂單、采購單中保存一些商品字段信息。這樣一來，每次查詢時就可以不再依賴商品服務。但新的問題又出現了，如果商品進行了更新，如何同步冗余的數據呢？最初設想了兩種辦法，第一種是每次更新商品時，先調用訂單與采購服務，再更新商品的冗余數據。但這種方式存在嚴重的數據一致性問題，如果訂單與采購的冗余數據更新失敗，整個操作都需要回滾，這顯然不合理，因為冗余數據并非商品服務的核心需求，不能因邊緣流程影響核心流程。同時，還會導致嚴重的依賴問題，商品服務本應專注于商品本身，卻因這種方式需要調用眾多其他服務，與作為底層核心服務的初衷背道而馳 。

于是，第二種通過消息發布訂閱的方案被采用。每次更新商品時，先發布一條消息，訂單與采購服務各自訂閱這條消息后，再各自更新商品冗余數據。這種方式讓商品無須調用其他服務，只需關注自身邏輯，即便訂單、采購等服務的更新冗余數據失敗，也可使用消息重試機制保證數據的一致性。然而，這個看似完美的方案也存在缺陷。在實際業務中，僅僅保存冗余數據遠遠不夠，還需要將商品分類與生產批號的清單進行關聯查詢。這意味著每個服務不僅要訂閱商品變更消息，還需訂閱商品分類、商品生產批號變更等近十種消息，幾乎要把商品的一小半邏輯復制過來。而且，每個依賴的服務都需要重復實現冗余數據更新同步的邏輯，導致大量重復代碼。此外，MQ 消息類型過多，聯調時 MQ 之間的聯動極為麻煩，常常不知道某條消息被哪臺服務節點消費，為了讓特定服務器消費特定消息，需要臨時改動雙方代碼，且聯調完成后還容易忘記改回原代碼 。

為了徹底解決這些問題，最終采用了解耦業務邏輯的數據同步方案。將商品及商品相關的一些表，如分類表、生產批號表、保修類型、包換類型等，實時同步到需要依賴和使用它們的服務的數據庫，并且保持表結構不變。在查詢采購、訂單等服務中的數據時，直接關聯同步過來的商品相關表，同時嚴禁采購、訂單等服務修改商品相關表。為了實現這一方案，項目組經過多方調研，選用了 Bifrost 這款開源中間件。Bifrost 能夠模擬成 MySQL 的從庫，監聽源數據庫的 Binlog，然后將數據實時同步到目標數據庫，且支持多種目標數據庫，正好滿足從 MySQL 同步到 MySQL 的需求。它界面管理方便，架構簡單，出現問題易于調查，作者更新活躍且自帶監控報警功能 。

通過這一系列的優化，商品服務的開發人員可以專注于自身業務邏輯，無需再為數據依賴問題煩惱。需要關聯使用商品數據的采購服務等，開發人員也只需在查詢時加上關聯語句，極大地提高了系統的穩定性和查詢效率，為電商業務的高效運轉提供了堅實保障。

?金融行業：運維可觀測性的提升之路

在金融行業全力推進數字化轉型的浪潮下，業務的快速發展帶來了日志類型和數量的爆發式增長 。各類軟硬件產生的日志數據不僅分散在各個角落，而且繁雜無序，缺乏統一的全生命周期管理以及高效的監控分析處理能力，這給業務監控告警、日志搜索分析和審計溯源等工作帶來了極大的阻礙。同時，隨著云原生環境中微服務化進程的不斷加速，業務系統的微服務化改造雖然帶來了諸多優勢，但也在運維排障方面豎起了一道道復雜的屏障。

某金融客戶在面對這些挑戰時，深刻認識到提升運維可觀測性的緊迫性和重要性。為了實現云原生可觀測性建設這一核心目標，該客戶采取了一系列行之有效的措施。

首先是完善管理制度規范。技術平臺是為管理服務的，要搭建好技術平臺，就必須先梳理和完善管理規范制度。該金融客戶與合作方一起，對現有的客戶規范以及業內規范展開了全面深入的調研。他們仔細梳理每一個條目，精心總結日志管理規范，并對其能力應用進行了前瞻性的規劃。以業務日志的規范化為例，他們進行了 4 層豐富度的詳細說明，針對不同級別明確了不同的規范度、可實現的效果以及能達到的能力級別。通過這樣細致的規范梳理，能夠更準確地評估客戶現有不同業務系統及其日志的規范化程度，進而根據客戶數字化推進的階段，合理反推不同業務系統下一步的管理要求 。

其次是建設統一日志平臺。管理制度的規范化是實現數字化轉型的 “道”，而具體的實現則需要 “術” 的支持，這里的 “術” 就是基于擎創的日志管理平臺作為基礎底座，構建以可觀測性提升為核心的統一日志平臺。該平臺架構主要分為 4 層，最底層是數據源層及接入層，將日志數據、監控數據、調用鏈數據等都歸為數據源，并針對不同的數據源，運用 agent、syslog、API 等不同的采集技術進行全面納管。在數據處理層，采用數據中臺進行數據緩沖、計算和存儲，把原始的基礎數據通過規范化、清洗、聚合計算、數據關聯等一系列操作，實現從數據到業務運行狀態觀測的關鍵轉變。在應用層，通過前端提供直觀、高效的交互界面，讓運維使用方能夠輕松操作；在后端及中間件層，則對運行狀態觀測數據進行緩沖高效查詢及部分業務邏輯處理 。

最后是整合觀測數據。數據源的豐富度和質量直接決定了可觀測性的挖掘深度。在現有的環境中，該金融客戶接入了操作系統、數據庫、中間件、硬件設備、容器及應用等各類日志及監控數據。在鏈路層，通過 skywalking 接入了多套業務系統的鏈路數據，同時在日志中，根據客戶規范增加了對應的 TID 標示，用于實現日志及鏈路數據的深度融合。

通過這一系列的舉措，該金融客戶在運維可觀測性提升方面取得了顯著的成效。實現了業務日志的統一查詢，能夠全局性覆蓋主要業務系統，快速高效地查詢日志，并通過對部分日志的合并、解析和分析，實現了日志的更高效利用。在此基礎上，還開發了如二次查詢、全鏈路排障、數據湖冷備數據查詢、上下文行數自動滾動、日志內 xml/json 段格式化、用戶使用統計分析等貼合實際生產環境的功能。能夠密切關注業務系統運行狀態及告警，從日志角度對業務系統進行統計分析，快速了解系統的整體概覽狀態。實現了業務日志全鏈路串聯，打通統一日志系統與 Skywalking 的數據，通過中間層處理，用 TID 在日志及 Skywalking 中做上下文關聯，通過全局流水號、業務流水號或任意內容搜索，就能獲取業務系統詳細日志及鏈路信息，實現了排障一體化解決，同時還能直觀方便地了解業務系統中業務拓撲及單筆交易的鏈路拓撲，為排障提供了極大的便利 。整合了監控內容，減少了運維場景下在不同平臺之間的跳轉，大大提升了運維效率。對接原有數據湖，實現數據雙寫，一份用于日常查詢排障，存儲容量限制后定期滾動刪除；另一份存儲于數據湖內長期保存，用于審計場景，并且實現了冷備數據的在線查詢，以及更高的壓縮率和接近熱數據查詢的查詢速度。

物流行業：智慧物流的創新架構

?

在物流行業的數字化變革浪潮中，高達智慧物流中臺系統憑借其創新的微服務架構，成為推動行業發展的重要力量 。該系統主要為自建物流公司或整合物流公司精心設計，致力于解決傳統物流模式中效率低下、成本高昂等難題。

在功能板塊上，它涵蓋了合同管理、運單管理、智能調度等多個關鍵領域，并全面支持北斗定位以及物流貨主、承運商、司機之間的在線協同。以合同管理為例，傳統的物流合同管理往往依賴人工操作，不僅效率低下，而且容易出現合同條款遺漏、審批流程繁瑣等問題。而在高達智慧物流中臺系統中，合同管理實現了數字化和自動化。從合同的起草、審批到簽訂，每一個環節都在系統中清晰呈現，大大縮短了合同處理周期，降低了人為錯誤的風險 。

運單管理同樣實現了質的飛躍。在傳統物流模式下，運單信息分散在各個環節，查詢和跟蹤極為不便。而該系統通過統一的運單管理平臺，實現了運單信息的實時共享和全程跟蹤。無論是貨主、承運商還是司機，都可以通過移動端隨時查詢運單的最新狀態，如貨物的位置、預計送達時間等，真正做到了信息透明化 。

智能調度是該系統的核心亮點之一。在實際物流運輸中，車輛的調度和分配是一個復雜的問題，涉及到貨物的重量、體積、運輸路線、車輛的載重和續航能力等多個因素。傳統的調度方式往往依賴人工經驗，難以實現最優的資源配置。高達智慧物流中臺系統的智能調度策略系統則通過對承運商的各項指標參數，如運輸任務響應效率、派車及時率、運輸破損率、回單及時率、客戶滿意度等進行綜合評定打分，基于評定結果自動推薦承運商及自有車輛資源完成派單。這種智能化的調度方式不僅提高了運輸效率，還降低了運輸成本 。

在運輸鏈精細化管理方面，該系統通過合同管理、計劃管理、調度管理、財務管理、司機端貨主端協同等多個環節的緊密配合，實現了運輸鏈的全方位優化。例如，在財務管理方面，系統能夠自動生成運費結算清單，根據不同的計費規則，如按月、按重量、按時間、按次數等進行費用統計，大大提高了財務結算的效率和準確性 。

在實際應用中，該系統的優勢得到了充分體現。某大型物流企業在引入高達智慧物流中臺系統后，通過智能調度實現了車輛利用率提高 30%，運輸成本降低 20%。同時，通過實時定位和軌跡跟蹤功能，貨物的準時送達率從原來的 80% 提升到了 95% 以上，客戶滿意度大幅提升 。

綜合業務：服務依賴的優化策略

?

在一個包含商品、訂單、加盟商、門店（運營）、工單（門店）等多個服務的綜合業務系統中，存在著復雜的服務依賴關系 。該系統有兩個 App，一個面向客戶，另一個供公司員工和加盟商員工使用，涉及總部商品管理、總部門店管理、加盟商員工、門店人員等多種角色，且每個部門內部還有更細致的角色劃分 。

在這樣的架構下，網關層承擔著路由、認證、監控和限流熔斷等重要職責。它負責將所有請求根據 URI 指向對應的后臺服務，對請求進行集中認證鑒權，記錄 API 請求數據以進行管理和性能監控，以及在流量過大或后臺服務出現問題時進行限流和熔斷操作 。

然而，隨著業務的不斷發展，這個看似完美的架構逐漸暴露出一些問題。例如，許多頁面需要展示多個服務的數據，像 App 首頁，對于門店運營人員，要展示工單數量、最近的工單、銷售訂單數據、最近待處理的訂單以及低于庫存安全值的商品等信息。這就導致在接口設計時，經常需要糾結該把接口放在哪個服務中，決策效率低下，職責劃分也不夠統一 。

另外，用戶的一個提交操作往往需要修改多個服務的數據，比如一個工單操作，可能要同時修改庫存、銷售訂單狀態和工單數據。由于這類需求眾多，服務之間的調用關系變得錯綜復雜，嚴重影響了系統的迭代和維護 。

為了解決這些問題，項目組決定抽象出一個 API 層。客戶端的接口通常有聚合、分布式調用和裝飾這三種需求。聚合是指一個接口需要將多個后臺服務返回的數據進行整合，然后返回給客戶端；分布式調用是指一個接口可能需要依次調用多個后臺服務，以實現對多個后臺服務數據的修改；裝飾則是指一個接口需要對后臺返回的數據進行重新處理，比如刪除某些字段或者對某些字段進行封裝，使其符合客戶端的需求 。

在客戶端與后臺服務之間增加 API 層后，所有請求經過網關都由這個共用的 API 層處理，API 層通過調用其他后臺服務來完成相應功能。這樣一來，接口放置的糾結情況大幅減少，若涉及聚合、裝飾、分布式調用的邏輯，都放在 API 層；若涉及數據存儲或查詢數據庫的邏輯，則根據目標數據所在的服務來確定邏輯位置 。同時，后臺服務之間的依賴也顯著減少，目前主要是 API 層調用各個后臺服務 。

但新的問題隨之而來，即客戶端適配問題。系統中有 App、H5、PC 網頁、小程序等多種客戶端，不同客戶端的頁面需求存在差異。例如 App 功能較多，頁面可能要求包含更多信息；而小程序追求輕量化，相同頁面所需的數據可能較少 。這就導致后臺服務的同一個 API 需要為不同客戶端進行不同的適配 。而且，客戶端經常會有一些細微的改動，如增加或減少一個字段，為了降低響應速度，需遵循數據最小化原則，這使得后臺服務需要頻繁發布新版本 。再加上后臺服務版本發布時要同時考慮不同客戶端的兼容問題，進一步增加了系統的復雜度 。

為了解決客戶端適配問題，引入了 BFF（Backend for Frontend）設計模式。BFF 的主要理念是為每種客戶端提供專門的 API 服務。不同的客戶端請求經過同一個網關后，會分別重定向到為其設計的 API 服務。例如，微信小程序有專門的 WX API 服務 。由于每個 API 服務只針對一種客戶端，因此可以針對特定客戶端進行優化，使邏輯更簡潔高效，響應速度也比通用的 API 服務更快，因為無需判斷不同客戶端的邏輯 。