中國附醫目前的容器化HIS系統架構中,不論前後端應用,都部署在Anthos的K8s容器環境中,並搭配Kafka平臺。不過,後端資料庫還是相當依賴關聯式資料庫。(圖片來源/中國附醫)

從5年前展開HIS改造工程至今,中國附醫HIS今年已經完成第一階段改造,順利轉移到微服務架構,更運用了超過1千支微服務,來支援醫院內各種醫療的作業。他們如何走到這一步?

關鍵作法1:先重整與優化關鍵流程

「我們先鎖定關鍵流程系統。」中國附醫資訊室副主任孫培然點出,HIS微服務再造的原則,得先從較核心的醫療系統下手,如住院醫囑、護理照護系統等,以微服務架構打造,而行之有年、幾乎不變動的系統(如會計系統),則採API介接,不另行重新開發,將IT火力集中在醫療核心系統。

也因此,他們動手開始改造醫療系統前,全面檢視了所有的醫療流程,想辦法精簡過於冗長的流程或是改善還未數位化的作業,再與新版HIS串接。

比如,中國附醫原有藥品管理流程需要不少人工作業,門診醫師開藥單後,由門診藥局調配藥劑,再派人將藥品送至門診注射室,由護理人員替病人注射,藥品的移動全靠人工,交接過程也得反覆清點確認,來避免出錯。

後來,他們改導入智慧藥櫃系統,來調整流程。醫師開藥後印出處方箋,由病人持至注射室,護理人員掃描條碼後,藥櫃會彈出對應藥劑,由護理人員取出、注射,在這個過程中,藥品運送完全自動化,不用人工清點確認,還能根據藥劑重量變化,來計算庫存。藥品管理流程引進更自動化的系統後,再透過RESTful API來介接中國附醫新版HIS。

另一類流程精進作法,則是採取「就源輸入」策略。比如,護理人員到病房檢視患者狀態時,能就地使用行動裝置上的App,直接登記患者所需的藥品,解決原本因紙本登記出錯或後續人工補登的時間差,導致準備藥品不足的問題。這種新開發的新應用程式,結合微服務架構和事件驅動(Event driven)設計,當源頭資料輸入後,會自動通知相關系統來更新庫存資訊。

一邊優化流程,他們也同步展開了系統架構的調整,拆分原本單體式架構的HIS系統,將其中的功能打造成一支支微服務。孫培然指出,HIS微服務化不只要改造應用程式,還得改造系統架構,將單體系統拆解為顆粒度更細的微服務,才能上雲。

關鍵作法2:功能解耦

中國附醫切分微服務有個關鍵原則:功能解耦方法。這是指,將原本在單體式架構中綁在一起的功能,拆解出來,變成各自獨立的微服務來運作。

比如,一個單體系統中有開單、掛號、計價等功能,可以各自拆分成獨立的開單微服務、掛號微服務和計價微服務程式,再按需要來擴充負載高的功能。「功能解耦方式,可彈性調度資源來應付大量需求,解決了單體系統資源調度困難的問題,」孫培然解釋。

關鍵作法3:程式碼微型化

在功能解耦大原則下,中國附醫還搭配了另一套利於模組化管理的分類方法,來將程式碼微型化。這就是孫培然所提的程式碼微型化設計策略。他解釋,程式碼微型化,不只將程式微服務化,像模組般隨插即用,還要建立共用元件。

這個程式碼微型化策略,將模組化程度將微服務分成三類,包括原料、半成品和成品。原料類微服務,是指與業務邏輯無關的元件,比如民國年轉西元年、電子郵件查收等。這些與業務邏輯無關的元件,還能獨立集結起來,作為一套共用元件。

半成品類微服務則是指與業務邏輯相關的功能,如病人查詢資料、檢驗報告、醫囑開立等,也就是醫療系統會使用到的功能。而成品,則是指多個半成品組成的微服務系統,比如將報告查詢、病人查詢資料、醫囑開立等半成品功能組合起來,就是一套住院醫囑系統微服務。

不論是元件、半成品還是成品,都由一支支微服務組成,比如,多個半成品組成的成品系統,在後端,可以是一支微服務網頁API,在前端,則可能是一個網頁App。採取這三種分類來設計微服務,也能納入時下流行的微前端和微後端架構,放入到半成品類型中管理。

