基于微服務的醫(yī)療數(shù)據(jù)統(tǒng)一服務平臺的設計與實現(xiàn)

基于微服務的醫(yī)療數(shù)據(jù)統(tǒng)一服務平臺的設計與實現(xiàn)

近年來，隨著醫(yī)院計算機科學的蓬勃發(fā)展，醫(yī)療數(shù)據(jù)呈現(xiàn)出明顯的大數(shù)據(jù)特征：數(shù)據(jù)體積大、類型多、價值高、價值密度低、數(shù)據(jù)生成快、效率要求高的特點。動態(tài)數(shù)據(jù)日益增長，醫(yī)療設施網(wǎng)絡數(shù)據(jù)得到實時生成。1微服務在互聯(lián)網(wǎng)的應用現(xiàn)狀目前大多數(shù)醫(yī)院已經(jīng)建設了以企業(yè)服務總線（enterpriseservicebus,ESB）交互的集成平臺，業(yè)務系統(tǒng)之間的調(diào)度，都能通過消息的方式完成傳遞和交互，解決了各系統(tǒng)之間的數(shù)據(jù)格式、存儲、安全級別不同造成的很多業(yè)務處理上的問題在互聯(lián)網(wǎng)、金融、政務等行業(yè)，基于微服務的服務平臺得到越來越多的運用，數(shù)據(jù)即服務、應用即服務的模式逐漸成為行業(yè)趨勢。在服務平臺上，實現(xiàn)了服務管理、憑證管理、用戶管理、統(tǒng)一訪問入口等功能，很好地解決了傳統(tǒng)服務資源管理中的難題，提高了服務資源訪問的效率，減輕了服務資源匯聚、分發(fā)的工作量2基于微服務體系結(jié)構(gòu)的統(tǒng)一服務平臺設計2.1微服務開發(fā)框架為了更好解決醫(yī)院業(yè)務數(shù)據(jù)、應用及服務的信息孤島問題，提升各種資源互聯(lián)互通的實現(xiàn)效率，可以通過搭建基于服務網(wǎng)關(guān)的醫(yī)院微服務統(tǒng)一服務平臺（以下簡稱“統(tǒng)一服務平臺”），支撐院內(nèi)各業(yè)務系統(tǒng)之間、醫(yī)聯(lián)體機構(gòu)之間業(yè)務系統(tǒng)的數(shù)據(jù)交互。醫(yī)院統(tǒng)一服務平臺架構(gòu)設計見圖1。醫(yī)院統(tǒng)一服務平臺技術(shù)架構(gòu)基于容器云平臺Kubernetes（以下簡稱K8s）、容器引擎Docker以及微服務開發(fā)框架SpringCloud技術(shù)，依靠K8s對容器集群實現(xiàn)自動化管理。微服務開發(fā)框架相當于微服務的實現(xiàn)與治理的一個模板，包含了多種微服務治理能力，比如流量控制、安全管理、鏈路負載、服務監(jiān)控等。SpringCloud旨在為微服務架構(gòu)提供一種簡單有效、統(tǒng)一的應用程序接口（applicationprogramminginterface,API）路由管理方式統(tǒng)一服務平臺對醫(yī)院院內(nèi)、醫(yī)聯(lián)體機構(gòu)、第三方機構(gòu)等提供配置、注冊、訂閱服務，并統(tǒng)一對各類數(shù)據(jù)、應用、服務的調(diào)用情況進行監(jiān)控和運維。通過開發(fā)規(guī)范、接口規(guī)范、集成規(guī)范等管理規(guī)范，將醫(yī)院應用及數(shù)據(jù)服務逐步納入統(tǒng)一服務平臺管理。醫(yī)院統(tǒng)一服務平臺將院內(nèi)系統(tǒng)對外提供的數(shù)據(jù)、應用、AI、標準、知識等服務定制成服務網(wǎng)關(guān)模式，將服務進行關(guān)聯(lián)和編排。2.2醫(yī)院應用系統(tǒng)的微服務模式2018年，云原生計算基金會將云原生的定義更新，加入了服務網(wǎng)格和聲明式API。在此概念下，針對醫(yī)院信息化建設，云原生可突破傳統(tǒng)Web框架，超越傳統(tǒng)IT模式，真正做到充分利用和發(fā)揮云平臺的彈性和分布式優(yōu)勢，將數(shù)據(jù)、服務和應用3種資源在最終實現(xiàn)時，構(gòu)建簡便快捷，部署輕松自如，運行按需彈性伸縮。隨著新興信息技術(shù)的發(fā)展，云原生技術(shù)逐步被引入醫(yī)療信息化建設中。醫(yī)院統(tǒng)一服務平臺通過云原生技術(shù)，可以更快速支撐持續(xù)變化的醫(yī)院臨床診療業(yè)務。比如，在醫(yī)院診療業(yè)務的數(shù)字化轉(zhuǎn)型中，大數(shù)據(jù)檢索服務、人工智能語音服務、患者全景視圖服務、指標管理服務、精準醫(yī)療以及臨床試驗、科研業(yè)務的開展，相比傳統(tǒng)業(yè)務更靈活多變，對數(shù)據(jù)和服務資源的需求呈多樣化趨勢，這些都在驅(qū)動醫(yī)院應用系統(tǒng)建設從傳統(tǒng)模式向云原生模式轉(zhuǎn)型。醫(yī)院系統(tǒng)實現(xiàn)一個后端應用傳統(tǒng)采用單體模式，通過單一后端應用提供并集成所有的服務，其系統(tǒng)實現(xiàn)見圖2。單體模式往往還給醫(yī)院信息系統(tǒng)帶來以下問題：(1)業(yè)務邏輯捆綁在一起，隨著代碼變得越來越大，開發(fā)人員在編譯和部署的時間上明顯增多，醫(yī)院再部署或改造新應用時間成本增高；(2)隨著醫(yī)院應用系統(tǒng)不斷完善，引用的技術(shù)越來越多，單體架構(gòu)在拓展實現(xiàn)各個技術(shù)兼容性方面明顯不足，也使得部分功能放棄最合適的技術(shù)選型；(3)龐大的代碼庫對新的開發(fā)人員是一個很大的技術(shù)壁壘，無法讓他們在短時間內(nèi)快速著手開發(fā)工作。微服務是將原來黑盒化產(chǎn)品進行拆分解耦，拆分成各自提供不同服務的多個個體，每個子服務個體負責一組子功能，這些子服務個體稱為“微服務”，見圖3。利用微服務模式，醫(yī)院業(yè)務系統(tǒng)可以通過統(tǒng)一服務平臺發(fā)布、訂閱所需的服務資源，實現(xiàn)數(shù)據(jù)和服務的共享交換。例如HIS、全程管理系統(tǒng)可以訂閱患者全景視圖服務，科研病種庫可以訂閱大數(shù)據(jù)檢索服務和人工智能語音服務，互聯(lián)網(wǎng)門診可以訂閱人臉識別服務等。多個微服務共同形成了一個物理獨立但邏輯完整的醫(yī)院分布式微服務體系，醫(yī)院業(yè)務系統(tǒng)能夠通過微服務快速擴展功能和應用水平。各個微服務相對獨立，不同的醫(yī)院或廠商應用開發(fā)人員可以對各自負責的模塊進行處理、研發(fā)、測試，還可以通過分布式架構(gòu)實現(xiàn)應用水平擴展和冗余部署。2.3微服務應用場景云原生技術(shù)下的容器云平臺K8s集群是醫(yī)院統(tǒng)一服務平臺的服務承載單元，但K8s集群卻缺乏靈活的服務接入能力。醫(yī)院臨床診療業(yè)務中的全景視圖服務、人工智能語音服務、大數(shù)據(jù)檢索服務等微服務模塊，需要靈活對外發(fā)布、提供訂閱，并對部分服務進行數(shù)據(jù)安全管控。因此，微服務架構(gòu)在醫(yī)院的落地，需要服務網(wǎng)關(guān)作為一個出入口。服務網(wǎng)關(guān)是醫(yī)院內(nèi)外部應用調(diào)用某個微服務的唯一入口，通過API提供應用程序與開發(fā)人員得以訪問一組醫(yī)療服務及數(shù)據(jù)的能力。服務網(wǎng)關(guān)也是醫(yī)院數(shù)據(jù)中心與數(shù)據(jù)服務需求者之間的數(shù)據(jù)服務中介模塊，對數(shù)據(jù)服務輸出的數(shù)據(jù)進行數(shù)據(jù)脫敏、合規(guī)檢查、安全審計等處理2.4統(tǒng)一服務平臺的中心功能2.4.1服務平臺相關(guān)功能提供統(tǒng)一的服務入口是醫(yī)院統(tǒng)一服務平臺最主要的功能，除此之外，服務平臺還可承擔認證授權(quán)、負載均衡、限流限額、熔斷、服務編排、API管理、監(jiān)控等服務管理類功能，見圖4。2.4.3服務能力提取醫(yī)院內(nèi)各應用系統(tǒng)有一些相同功能，比如身份校驗、流量過濾、訪問統(tǒng)計等。統(tǒng)一服務平臺可以將應用服務中重復的功能提取出來，由平臺的服務網(wǎng)關(guān)統(tǒng)一對所有微服務進行權(quán)限校驗、流量控制、熔斷降級、數(shù)據(jù)緩存等。讓各個微服務的開發(fā)專注自身業(yè)務，降低重復開發(fā)和運維成本。見圖6。2.4.4服務靈活組合3統(tǒng)一服務平臺的關(guān)鍵技術(shù)在醫(yī)院統(tǒng)一服務平臺的設計和實現(xiàn)過程中，所涉及的核心要點和技術(shù)創(chuàng)新點，主要包括以下3個方面。3.1自適應一體化管理架構(gòu)針對醫(yī)院信息系統(tǒng)組成復雜、異質(zhì)異構(gòu)的技術(shù)難題，醫(yī)院統(tǒng)一服務平臺以微服務架構(gòu)將數(shù)據(jù)、應用、服務資源統(tǒng)一納入管理，以注冊、訂閱的形式對外提供服務，構(gòu)建業(yè)務自適應一體化管理架構(gòu)，實現(xiàn)自適應按需擴展。醫(yī)院內(nèi)開展的一些新興業(yè)務，例如人工智能語音服務，醫(yī)院各業(yè)務系統(tǒng)不需要重復建設該服務，只通過統(tǒng)一服務平臺對該服務進行訂閱即可。所有資源對內(nèi)封裝，以接口的方式對外安全開放，通過平臺的統(tǒng)一數(shù)據(jù)和接口規(guī)范，以統(tǒng)一協(xié)議的服務網(wǎng)關(guān)，將數(shù)據(jù)、應用、服務接口通過服務網(wǎng)關(guān)發(fā)布。平臺對各個資源部件進行智能管理控制，實現(xiàn)判斷和決策，自動生成業(yè)務策略，并快速分發(fā)執(zhí)行，實現(xiàn)統(tǒng)一策略下的協(xié)同服務、檢測和響應。統(tǒng)一服務平臺管理模型，見圖8。3.2微服務架構(gòu)的關(guān)鍵技術(shù)醫(yī)院統(tǒng)一服務平臺實現(xiàn)對服務資源集中化處理，但如果缺乏精細的服務管理和運維能力，一旦服務發(fā)生異常將無法及時響應和進行排查，導致業(yè)務受損；或由于后端服務沒有統(tǒng)一的身份認證和安全防護，導致后端安全性降低。基于微服務架構(gòu)的統(tǒng)一管理模型，將通過安全認證、監(jiān)控管理、審計管理等關(guān)鍵技術(shù)來保障服務資源的安全。醫(yī)院統(tǒng)一服務平臺集中了醫(yī)院院內(nèi)、院外優(yōu)質(zhì)服務資源，例如大數(shù)據(jù)資源、人工智能服務資源、診療數(shù)據(jù)資源等，對這些資源進行有效利用的同時，需要數(shù)據(jù)安全、監(jiān)控管理及審計管理的強化保障，避免資源濫用、誤用、數(shù)據(jù)泄漏等安全問題。安全認證：在統(tǒng)一身份和安全認證上，統(tǒng)一服務平臺通過服務網(wǎng)關(guān)進行鑒權(quán)控制和流量控制；監(jiān)控管理：統(tǒng)一服務平臺針對全局或單個服務設置預警規(guī)則和通知人，支持郵件和短信等預警方式，同時可對接醫(yī)院內(nèi)部預警系統(tǒng)；審計管理：統(tǒng)一服務平臺通過分布式日志系統(tǒng)，對不同事件進行細粒度的實時記錄與分析。3.3統(tǒng)一服務平臺彈性能力在當前醫(yī)院大數(shù)據(jù)中心建設趨勢下，院內(nèi)業(yè)務海量數(shù)據(jù)交互需求日益增多，例如影像、基因組學、流式數(shù)據(jù)等，其次臨床科研任務突發(fā)需求多，這種情況下統(tǒng)一服務平臺的彈性能力就顯得尤為重要。統(tǒng)一服務平臺提供了分布式服務網(wǎng)關(guān)管理的核心能力，配合容器技術(shù)可輕松應對突發(fā)大流量的情況。3.3.1多容器集水平自動支持K8s監(jiān)測每個容器服務上所承擔的負載，如果某個容器CPU利用率過高，或者響應時間過長，它可以通過多容器集的水平自動擴展（horizontalpodautoscale,HPA）對這個服務進行自動水平擴容。3.3.2協(xié)議轉(zhuǎn)換服務平臺集成多種數(shù)據(jù)處理協(xié)議，根據(jù)消息請求體，判斷使用何種協(xié)議，可靈活調(diào)度后端提供的文件、影像、基因組學、流式數(shù)據(jù)服務。4醫(yī)院應用程微服務化改造是一項復雜的、多方多人協(xié)作的應用架構(gòu)演進工程，是以醫(yī)院為主導，平臺及應用廠商從架構(gòu)、技術(shù)、運維等方面密切配合才能付諸實現(xiàn)的軟件工程。以我院為例，結(jié)合已經(jīng)逐步接入的系統(tǒng)或項目，如表1所示，主要解決的問題如下。4.1加的系統(tǒng)之間的關(guān)聯(lián)隨著信息化發(fā)展需要，我院的主要業(yè)務系統(tǒng)已經(jīng)達到143個，每年持續(xù)增加的系統(tǒng)在20個以上，各個業(yè)務系統(tǒng)之間都或多或少有些相互關(guān)聯(lián)。通過服務平臺將所有業(yè)務系統(tǒng)的服務接入平臺，并通過服務平臺對所有業(yè)務系統(tǒng)提供唯一、標準的垂直服務，大大降低了業(yè)務系統(tǒng)之間的互聯(lián)互通的復雜性。4.2業(yè)務及服務監(jiān)測統(tǒng)一服務平臺存儲了各個業(yè)務系統(tǒng)的訪問日志。通過統(tǒng)計功能可以查看各個業(yè)務系統(tǒng)、各個服務訪問的情況；通過預警可以及時解決系統(tǒng)異常、服務異常、數(shù)據(jù)異常等問題。以2021年3月3日一天為例，醫(yī)療數(shù)據(jù)服務情況統(tǒng)計見表2。4.3在線服務的性能醫(yī)院業(yè)務復雜，業(yè)務系統(tǒng)有需要數(shù)據(jù)接口時，往往都是根據(jù)廠商需求定制開發(fā)數(shù)據(jù)服務。而每個廠家需要的數(shù)據(jù)格式和標準都不一樣，沒有統(tǒng)一的服務平臺，難以對以前的服務進行二次復用而不得不新開發(fā)接口，造成大量的人力和時間的浪費。通過服務平臺，所有在線服務可以一目了然，可通過授權(quán)輕松把服務提供給廠商，不用二次重復開發(fā)。也可通過服務編排對現(xiàn)有接口進行服務整合，滿足個性化服務需求。4.4增強服務能力以服務平臺的彈性伸縮能力，當平臺檢測到有大數(shù)據(jù)請求需求，平臺容器服務負載過大或響應時間過長，平臺通過多容器集的水平自動擴展，對這個服務進行自動水平擴容，增強服務能力。輕松解決本院用戶在傳輸影像、基因組學、流式數(shù)據(jù)等海量數(shù)據(jù)問題時遇到的問題。4.5數(shù)據(jù)安全方面當前，大數(shù)據(jù)正在成為信息時代的核心戰(zhàn)略資源，對國家治理能力、經(jīng)濟運行機制、社會生活方式產(chǎn)生深刻影響。與此同時，各項技術(shù)應用背后的數(shù)據(jù)安全風險也日益凸顯。近年來，有關(guān)數(shù)據(jù)泄露、數(shù)據(jù)竊聽、數(shù)據(jù)濫用等安全事件屢見不鮮，保護數(shù)據(jù)資產(chǎn)已引起各國高度重視。我院在數(shù)據(jù)安全方面長期以來缺少一個系統(tǒng)來輔助解決，一旦服務發(fā)生異常將無法及時響應而導致業(yè)務受損；或由于后端服務沒有統(tǒng)一的身份認證和安全防護，導致后端安全性降低。統(tǒng)一服務平臺以統(tǒng)一安全認證、監(jiān)控管理、審計管理等關(guān)鍵技術(shù)來保障服務資源的安全。對數(shù)據(jù)服務輸出的數(shù)據(jù)進行數(shù)據(jù)脫敏、合規(guī)檢查、安全審計，并提供身份驗證、流量控制、安全防護、內(nèi)容審計等。5統(tǒng)一服務平臺，實現(xiàn)醫(yī)療大數(shù)據(jù)共享，將促進信息共享本研究對基于微服務的醫(yī)院統(tǒng)一服務平臺的管理模型、設計方案、核心技術(shù)、主要功能進行了闡述?；诖似脚_，可以實現(xiàn)對醫(yī)院數(shù)據(jù)、應用、服務資源的三位一體的統(tǒng)一管理，更好地解決醫(yī)療信息化互聯(lián)互通的問題。借助統(tǒng)一服務平臺，實現(xiàn)服務的統(tǒng)一調(diào)用、統(tǒng)一鑒權(quán)，提高醫(yī)院應用系統(tǒng)的開發(fā)迭代效率。同時，統(tǒng)一服務平臺在醫(yī)院大數(shù)據(jù)場景下，在安全認證、監(jiān)控審計等技術(shù)保障下安全提供各類數(shù)據(jù)資源服務。數(shù)據(jù)、應用、服務資源的完全打通，實現(xiàn)醫(yī)療信息的真正互聯(lián)共享，將成為后續(xù)推進醫(yī)療行業(yè)持續(xù)發(fā)展的重要一環(huán)。此外，隨著醫(yī)院業(yè)務需求的不斷出現(xiàn)，將K8s移植到邊緣計算場景是個非常好的選擇，但由于邊緣計算特點，將完整的K8s移植到邊緣計算場景中，仍然存在不支持ARM設備等諸多問題。而且對計算資源的消耗，尤其內(nèi)存是邊緣設備無法承受的，并且邊緣設備目前是以ARM架構(gòu)居多因此，本研究服務平臺在未來的設計方向?qū)⒔Y(jié)合K3s技術(shù)展開研究，以滿足醫(yī)療服務行業(yè)中各類新興業(yè)務需求和垂直行業(yè)物聯(lián)網(wǎng)大規(guī)?？焖儆行Ч芾淼墓I(yè)需求2.