口述／孫培然‧彙整／CIO編輯室
本文要談的是，如何透過事件驅動架構（Event-Driven Architecture，EDA），讓程式更解耦，來提高彈性跟容錯性。以前的單體式時代，我們比較重視的是硬體資源，比如說主機伺服器要很大，CPU 要很快，記憶體要很多，要加速硬碟 I/O 效能。但是到了微服務的分散式架構時代，重視的反而是服務網格（Service Mesh）。然而服務網格的網路之間怎麼互通？怎麼好好的呼叫微服務，服務跟服務之間的呼叫，能怎麼確保它可以正常的運作？
Open API 無法主動及時通知
比如說現在你問朋友中午要吃什麼，他回覆說吃披薩。這就是一個提出要求（Request）的概念。換成 Open API 的措辭，提問的人是「消費者」，而回答的人是「提供者」，也就是消費者會對提供者提出要求，提供者則是根據消費者的要求，回饋消費者所需要的資料。
但在這個情境當中會有一些問題存在。當消費者問提供者：「午餐準備好了嗎？」提供者回答說：「沒有。」但可能再過幾分鐘，消費者又再問：「午餐準備好了嗎？」可能會問很多次。
問題是消費者會覺得很煩，因為問了那麼多次，都還沒有得到提供者的回覆；而提供者也會覺得，我已經在忙著準備午餐了，還得一直回覆消費者還沒有、還沒有…。
其實這正是傳統 Open API 會產生的問題。如果把前述的概念換成 API 來看，若在醫院的使用情境，如圖一所示，就是用戶端（Client）的醫師會一直對伺服端提出需求，不斷的問檢驗報告出來了嗎？但過於頻繁的問，伺服端（Server）就得很頻繁的回答，如果很多醫師來問，這個伺服端可能最後就會被用戶端操到死。
你可能會想，如果不想問到很煩，為什麼不能過 10 分鐘再問？因為即使只是過了 10 分鐘，可能就已經喪失良機。比如說，醫師可能正好碰到病人出現過敏反應，或者是投資者正想要買的股票剛好跌下來，想賣的時候卻又漲上來，要不要等 10 分鐘，都會是個難題。
Async API 的服務更貼心
所以，有沒有可能改變方式，消費者不需要一直問提供者，而是讓消費者可以跟提供者要求，提供者如果準備好了，會主動告訴消費者。也就是說，如果股市或是病人的過敏反應的資訊稍微有變化，提供者可以主動告訴消費者。
從消費者只能被動的詢問，變成由提供者主動告訴消費者，東西準備好了沒有的方式，可以用來反思 Open API 跟 Async API 的不同之處。如我們前面提過的案例，與其讓提供者只能回答「準備好／未準備好」，讓消費者必須要不停的去理會，消費者可不可以只需要訂閱（Subscribe）？一旦消費者有訂閱，只要有任何的變化，提供者就可以告訴消費者你，如 圖二 所示。
這也是我之前常講的「按讚、分享、訂閱，開啟小鈴鐺」的概念。也就是說，一旦提供者有異動，就通知消費者，消費者不用一直問提供者，提供者也就不用一直忙著回覆消費者。
這樣的機制從被動化為主動，不但可以減少消費者的詢問，又可以減少提供者一直回覆浪費資源。所以未來的程式開發，應該要慢慢的朝向以事件驅動架構的概念來進行 API 的呼叫方式。
這也就是 Async API 運應而生的價值，除了可以回答好「準備好／未準備好」之外，事件驅動架構還可以依照不同的 API 驅動方式，讓消費者可以即時接受到每一個狀態的變化，讓提供者可以由被動化為主動，藉此提升效能。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球 CIO 同步獲取精華見解 ]
比如說，原本是要由消費者問：「晚餐準備好了沒有？」現在可以變成由提供者主動說：「披薩已經準備好了」、「已經賣完了」等等這些資料的變化，提供者都可以即時通知前端的使用者，讓使用者可以直接接觸到更多的資訊。
比如你訂閱了「某個病人開刀的整個狀況」，因為開刀的狀況，會包括進入開刀房、麻醉、手術中、恢復中等，只要病人的開刀狀況有異動就會主動通知，「病人已經進入開刀房」、「病人現在正在麻醉中」、「病人現在正在手術中」、「病人已經在恢復中」等這些資訊，不用你每一次去詢問，讓使用者得到更好的體驗。
微服務的運行方式的優劣
微服務的運行方式有編排（Orchestration）與編舞（Choreography）就好像是交響樂團與芭蕾舞團的比喻；編排方式需要有一個操控所有元素和交互，就像交響樂團的指揮家一樣，而編舞方式則只需要每位舞者跟隨著音樂旋律起舞就可以，無需監督和指導。例如許多與微服務如何相互交互以實現業務成果有關。在微服務編排方式與編排方式之間進行選擇，將對服務在幕後的無縫運行方式以及您是否成功構建了微服務架構或分佈式整體架構產生了影響。
我們就以健康檢查中心的應用來舉例說明，當客戶要預約健檢時，新增手續完成後，可能需要幾個步驟。如 圖三，首先是要依班表先去分配主責護理師，完成之後再告訴客戶，健檢當天的主責護理師是誰？之後要 E-Mail 通知客戶健檢時間跟叮嚀健檢的注意事項，還要列印信封，再郵寄檢查包給病人。假設分配主護要花費 5 秒鐘，發送簡訊要花費 5 秒鐘，寄送列印信封要花費 10 秒鐘，等於從新增到完成，總共要花 20 秒的時間。若是用編排方式來進行微服務之間的呼叫，那真的要花 20 秒才能完成。由於編排的方式屬於同步的機制，所以必須要等前一個服務完成才能繼續下一個服務，最後要等所有的服務都完成，這個任務才能結束。如果有某一個服務延遲或出了狀況，就得要一直等。
但若改為 圖四 的編舞方式，所有的服務接收到要求就開始運作，最快可能只要 10 秒鐘就能完成任務，若有某一個服務有狀況也不會影響其他服務的執行，另外，有問題的服務也可以重啟新的服務來接手繼續服務，確保服務不中斷。
只採用 Open API 方法的時代已經過去了，對於能夠更快、更可靠地提供業務服務，並且易於擴展的架構，更好的方法是編排微服務交互的模式 ─ Async API ，讓服務之間更加鬆散耦合，以實現敏捷性和容錯性及強化服務的韌性。
[ 推薦閱讀：孫培然專欄所有文章 ]
(本文授權非營利轉載，請註明出處：CIO Taiwan)
