口述／孫培然‧彙整／CIO編輯室
俗話說：「天下大勢，合久必分，分久必合」。現在的系統架構設計風格，隨著系統不斷的演進，已經逐步呈現出分分合合的變化，在整個變化過程中，因為技術框架的快速發展、使用者需求的不斷提升、雲計算多年來長足的發展等環境因素，也對應用系統架構風格產生了重大的影響。
其中微服務架構的盛行，因為解決了系統上可用性、可擴展、可維護性上的問題，已經成為眾多企業數位轉型不二之選的架構。
但在原有架構做數位轉型時，系統應該如何進行微服務拆解呢？要避免哪些陷阱？而不是說單體直接微服務就可以了，還是需要了解很多注意事項。為了要滿足使用者爆炸式增長的個性化需求，系統架構已經慢慢的從單體架構轉變的 SOA 架構。但由於 SOA 架構仍是屬於集中式的架構，所以在面對系統日趨龐大和複雜之後，企業服務匯流排（Enterprise Service Bus，ESB）卻會成為服務通訊的瓶頸。
因為微服務架構的服務變得更細緻化，可以透過 DDD（Domain Driven Design）讓每一個微服務達到服務自治，而不用透過集中式去統籌回應，服務之間就可通過輕量化的通訊機制去溝通。每一個微服務都圍繞著自己的具體業務單元進行建構，系統各服務間可以有機耦合的去解決問題，還可以保有互相合作，各自生長的狀態。
不要為了微服務而微服務
有幾個重點要提醒各位，就是不要為了微而微，因為微小化應該是結果，而不是目的。
[ 推薦下載： 2022年度CIO大調查報告PDF ]
所以微服務的第一個原則，其實就是「不要一開始就從微服務開始進行」。
也就是說，要等到應用程式變得又大又笨重的時候，而且在更新與維護時變得很複雜且困難時，此時才是開始介入以微服務來管理複雜性問題的時機。只有當你感受到單體式架構的痛苦及複雜性時，才值得開始考慮是不是要把很多大的單體，拆成小型的微服務。
我要強調的是，不是什麼東西都需要做微服務，而是要看情境是否需要微服務。
第二個原則就是「不要在沒有容器化下運行微服務」。因為微服務屬於分散式架構，在管理層面上，遠比像 SOA 這種集中式架構還要困難及麻煩，所以一定要先做好自動化或可監控的管理機制下才去實施。
也就是說，如果在還沒有適當部署和監控自動化或受管理容器化的情況下，為了解決眼前不斷蔓延的異質基礎架構，而嘗試建置微服務，會招來很多不必要的問題，請各位不要自己找麻煩。
第三個原則是「不要將微服務做得太小」。劃分微服務的時候，不要矯枉過正，如果您將微服務中的「微小」弄得太誇張，反而會失去它的內聚力，您很快就會發現自己會面臨很大的負擔跟複雜性，不但沒有得到微服務的好處，反而會得到一堆微服務的壞處。
所以最好的方式，是以高內聚力的大型服務為著眼點，在單體的部署變得越來越困難和緩慢、共用資料模型變得過於複雜，或者服務的不同部分具有不同的負載／擴充需求時，才將它們進行拆解，拆出適當的微服務。
第四個原則是「不要把微服務變成 SOA」。雖然前面講的是不要將微服務做得太小，但把微服務寫成跟以前 SOA 那樣的概念，也是錯的。微服務跟 SOA，雖然在最基本的層次上，兩者都有意建置可供其他應用程式使用的可重複使用個別元件，但兩者還是有些差別。
微服務跟 SOA 的差別在於，微服務屬於分散式架構，通常涉及重構應用程式，因此它比較容易管理；SOA 屬於集中式架構，著重在企業層面改變 IT 服務的運作方式。 SOA 必須要有中間的 ESB 來支撐，微服務則是服務跟服務之間的溝通，也就是中間是隱藏著一個共同標準協定去做溝通。
用微服務要確保資料一致性
使用微服務，其實是「水能載舟，亦能覆舟」，弄得不好反而會弄巧成拙。因為在微服務架構中，有很多可移動的模組，所以對服務的管理將變得更加複雜。
比如說，如果住院醫囑系統是單體架構，我只要把住院醫囑系統的執行檔發佈到線上主機就可以了。但如果住院醫囑拆成很多的小服務，你要發佈的服務可能就會是成百上千，這些成百上千的服務之間，又必須要做到無縫接軌，互相溝通，就必須要有服務註冊和服務發現解決方案，以便一個新的或者更新的服務，能夠讓自己被系統知道，能夠被其他服務偵測發現到。比如說你完成了一個小服務，你必須先註冊這個小服務，讓其他的服務知道有這個服務存在，而其他的服務也可以透過服務發現機制找到這個服務。
你也需要確保所有的服務都啟動並且在運行當中，不會耗盡磁碟空間或者其他資源，確保足夠的性能。一支微服務在運行時不可以把所有資源都吃掉了，還要考慮到服務跟服務之間的負載平衡，並且使用同步或非同步的消息發送來進行通訊。
所以使用微服務，要儘量透過叢集管理（Cluster management）和編排工具（Orchestration tools）做到自動化幫助你解決問題，還要有監控工具幫忙監視這些服務的健康狀況。另外，硬碟空間或者其他資源是不是可以依據容量的變化來自動擴縮容量。通常在容器化的生態系統裡面，就會提供很多監控或者熔斷機制，我們自己不用再花時間去研發這些工具，但一定要了解這些工具是如何進行工作。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ，與全球CIO同步獲取精華見解 ]
網路的壅塞和延遲也必須特別注意，因為單體架構的程式跟程式之間，是透過記憶體或 CPU 進行內部溝通。如果把單體拆成成百上千的服務，之間的溝通就要透過 API 來使用網路標準協定溝通，比如透過 RESTful API。
所以網路頻寬對微服務而言就變得非常重要。比如說有一個程式可能有數百個服務，每一個服務可能又要跨多個不同的服務，不難看出，如果網路方面沒有給予足夠的重視，將會對應用的整體性能造成多大的影響。
目前有幾種方式可以儘量減少網路的往返的流量，比如資料緩存和服務，來限制請求的流量或數量，這個就是微服務所講的熔斷機制，如果這個程式出現異常，一直在呼叫我的程式，我可能就會把你熔斷掉，也就是自動把你中斷掉。
另一個經常被忽略的地方是資料的序列化和反序列化。有時相同的資料從一個服務傳遞到另外一個服務，往往會被序列化和反序列化很多次時會大幅增加網路延遲。
要解決序列化的問題，你可以使用高效的序列化格式，並且在整個服務框架中使用這個共用的格式，減少資料服務之間傳遞數據的步驟，而不需要再次序列化。
再來是要確保資料的一致性，以前的單體架構的時代資料庫管理系統所講的 ACID 就是一次性的把所有的東西都串接做完，要嘛全部成功、要嘛全部失敗。但現在既然已經變成微服務，每一個微服務通常都會有它自己的狀態儲存，比如說掛號、醫囑各自是不同的程式或基本檔，你必須要面臨分散資料所帶來的資料一致性和完整性挑戰。
[ 閱讀所有孫培然的文章 ]
比如說，在開立藥品處方的服務時，在可能開立藥品處方之前，可能會去找另外一個服務當中需要引用的資料，比如藥品基本資料服務，如我要開的這些藥品是不是有庫存？庫存還夠不夠？或者說這個藥品是不是已經被刪除了或者停用，該服務中的資料完整性需要特別注意。
所以當每個服務中都有一些相同資料時，必須確保它的一致性。如果有某個服務，比如說藥品基本資料變更時，就必須要立即去通知其他的系統，這個資料已經變更，讓其他系統可以一起進行變更。
這就像之前的文章中提過的「事件驅動」。也就是說基本資料如果有異動、被刪除或者停用，就要通過事件驅動，去做到即時同步的概念，去通知其他會關心這些資料的系統，讓系統知道資料已經變動了。
所以在整個微服務架構當中，我們不能再用傳統的方式去做 ACID。而是要借助事件驅動或通知服務之類的模式，讓需要即時同步資料的使用者，可以馬上收到資料變動的訊息。
就好像一些 Youtube 網紅常常會跟觀眾講「按讚、分享、訂閱開啟小鈴鐺」這種「一鍵三連」的動作，只要資料有變化，就會自動發佈給已經訂閱這種變化和更新的資料，來做到資料同步一致性。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
