三種不同實現難度的微服務應用
微服務架構的實現也可以很簡單
談到微服務架構（MSA, Micro-Service Architecture），許多人就會感覺到恐慌，因為微服務帶來的議題太多，從基礎設施（Infrastructure）、維運議題、開發測試、軟體架構以及組織規範，處處都是充滿待解決的問題。
很多人好不容易容器化了，卻發現離微服務還有一大段路；學會了領域驅動設計（DDD, Domain-Driven Design），卻發現系統帶來的技術問題讓我們下不了手；費盡心思，搞懂了微服務架構種種開發的設計模式及技術細節，卻發現必須要自己想辦法實現太多架構層面的機制，都輪不到開始動工真正有商業意義的業務邏輯。
微服務架構的實現，真的是一條崎嶇難走的路嗎？真的會把什麼應用都搞得太複雜嗎？我們到底要怎麼評估一個應用，在採用微服務架構後的實現難易度呢？
本文將應用分成三大類型，探討不同類型的設計難易度，作為評估參考。
無資料管理需求的應用
以微服務的思維實現軟體架構，最容易落實的是無資料管理的應用，由於無任何資料管理、狀態管理的需求，只要 單純實現「業務邏輯」即可。常見的是一些功能型服務，例如運算處理、沒有資料庫系統的簡易資訊查詢或是轉接需求的中間服務。
這種應用，通常是無狀態（Stateless）的服務組成，你可以簡單採用 serverless 的開發思維就能實現，而且不太有副作用，也無須了解微服務的各種設計模式。
雖然難免會有處理會話狀態（Session）的需求，但可以透過用戶端保存會話狀態的實作來解決，例如 Cookie-based session 和 JWT Token 等，這樣一來，由於 Session 狀態是跟著連線要求一起傳入服務，服務無需自己保存或管理 Session。
註：Session 的管理和檢查問題可以交給已經成熟的 API Gateway 來解決。
資料不落地的即時應用
另一個容易實現微服務架構的應用，是單位資料組成簡單、尺寸小的即時應用，例如即時通訊（IM）、影音多媒體、遊戲、資料不落地的系統。這種應用下，因為資料內容、工作狀態、任務生命週期以及資料的擁有權都是跟著資料走，而資料的尺寸又容許能被快速在服務之間轉移傳遞，所以服務的設計只要專心在自己的任務上和事件管理即可。
因此，這算是只要熟悉 MQ 系統，懂得進行任務拆分，就能掌握的微服務應用。也很剛好，微服務架構很適合做這類即時應用的設計，能夠針對業務邏輯做清楚的拆分和管理，又無需處理資料、服務狀態的種種情況。
同時具有商業邏輯和資料處理的應用
通常最常見、最難、也是最讓企業頭痛的，是資料結構較大且伴隨著業務邏輯的應用和系統群，例如有交易行為的電商系統、金融系統等。
這類應用會帶來系統內服務之間資料分享共用的問題，例如領域邊界交集處的資料分享和交換機制、避免集中式資料管理被大量服務的內部存取所擊潰等。由於這類業務需求，需要同時對任務與資料進行解耦、拆分，其手段和考量點非常多，設計上也就相對棘手。
面對這種應用，開發者和架構師，需要同時掌握「領域驅動設計、相關拆分服務的策略」，也要能熟悉如何「應用並實現各種微服務架構模式」，以同時解決服務層面和資料層面的架構設計，缺一不可。
要知道，微服務架構講的服務拆分，其範疇除了常聽到針對業務邏輯的領域設計之外，最重要的還是各種分散式資料管理（Distributed Data Management）的方法和技術架構，如果不能同時熟悉兩者，很難將微服務架構真正的落實。
此外，此類應用從分散式資料角度來看，又可以分成兩級難度。
對資料一致性較寬鬆的應用
如果資料和任務工作本身沒有直接成敗關聯性，即便引入分散式設計，通常問題比較沒這麼複雜。可以藉由自己實現事件驅動、簡單的資料同步或是直接引入 CQRS 模式即可解決需求。只要我們使用的方法，能保證資料「最終能夠保持一致性」即可，沒有太高的時限、業務需求的直接壓力。
訂單之後的物流系統就屬此類應用，對任務狀態的改變、資料的傳遞，沒有要求一定要在幾秒、幾毫秒內達成，此應用對資料甚至容許一定程度的延遲，只要最後的資料狀態能夠同步，達成整個系統的一致即可。
對資料一致性較嚴格的應用
對於嚴重依賴任務狀態的資料來說，分散資料的管理就延伸了另一個嚴重的議題「交易（Transaction）」。由於一個任務相關的資料被拆解分散在不同服務中管理，我們在執行任務時要保證有限時間內，於多個服務間達成資料狀態一致，就變成是一種硬性的需求。此時，跨服務的「分散式交易機制」，就變成一個必要的實現。此類應用，如訂單與庫存系統、錢包、帳務系統等。
另外，隨著交易狀態同步時間要求越短，系統設計的難度就越大幅升高，甚至不得不與一些原則進行妥協。因為分散式架構下，延遲性和缺乏原子性是一大難點。還好，這樣極端的需求並不是非常多，我們視情況再來處理即可。
總結
三種應用的微服務架構實現，可依照需求分為三種程度的能力對應：
- 商業邏輯實現
- 業務拆分
- 領域設計與分散式資料管理設計
而前面兩者相對來說簡單許多，也不涉及太多架構模式和設計方法，基本上只要是技術人員，通常能夠勝任。而最後一種應用，才是大家最頭痛的問題。還好，最後一種應用也不完全都是很複雜的需求。至於困難與否，可以用資料一致性的需求強弱，來評估其架構實現的困難度。
大體上來說，評估一個系統是否能容易導入微服務架構，能單純從「資料和業務相依性」來看出一些端倪。而實現微服務架構時，通常多半閃躲不掉的分散式資料管理與交易機制議題，也是導致許多人「用 DDD 將服務拆完後，做不出來的最後關鍵」。
由此可知，導入開發流程、容器化部署機制、serverless、事件機制，只能算是起手式而已，若沒有考慮資料管理層面的設計，其實也只是另一個三層式架構或是單體式架構。
相信已經有太多文章、言論恐嚇你微服務架構的困難，但卻很少人提到，微服務架構所發展出來的各種資料管理機制，其實能夠直接應用在舊有的系統上。這些技術，能在不影響既有系統運行的情況下，低風險協助舊系統改善效能、增加服務開發速度，或是提高彈性、穩定性。
也許您該考量的是，在不全面推翻舊有架構的前提之下，先享受微服務相關技術所帶來的好處。等對微服務各類機制和技術都極為熟悉時，再逐步改造既有系統，以轉型成微服務架構。
最後，如果您對微服務架構及其生態有任何疑問，或是需要技術上的評估與建議，歡迎與我們 Brobridge 聯絡，取得專業的教育訓練和顧問服務。
