上期談到傳統HIS架構面臨技術債的危機，因此期望透過微服務架構來重構HIS系統，拋棄舊有HIS的包袱，那如何開發出符合高品質標準的HIS微服務，將是另一個值得挑戰及探討的議題。
眾所皆知，微服務不可能獨立存在，各個服務之間存在互相依賴的關係，形成複雜的生態圈，而且複雜度會隨著服務的數量增加等因素，而呈現線性的增長。要確保整個生態的可用性，必須要制定更多的高品質標準。微服務要符合高品質標準，必須要遵循幾個原則。上期已經談過穩定性、可靠性及擴充性，緊接著就是容錯與災難預防能力、高效能，還有監控能力及文件化。
容錯與災難預防 以確保快速處理故障
一個具備容錯跟災難預防的微服務，可以承受來自內部和外部的故障。內部的故障，就是指服務本身的故障，比如說，沒有經過嚴格測試的程式缺陷導致部署失敗，會影響整個生態圈。外部故障，比如資料中心斷線了，或者生態圈某一部分的服務造成影響，也可能會影響到每個微服務和整個系統的穩定性跟可用性。
所以我們要對故障進行預測，意味著要比故障出現之前先行一步，做好對應的準備，針對服務、基礎建設跟整個生態圈，做可用性的測試，透過多樣化的彈性測試來實現。
[ 大師開講 ─ 衛生福利部資訊處處長龐一鳴：後疫情時代的智慧醫療 ]
第一步是程式測試，包括單元測試、回歸測試和整合測試；第二步是壓力測試，就是測試微服務跟基礎建設在面對大流量時，是否能夠維持可用性；最後也是最重要的混亂測試，也就是實際在線上的環境去驗證，安排很多不同故障情境，觀察這樣的測試是不是可以確保整個微服務跟基礎建設能夠快速的處理已知的故障狀況。
確保高效能 監控與調校不可少
高效能是在服務生態裡，可擴充性與微服務能夠處理的請求數量有關的另一個高品質標準。高效能主要是指微服務對請求的處理速度，要有一個好的高效能微服務，就是要充分的去使用現有的資源硬體和基礎建設，快速地處理請求，高效的執行任務，並且能夠隨時隨地接受效能的監控及調校能力。
監控系統乃是運維整個系統生命週期中最重要的一環，完善的監控可以讓我們事前及時發現故障，事後快速追蹤查找問題癥結。而在微服務生態圈中，系統分為多個層次，服務之間的路由相當的複雜，系統中需要監控的目標也非常多，如果沒有一個完善的監控系統就難以保證整體服務的高效能及穩定。
[ 加入 CIO Taiwan 官方 LINE 與 FB ，與全球CIO同步獲取精華見解 ]
從監控模組及系統分層的角度看，監控系統需要監控的範圍是非常廣泛的，但從微服務監控的角度來說，如果微服務是部署在Kubernetes雲原生環境中，那麼我們需要關注的監控模組主要就是Kubernetes叢集本身以及運行其中的微服務應用容器。例如對容器資源使用情況，如CPU使用率、記憶體使用率、網路、I/O等指標的監控。當然這並不是說，像實體主機、虛擬機器設備或者中間層軟體的監控我們不需要關注，只是這部分工作一般會有專門的人員去維護。而如果使用的是雲端服務，那麼雲端服務廠商大都已經為我們提供了監控支援。
在業務層監控也是監控系統所關注的一個重要內容，在實際場景中如果你只是讓應用程式穩定運行那是遠遠不足的。因此，我們常常會對具體業務產生的資料進行監控，例如網站系統所關注頁面瀏覽量或點擊量等訪問量（Page View）及訪問此網頁的不同 IP 位址的人數，即獨立訪客數（Unique Visitor ）等參數；後端如交易之類的微服務，我們則會關注門診量、開單成功率等。臨床業務指標也是體現醫院系統穩定性的核心要素。任何系統，如果出現了問題，在醫院最會先受到影響的大都是臨床業務指標。對於核心臨床業務指標的設定因具體的業務和場景而異，所以對於業務層的監控需要構建具備業務特點的業務監控系統，來確保醫院資訊系統維運正常。
文件化能夠減少技術債
由於微服務架構可能會帶來很多的技術債，所以必須要在整個微服務架構裡面，隨時隨地的更新系統文件，這也是採用微服務架構所要面臨的關鍵性挑戰。
一般來說，技術債與開發速度有關，服務會反覆的運算、變更、部署，而且會越來越多，越來越快，要怎麼去做到臨時的解決方案跟補丁，就是要在整個組織層面的微服務裡面，進行文件化。
文件化除了可以減少整個技術債，同時也會減少困惑，跟增長知識，加強對整個微服務架構狀況的理解。所以建構文件化的微服務要求，必須包括有詳細、最新以及集中式的檔案管理，其中包括微服務所有的相關資訊需求，讓所有的開發人員能夠充份瞭解微服務生態的相關運作功能。
遵守高品質標準才能擁有真正的開發自由
要實現高品質的微服務，首先就是要有一套可以應用在每個微服務上的標準原則，這些標準原則都要由我們團隊自己制定及遵循，且必須要滿足每一個微服務在線上環境都可以處理的流量，確保整個系統的高可用性。
有了標準之後，我們就必須要知道，如何在真實的微服務生態系統裡去實現。從理論到實際，總是有一定的難度，但在整個高品質服務裡面，有個很有力的可行性跟細節程度，它們必須要套用整個微服務的生態系中，又能提供更好、更紮實的實作策略細節。
很多開發人員可能會去抗拒這些標準，他們會辯證說，採用微服務架構不就是為了速度、自由跟效率嗎？為什麼還要訂定這些標準。確實，微服務架構可以為開發團隊帶來自由跟效率，但這也是高品質標準發揮作用的地方。
[ 下載 2020-21 CIO大調查報告，掌握IT最新趨勢 ]
標準化的要求，必須在各組織的各個層面展開，不僅要由上而下，還要求從下到上。上層的領導者，必須要求整個工程組織及專案，要落實標準原則，而每一個員工，也就是每個開發團隊，也都需要接受並且執行這些標準，最關鍵的就是，不要將標準化看成是一堵限制開發或者部署的牆，而是應該把它當作實現高品質的指南。
如果不堅持或者遵守高品質標準原則，一旦有服務故障失效，可能導致破壞整個微服務生態系統的可用性，或者當一個本來可以通過適當的彈性測試及部署流程，來避免拖垮故障的整個微服務生態都不去遵循，那麼開發上的自由和效率，也就會慢慢失去了意義。
如果說，我們對 50 年前的軟體發展有所瞭解，就會知道標準化會帶來自由並減少混亂。就是 Brooks 在他的《人月神話》裡所說的，我們是要真正的自由呢？還是形式的自由？就在於你要不要去遵循所規劃的標準。
微服務架構讓服務上線更好更快
整個工程組織接納高品質標準之後，下一步就是要詳細的定義每一個標準的細節及具體的要求，需要結合具體的環境以及特定的組織細節，實現策略並且理解它們。
要做好這些工作，就是要針對每個高品質原則和要求，提出真正的實現方案。例如，如果組織的微服務生態中，裡面有一個自助部署工具，我們就要去實現一個穩定可靠的部署流程，把這個流程跟整個工具考慮的運作原理做好整合，重新建構內部工具，或者給它們添加新的功能，也需要遵循標準原則。
所以不管是開發人員、團隊主管、管理層及維運人員（包含系統、 DevOps 或是 SRE 維運），都要能實現這些要求，他們可以自己判斷一個微服務是否滿足這些要求，也就是依照標準去尋求工具，根據尋求的工具來建置屬於自己團隊的標準。
所以，建構跟維護高品質的微服務生態，不是一件很容易的事。不過，如果做的好，我們可以從中獲得很大的好處，微服務的可用性也會因此得到保證。
高品質標準原則為我們提供了可衡量結果，讓團隊可以看到所依賴的服務是可信任的，具備了穩定性、可靠性、容錯能力、災難預防、高性能、監控能力和文件化的能力。
我們也可以透過DevOps有效地應用工具，協助團隊快速且可靠的為用戶進行部署跟創新。此外，可擴展性、更彈性化及自動化，靈活的使用新的框架、函式庫和其他資源，加上整個微服務及DevOps都是以雲端架構為基礎，所以透過DevOps和微服務的檢核，可以讓我們提高生產力的水準。
（口述／孫培然‧彙整／CIO編輯室）
