口述／孫培然‧彙整／CIO編輯室
針對打造微服務架構，前兩期我們闡述了資料庫與 API 的特性。本期來談談有關程式同步的問題。
如果我們把同步改成異步，也就是非同步，以 Event-Driven APIs 而言，會是屬於協同式（Choreography）架構，會預先說明清楚系統中各個部份的職責，把具體怎麼實現，留給各個部分服務自己實作出來，不管是分配主護、寄送檢查包或是發送郵件，每一個服務的職責都會非常的清楚。
異步協同式架構更加靈活
透過異步的方式，從新增客戶健檢服務開始，只要把資料推送到 Event-Broker 觸發一個事件，有個客戶要去做體檢，再由分配主護、發送郵件、寄送檢查包這三個服務來分別訂閱，各自完成任務。之前曾經提過同步方式，分配主護可能要 5 秒，寄送檢查包可能要 10 秒，發送郵件可能要 5 秒，總共要花費 20 秒的時間，但如果用異步方式，總共只要花費 10 秒就可以完成。因為不需要互相等來等去，只要取最大花費秒數的時間，就可以完成整個事件。
所以異步方式的優點，就是可以讓整個系統架構完全解耦，沒有時間差的耦合，不需要等到某一個服務完以後，再接著下一個服務，而是可以同時工作，服務之間不會互相牽絆。
[ 推薦閱讀：後疫情時代的數位轉型關鍵心法 ─ API 篇]
除此之外，如果寄送檢查包一個服務不夠，我可以再開另外一個服務實例（Instant），用兩個服務來提供服務。如圖一所示，一個服務可能要花 10 秒，兩個服務一起運作，就只要花費 5 秒，就可以完成整個動作，這就是 Event-Driven 可以讓我們更靈活的修改現有系統架構的概念。
事件驅動可以加速 AI 應用落地
以中國附醫的智抗菌平台為例，整合了七個單位透過事件驅動來做資料傳遞，加速 AI 落地。首先是由檢驗醫學部將所做的細菌報告的結果，發布到事件驅動架構中的 Event Broker，已經訂閱這些報告主題（Topic）的三個 AI 中心，就可以即時直接拿到資料進行演算法分析，再把 AI 預測結果一樣推送到 Event Broker，一旦 Event Broker 有了這些資料，HIS 系統因為已經在之前訂閱，就會直接將這些資料推送給 HIS，再將 AI 預測結果直接呈現在 HIS 的畫面上。
同步的 API 會遇到一個問題，到底是我沒有把報告發出來？還是你沒有接收到報告？還是我有接收到報告，卻沒有回覆給你？兩造之間就會因為分不清楚而爭吵。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球 CIO 同步獲取精華見解 ]
如果是透過傳統的 API 來呼叫檢驗醫學部的報告，就要呼叫這三個 API，等於這三個 API 要跑三次。但如果透過事件驅動的概念，檢驗醫學部的報告只要有發出來，在訊息區就能找得到，有多少人訂閱都不用管，只要找得到報告，如果沒有被讀取，就是 AI 沒有讀，不是檢驗醫學部沒有發出來；一旦 AI 有讀，卻沒有把進一步的報告發出來，那就是 AI 的問題，責任劃分非常的清楚。
如果希望把 AI 相關預測，擴展延伸到其他的醫院，而每一家醫院的內部網路架構都不一樣，所面對的問題就更為複雜了。所以未來會把資料透過 Event Broker 來傳遞，為了符合標準，我們以後傳輸的資料是都會符合 HL7 FHIR 標準格式做交換。
也就是說，儀器所產生的資料會直接發布到 Event Broker，雲端的 AI 就直接來訂閱相關資料，一旦有資料，就會把它傳送到雲端，雲端的資料分析完以後，再發佈到 Event Broker，再給院內的 HIS 訂閱，呈現在資料庫當中。之間可以跨不同的網域，不同的網段，從地端到雲端都可以互相的應用，這種機制可以快速的讓 AI 落地。
[ 推薦閱讀：孫培然專欄所有文章 ]
(本文授權非營利轉載，請註明出處：CIO Taiwan)