圖片來源/孫培然
中國附醫HIS微服務再造遵循功能解耦原則,在該原則下延伸出
程式碼微型化方法,也就是將程式碼按業務功能,分為原料、半成品和成品。原料是指與業務邏輯無關的共用元件,半成品則是與業務邏輯相關的功能,成品則是由多個半成品組成的系統。

關鍵作法4:MVC程式架構

有了業務面的程式碼微型化做法,在程式開發做法上,中國附醫也採用MVC架構來開發前、後端和資料庫應用,這是後來能夠順利擁抱微服務架構的關鍵。

MVC將程式分為三大類,包括模型層(Model)、視覺呈現(View)和控制類(Controller)舉例來說,一個健康管理應用程式,前端以網頁App方式呈現,其中包含公司基本資料、健檢項目管理、團體接案等3個視覺層,在後端則是網頁API,由3個相同的控制器組成,這3個控制器再向後一層的模型層發送通知,讓3個模型層各自從Stored procedure中撈取所需資料,如公司基本資料模型層,會從Stored procedure中取得單一公司資料、公司清單等。

孫培然透露,中國附醫HIS在MVC架構中,從前端到後端,都採用了雲端原生應用慣用的JSON資料格式,並採網頁技術通用的RESTful API來串接,而且,不論是模型層還是其他程式碼,都改為Stored procedure,而不直接下達SQL指令,以避免人為誤刪資料的問題。

關鍵作法5:結合容器和軟體定義

底層基礎架構的改變,也是中國附醫能夠執行上千支微服務的另一關鍵。

中國附醫運用容器技術來打包這些微服務程式,再部署到K8s環境中,來善用K8s資源自動調度好處,有別於傳統以硬體為中心的架構,資源調度受限硬體,不易動態調整。

孫培然指出,這是微服務的容錯優勢,當系統發生故障時,應用程式不會受到影響,依然繼續運作。而採取容器部署,不論是功能發布、修改、更新還是移植,都能快速完成。搭配輕量級虛擬化容器技術維運管理做法,孫培然更以「不會死」來形容其特性,這也是讓他最有感的微服務優勢。

中國附醫HIS的底層資源調度方式,原以硬體為中心,在應用系統所用的配置中中,明定出所用虛擬機器的配置,得搭配多少CPU記憶體、儲存和網路等硬體規格,這些設定綁定了系統所搭配的硬體規格,一旦更換硬體,就得從頭設定VM配置,並重新測試驗證後才能執行,擴充彈性不足。

後來,中國附醫,改採用軟體定義做法,讓資源調度可以自動化。在底層環境,導入VMware VCF混合雲管理平臺,用軟體定義規則,來管理網路、儲存等設定。利用標籤機制來標記一套應用所需的記憶體、CPU規格、快取容量或網路設定。這些標籤會在部署VM時啟動,執行相對應的規則。如此一來,就算更換實體機器,也不必重寫規則再測試。這種軟體定義的規則更容易管理資源,也能彈性擴充容量。

有了彈性的底層架構,中國附醫也在VCF上部署了混合雲管理平臺Anthos,來管理Kubernetes(簡稱K8s)執行環境。Anthos添加不少管理微服務和K8s工具,能自動監控微服務狀態,也提供服務網格工具,作為不同服務的溝通橋樑,還能將流量和底層架構的資源調度分離,進行更細緻的流量管控。

中國附醫採用Anthos來即時監控HIS微服務狀態、自動調度資源,孫培然認為,Anthos資源自動調度機制最獲得他的青睞,比如,以C#開發的舊護理系統未搬上Anthos時,每隔2周就得將底層伺服器關閉一次,否則系統會當機。後來,他們改用Typescript語言重寫護理系統,並將系統搬上Anthos環境,「8個月來,都沒當機。」

中國附醫在微服務架構中,還採取了訊息佇列(Message queue)機制,來與其他系統溝通。因為,訊息佇列就像是訂閱功能,一旦訂閱的系統接收到新資料,就會發送通知。比如,住院醫囑系統可訂閱護理系統的佇列,當護理人員在系統登記病人藥物過敏時,護理系統就會發送佇列,告知住院醫囑系統,如此,醫師就不必一直搜尋病人藥物過敏記錄,降低資料庫工作負載。

