【中國附醫HIS再造：微服務實作關鍵】上千支微服務支援全院醫療作業，5大關鍵做法大公開

從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架構。

 相關報導