iT邦幫忙

2021 iThome 鐵人賽

DAY 2
0
Modern Web

基於 Kotlin Ktor 建構支援模組化開發的 Web 框架系列 第 2

[Day 2] 從單體式遷移至微服務架構,支援模組化開發的 Web 框架可以解決什麼問題?

近年微服務架構興起,對於規模較小的開發團隊而言,一開始就拆分為多個微服務是個沉重的負擔,所以大多還是從單體式架構 monolithic 出發,往後再逐步拆分為微服務。雖然這種開發方式廣泛被採用,但實務上並不是所有團隊都能輕鬆轉換至微服務架構,這取決於單體式架構裡的各個功能實作上是否能低耦合,甚至模組化。

另一方面,即使往後將各個功能拆分成微服務,因為通常拆分的時間點不一, 或是由不同的工程師負責實作,如果沒有事先規劃及規定統一的作法,就容易導致各個微服務在基礎設施功能方面的實作方式上有所差異,提高了往後開發及維運的成本。

本專案是以模組化為準則的單體式架構,在底層的基礎設施函式庫上建立多個子專案,當未來要將子專案拆分為微服務時,能把轉換工作降至最低。規劃子專案的方式,除了可以採用 Backend for Frontend (BFF) 的方式,簡單地把多個前端與有商業邏輯的後端分開之外,也可以遵循 DDD 的概念,將每個子專案對應到一個 Bounded Context。

Gradle Multi-Project Builds

在專案結構上,為了讓各個子專案儘量獨立不耦合,我採用 Gradle Multi-Projects Build 分隔子專案,強迫開發者意識到這是一段跨專案依賴呼叫的程式碼,未來拆分為微服務時,將會從直接函式呼叫改為遠端呼叫。

Multi-Project Architecture

在架構設計方面,每個子專案都會有一個 projectId,因為底層的基礎設施函式庫多考慮了 project 維度,而且產生的資料也已經記錄了 projectId,當未來要把子專案拆分為微服務時,將會輕鬆許多,例如 Logging 功能會記錄這個請求是由那個 project 處理。除了 projectId 之外,每個子專案還可以定義自己的 User Type 及 User Role,還有 Notification Type,讓商業邏輯 Domain Model Object 可以獨立分開,然而底層的 API 權限檢查、寄送訊息通知…等功能實作程式碼都是相同的。

Ktor Module

在實作及部署方面,每個子專案都是一個 Ktor Module,我們可以根據 Ktor Module 本身的設計,修改設定檔中的 ktor.application.modules 屬性值來決定要部署那些子專案。如果一個子專案沒有被部署,則執行期不會進行任何初始化動作,也就不會部署任何 API。理論上,我們可以把 A, B 2個子專案分開部署,然後設定 nginx 或 API Gateway 重新導向,如果發現 A 專案緊急有 Bug 需要修正,那麼 B 專案將不會被影響,即使 A, B 都是在同一個單體式架構開發的。不過我覺得這是單體式架構不得已的作法,所以也不是很推薦採用就是了。

這2天已說明我的 side project 目標、設計概念、實作項目及要解決的問題,明天開始就要進入實作程式碼。


上一篇
[Day 1] 微解封 微服務 那你有聽過微框架嗎? 又為何我選擇 Ktor?
下一篇
[Day 3] 以 Ktor Module 實作模組化開發
系列文
基於 Kotlin Ktor 建構支援模組化開發的 Web 框架30

尚未有邦友留言

立即登入留言