中國附醫DevOps工具鏈大公開

中國附醫在這場HIS微服務再造實戰中不斷試錯,也累積出一套自己專屬的DevOps工具鏈,涵蓋了微服務開發到維運的生命周期循環。

在開發流程端,導入了新創圈流行作法,像是Scrum敏捷開發框架、微服務架構設計模式、SOLID物件導向設計原則,還有MVC開發架構。而在程式碼技術上,則以HTML/CSS、JaveScript和Node.js為主,還可細分為前端Angular框架和後端的NestJS框架,並搭配Typescript和Express。建置用的IDE開發工具是VS Code,測試工具則搭配直覺簡單的API測試工具Postman。

在維運工具端,使用了RESTful API設計、開源遠端呼叫框架gPRC和開源分散式串流處理平臺Kafka,也採用GitLab版本控制平臺,來串接持續部署和持續交付(CI/CD)機制,監控機制上,則使用了K8s、Istio和Envoy平臺機制,搭配開源系統監控工具Prometheus,以及開源分析監控工具Grafana。

不過,中國附醫後端資料庫,採用了關聯庫資料庫SQL Server和開源資料庫MongoDB。

圖片來源/中國附醫
中國附醫資訊室副主任孫培然揭露HIS微服務再造的DevOps工具鏈。比如,在開發流程端,他們導入新創圈流行作法,如Scrum敏捷開發框架、微服務架構設計模式。

挑戰:解決資料同步和資料庫分散設計

不過,要將單體系統改為微服務架構,也不少挑戰要克服,特別是資料同步和資料庫設計。

孫培然指出,要採用微服務架構,還得先解決資料同步的問題。因為,新服務上線後,勢必有段新舊系統並行的適應期,在這段期間內,使用者不可能到兩套系統中重複輸入資料,因此,得先用API介接新舊資料庫,來讓資料同步。

再來,既然應用程式都已微服務、容器化,資料庫設計也得跟著改變。原本,中國附醫HIS採集中式的SQL主機資料庫,若未來所有體系醫院都用一套集中式的資料庫,就會造成管理問題。

孫培然正逐漸要將集中式的關聯資料庫,改採以分散式的NoSQL設計,來降低關聯度。例如,在關聯式資料庫設計中,原本一個Master資料表對應到多個Detail資料表,出院病摘是Master資料表,而其中的檢驗值、檢查報告、過去病史、現在病史等都分散在不同的Detail資料表中。

他採取的新作法是,保留Master資料表,但將多個Detail整合為一個JSON格式表格,一次包含所有Detail,如上述提到的檢驗值、檢查報告、過去病史和現在病史等。原本資料庫架構上,Master和Detail的比例可能高達1比15,現在則要逐漸減少為1比1。「這就是NoSQL中的Document概念,降低關聯式資料庫的關聯性。」中國附醫逐漸邁向更分散式的資料庫架構。

中國附醫在2021年已經完成了新一代HIS 4.0的架構轉移和優化,順利在微服務架構上運作。新的容器化HIS系統架構中,不論前端Angular應用或後端的NestJS應用,都在K8s的容器環境中執行,整套K8s環境則部署在Anthos來提供自動化資源調度,並搭配Kafka平臺。不過,後端資料庫系統還是相當依賴關聯式資料庫。

目前,孫培然正持續打造更完善的新微服務架構,除了延續現有的事件驅動設計和Kafka平臺,對現有微服務之間的溝通方式,還要採用更高效溝通的gRPC框架,來逐漸來取代現在所用的Restful API呼叫方式,也要將關連式資料庫,轉換成NoSQL架構。

中國附醫新一代HIS的微服務架構轉型,才順利剛邁開了第一步,完成第一階段的轉移,2022年展開的基礎架構改造第二階段,開始要邁向混合雲架構和更高可靠性的設計,中國附醫的微服務改造之旅,還沒有結束。

圖片來源/中國附醫
中國附醫正持續打造更完善的新微服務架構,微服務之間的溝通方式,將採用更高效溝通的gRPC框架,來逐漸來取代現在所用的Restful API呼叫方式。也要將關連式資料庫,轉換成NoSQL架構。

 相關報導  


熱門新聞

Advertisement