【從一台 Server 到分散式架構】第 01 篇：小明他們做了一個網站——一前、一後、一 DB
這是一個工程師創業的故事。
小明跟朋友想自己做點東西，決定做一個線上課程平台：讓使用者可以註冊、瀏覽課程、買課、看影片。他們從最簡單的版本開始——一個前端、一個後端、一個資料庫。前後端分離，後端跟資料庫可以跑在同一台機器，或分開也行。這就是這個系列的起點。
這一篇先不談會出什麼問題、要怎麼擴充，只把「最起點的架構」講清楚：請求到底是怎麼走的？什麼叫單體架構？為什麼在用戶還不多的時候，這樣就夠了？如果你已經會做前後端分離、會接 API、會連資料庫，這條路其實就是你熟悉的那條；這一篇只是把「請求從前端到後端再到 DB」這條流程講清楚，跟後面系列要講的架構演進對齊一下，讓起點清清楚楚。
前端、後端、資料庫：各做什麼？
小明他們的線上課程平台，就是一個前端、一個後端、一個資料庫。
- 前端：使用者打開瀏覽器、進到課程平台，看到首頁、課程列表、課程詳情、登入頁……。畫面和互動都在這裡，使用者點「看課程列表」、點「購買」，前端就根據操作發送請求。
- 後端：收到前端的請求之後，根據網址和參數判斷這次要做什麼（例如查課程列表、建立訂單、驗證登入）。接著向資料庫查詢或寫入——該查的查、該新增的新增、該更新的更新——再把拿到的資料組裝成前端要的格式（例如 JSON），回傳給前端。
- 資料庫：用戶資料、課程、訂單、學習進度都存在這裡。後端要查就查、要寫就寫。
三者各司其職。在用戶少、請求少的時候，這三樣就夠了。
請求是怎麼走的？從使用者到資料庫再回來
當使用者在課程平台上「點進課程列表」或「按下購買」的時候，實際上發生什麼事？
- 前端（跑在使用者瀏覽器裡的網頁或 App）根據使用者的操作，發送一個 HTTP 請求到後端的某個網址（例如
GET /api/courses或POST /api/orders）。 - 後端（跑在小明他們租的那台 server 上）收到請求，根據網址（例如
/api/courses）和參數判斷這次要執行哪一個功能——查課程列表、建立訂單、驗證登入……。 - 若需要讀寫資料，後端會連線到資料庫：查詢（SELECT）、新增（INSERT）、更新（UPDATE）……把結果拿回來。
- 後端把拿到的資料組裝成前端要的格式（例如 JSON），回傳給前端。
- 前端收到回應之後，把畫面更新（例如把課程列表畫出來、或顯示「購買成功」）。
整條路就是：使用者 → 前端 → 後端 → 資料庫（讀寫的時候），然後 資料庫 → 後端 → 前端 → 使用者。以課程平台來說：使用者點「課程列表」→ 前端發 GET /api/courses → 後端向資料庫查課程表 → 把結果回給前端 → 前端把列表畫出來。一條線，沒有分支、沒有多台機器分工，這就是這種架構的請求流程（request flow）。
小明他們的第一版就是這樣：前端有首頁、課程列表、課程詳情、登入／註冊、購買流程、影片播放頁；後端提供註冊、登入、取得課程列表、下單、已購課程、播放權限檢查等 API；資料庫存用戶、課程、訂單、學習進度。初期只有幾十到幾百個用戶，一台後端、一個資料庫就跑得很順，架構簡單、出問題也容易查。如果你寫過前後端分離的 side project 或 MVP，這條路你已經走過了；在用戶少的時候，這樣完全夠用。
什麼叫「單體架構」？
這種「一個後端程式、一個資料庫、對外提供所有功能」的作法，在系統設計裡常被叫做單體架構（monolith）。
什麼意思？就是：所有業務邏輯（用戶、課程、訂單、金流……）都寫在同一個後端專案裡；部署的時候，就是「把這一個後端程式跑起來」、連上「這一個資料庫」。沒有「課程服務」「訂單服務」分開跑，也沒有多台後端在做負載分流，就是一份程式、一台（或少數幾台）機器。
單體不是「爛」或「落後」，而是一種選擇。在用戶少、請求少、功能還在變的時候，這樣的架構其實已經足夠滿足現階段需求，因為架構簡單、好改、好 deploy，維運成本低，出問題也容易查。
小結：這是起點，不是終點
以小明他們的線上課程平台來說，請求從使用者一路走到資料庫、再走回來，是一條直線；這種「一個後端包辦所有邏輯、一個 DB 存所有資料」的架構，就是單體架構，也是很多 MVP 和 side project 的常態。
小明他們的線上課程平台，就從這裡開始。下一篇會看到：當使用者變多、流量上來，這套簡單架構會先遇到什麼問題，以及怎麼從「變慢、超時、錯誤變多」裡判斷瓶頸在哪裡。我們下一篇見。