傳統HIS架構有哪些問題？首先，傳統的HIS架構大部分屬於單體式的應用架構，導致軟體生命週期在剛開發時就已經定型了，對很多應用程式來說它們的架構在醫院建立之初，就已經被設計好了。
例如早期的HIS是用Delphi程式語言設計的，那就只能一直沿用Delphi來設計，但糟糕的是現在卻找不到會用Delphi設計的人，我甚至問來面試的人，知道Delphi是什麼嗎？很多人都已經不知道了。
[ 加入 CIO Taiwan 官方 LINE 與 FB ，與全球CIO同步獲取精華見解 ]
所以，隨著醫院的發展，應用程式的規模也在慢慢的擴充，但開發人員就會慢慢感覺到，當初所設計的架構，會影響到未來的發展而形成束縛，沒辦法自由自在的選擇比較新和比較好的程式語言去重新開發，沒辦法做大量的回歸測試，來確保新增的功能特性不會破壞應用程式的完整性，影響系統的架構。
如此一來，傳統的HIS架構就可能會演變成一個巨大又複雜的「大泥球」，就像我之前形容HIS是一個大恐龍一樣，在這種情況下，很難有單個開發人員能夠理解HIS的整體架構。
於是我們就要花很多時間先去瞭解原來的程式架構，才能開始修改程式。假設我的開發時間是12小時，可能會有2/3的時間，是花在瞭解程式的整個架構，只有1/3的時間才是真正的用來改程式。
[CIO都在讀： 導入微服務重構現代化HIS架構 ]
傳統HIS架構另一個問題，就是很難實現模塊化的重用，因為它的耦合性太高了，沒辦法重覆使用，要擴展HIS架構，更是一大挑戰，尤其是單體應用是使用單個開發工具時，你就只能用同樣的程式語言去發展，沒辦法改變。這可能會限制無法為不同的服務任務，選擇較合適工具的靈活性，會成為很大的問題。
因為任何針對單體應用的重構，都會受到原始架構的束縛，也就是說，原始的架構會決定應用程式的未來。所以我們希望在開發新的HIS系統時，能朝向應用開發更有彈性的微服務架構，這也是我為什麼一直在倡導，醫療資訊系統應該要以微服務架構來搭建，才能永續經營。
單體應用架構的缺點
單體應用架構的複雜性非常高，因為所有的東西都會整合在同一個檔案或專案裡面，導致模組邊界會非常的模糊，依賴性及相關性也會變得不清楚，每一個程式碼的質量參差不齊，如果接觸到系統人很多，一旦有人離職，有新來的人接手，都可能造成混亂。每次修改，就算只是新增一個簡單的功能，一不小心就會有Bug，就會影響到其他功能，每上一個系統之後，都必須要戰戰兢兢，拜託系統不會出事情。
再來就是技術債務的問題，隨著時間的推移跟需求的改變，還有技術人員的更替，會逐漸的形成應用程式的技術債務，而且會越積越多。擴充套件的能力也會受限，因為單體應用只能做為一個整體進行的擴充套件，沒辦法根據某個業務模組去進行擴充。
[ 下載 2020-21 CIO大調查報告，掌握最新IT趨勢 ]
單體應用架構同時也會阻礙技術創新，對於單體應用來說，技術是在開發之前就必須要慎重評估後選定的，但是一旦你選定以後，你就可能不能改了，而且是一二十年都不能改。有一些醫院的舊HIS系統是在二十幾年前寫的，到目前都還在用，每個團隊成員就必須使用相同的開發語言及資料庫管理系統，相關的儲存設備跟其他資訊系統，也必須要一樣。
此外，單體應用架構的程式，因為必須要部署在同一個伺服器上，很容易出現系統負載過重（Overload）、記憶體洩漏（Memory Leak）等問題。也就是說，伺服器假設只能容納1000個人同時上線，一旦超過了就沒輒了，只能重新買一台更大容量的伺服器去應付更多人，但原來的硬體也就不能用了，因為單體應用架構不能橫向擴充，只能垂直的擴充，所以很難快速的重新部署更新版本，導致要提供高品質服務，會變成事倍功半。
微服務架構從開發即是高品質服務
但如果要讓微服務架構從開發就是高品質的服務，就必須要接受微服務標準化的挑戰。因為微服務架構雖然為開發人員提供了很大的自由空間，不再局限於過去的架構，開發人員可以依照自己的想像去設計服務，可以自由自在的選擇開發工具、資料庫還有開發語言等等，但每一個微服務都是由微服務生態系統所組成，他們之間存在非常複雜的相依關係，所以需要定出標準原則，微服務之間才能無縫地進行交付。
最重要的是，任何一個微服務都不應該破壞整個生態系統的完整性，每一個微服務只不過是在大型分散式系統的一個組成部分而已，所以我們必須要為所有的微服務定義標準，讓它可以融入到整個生態圈裡面，使每一個微服務都可以被量化，並且可以產出可度量的結果，這才叫做高品質的概念。
首先，微服務的可用性標準目標是什麼？在微服務生態圈中，服務的可用性相關的服務等級協定（SLA），是最被常用的評估方法。如果一個服務具有高可用性（代表停機時間很少），我們就可以說這個服務運行良好。
[CIO都在讀： 6個基礎架構及維運的熱門趨勢 ]
可用性要怎麼衡量？只需要考慮三個重要的指標。第一個是Uptime，也就是微服務正常工作的時間；第二個是Downtime，也就是微服務沒辦法正常運作的時間，Uptime跟Downtime加起來，就是整個微服務的總執行時間。可用性指標的公式如下：
Uptime/(Uptime+Downtime)
所謂的「高品質標準」，就是當我們說一個應用程式或者微服務是「高品質」時，代表我們對它充滿了信心，我們相信它的行為是正常合理的，而且表現是可靠的，以及他可能會在很少停機的狀況下可以處理好任務。
所以高品質標準的主要原則，也是達成微服務生態系統可用性的關鍵因素，每個微服務、應用程式和分散式系統，都必須去遵循八個可量化的高品質原則：穩定性、可靠性、擴充性、容錯能力、災備能力，高效能，還有監控能力及文件化等，這些原則組合加在一起，才能共創微服務的高度可用性。
穩定性、可靠性及擴充性
首先是穩定性。微服務架構可以帶來開發上的自由，並且可以加快部署的速度，每天我們都可以開發部署新的功能，缺陷也可以很快的被修復，舊技術被新技術取而代之，過時的微服務被重寫，舊版本的微服務被下架。但如果沒有遵循八大原則，快速的變更可能會導致穩定性的下降，因為程式有Bug或其他嚴重錯誤，都可能會影響到其他的服務，造成整個的不穩定。
所以要處理好微服務的變更，提高穩定性，是達成可用性的關鍵步驟，任何的開發、部署、技術更新，還有服務下架，都不應該降低服務本身跟整個生態圈的穩定性。
為了要減少可能在開發過程中出現的問題，我們必須要採用穩定的開發流程，也就是最早所提的，你必須要部署到不同的環境去做測試，從階段性（Staging）跟逐步性（Canary）的環境去測試，一旦測試沒有問題，才推到線上的環境，確保系統的穩定性。
如果只依靠穩定性，是不足以稱為可用性。可靠的微服務，必須可以受到使用者或者相依服務以及整個生態圈所信任，穩定性跟可靠性是密不可分的。
[CIO都在讀： 將IT回歸到組織內部以提昇敏捷性 ]
可靠性跟穩定性一樣，有幾個原則要求，譬如說確保整合測試是全面性的。另外，階段部署（Staging）、逐步部署（Canary）能夠部署成功，使得每個變更需求，都能確保成功的部署到線上環境，不影響或者傷害其他使用者或者相依的微服務正常運作。
透過在微服務中建立可靠性與可用性，有些資料必須要做快取（Cache），讓服務可以很快的去讀取其他資料，也確保自己本身服務的SLA，避免因為其他的相依服務帶來不利的影響。
在可擴充性方面，因為微服務的業務流量，很少是固定不變的，所以好的微服務應該是跟隨業務流量的增長，也可以呈現穩健的增長，可以輕鬆地對應流量的增長，而靈活的進行擴充。
所以可擴充的微服務，才能同時處理大量的任務和請求。為了確保微服務的擴充性，我們必須要知道他在質（如擴充網頁瀏覽數或客戶訂單數）和量（如每秒可以處理多少請求）這兩方面的增長規模，就可以針對增長規模去規劃，對未來的容量進行規劃，並識別出資源瓶頸和需求。
除此之外，微服務處理業務流量的方式，也要找到一個自動化的方式讓它自動擴充，才能隨時隨地做好處理高併發流量的準備，防止它們拖垮整個微服務的生態。說起來很容易做起來很難，但事實上，如果流量的處理方式無法進行擴充，開發人員將會眼睜睜地看著他們的微服務生態系統走向崩塌。
口述／孫培然 彙整／CIO編輯室
