後端系統設計的思考架構

本篇詳細解說本收錄在 E+ 的後端系統設計專題

在前一篇的 前端系統設計的思考架構 文中，我們談了前端系統設計可以用的思考框架，在這一篇我們將談後端系統設計可以用的思考架構。特別備註，這篇會談的後端系統設計，是指一般軟體工程師、後端工程師，或者全端工程師會要做的系統設計。

不論是在實際工作或者面試，如果在做系統設計時，你不知該如何下手，相信這篇可以給你一個基本的思考架構。

後端系統設計的思考架構

在做後端系統設計時，我們推薦可以用三步驟來協助思考，這三步驟分別是

• 需求探索 (Requirements)
• 架構建立 (Architecture)
• 深入設計 (Deep dive)

如同在前端篇談到的，要設計出適當的系統，會需要先釐清需求，才能確保解決到對的問題。而在定義完需求後，接著要根據需求來建立系統的架構，在這階段要確保整體架構能呼應需求。最後針對系統的特性 (例如需要高可用，或者高一致性) 來深入設計。

讓我們進一步來看這個架構的三步驟分別可以如何運用。

需求探索 (Requirements)

不論在實際工作，或者在後端系統設計的面試，經常會遇到需求沒有清楚定義的時候。從工作的角度看，產品經理會從產品的角度出發提需求，然後許多需求需要深入考慮技術可行性，這時就會需要由工程端進一步提問題釐清，透過多個角度，把整個系統設計地更完整。

而從面試的角度看，因為面試官會想檢驗候選人是否具備探索需求、釐清需求的能力，往往在面試最開始，不會把所有訊息完整跟候選人說，這時會需要候選人主動提釐清的問題，來確保有解決到最關鍵的問題。

不論在工作或面試，當遇到一個需求，如果沒有釐清，會是工程師的大忌。先前 Meta 主任工程師 Ryan Peterman 分享到，初階工程師會抱怨產品經理的敘述不夠清楚；資深工程師則會主動協助把不清楚的地方理清楚。如果想要往資深邁進，有任何模糊不清處的地方，務必要在最開始就釐清。

當然，如果從面試的角度來說，因為時間有限，盡量可以在最開頭的五分鐘，把關鍵點問清楚。通常這會分成兩個區塊，分別是功能需求，以及非功能需求。

功能需求

功能需求是從使用者的角度來看，可以使用「使用者要能夠...」做為開頭句來思考。可以從產品的角度來思考，產品要提供給使用者什麼功能。同時可以思考有哪些功能是必要的，哪些是相對次要的。

例如以設計一個動態牆系統來說，貼文、追蹤等功能是一定需要，但是按讚、通知可能不一定在最開始就是必要的。假如你沒有辦法確定哪個是必要的，就提出釐清問題把它確定下來。

非功能需求

而非功能需求則是從系統的角度來看，可以使用「系統要能夠...」做為開頭句來思考。在思考非功能需求時，可以把這類需求理解成品質。舉例來說，「高可用性」是系統設計中很常會有的非功能需求，在一個系統中，就算可用性很低，也仍能夠達到其功能，只是會讓人覺得品質很差；而當能夠照顧好非功能需求，就會讓人覺得系統的品質好。

常見的非功能需求包含：

• 例如有多少使用者，要擴展到什麼量級?
• 對於延遲 (latency) 的要求是什麼?
• 可用性或一致性之中，比較看重哪一個?

但要特別注意，在一個系統中，可能不同的子系統，會有不同的非功能需求的要求。舉例來說，舉例來說，在一個電商系統當中，商品展示的部分會需要高可用，但一致性要求可能還好；而在訂單部分為了避免重複下單，會需要高一致性，這種情況可用性可以相對被犧牲。

所以盡可能釐清時，不要通則地說「這個系統要高可用」，而是要去釐清功能需求中，不同的功能分別有哪些特性，並依照這些特性，來思考子系統要滿足哪些非功能需求。

另外，在釐清非功能需求時，也要確保是足夠明確的。舉例來說，「系統要高可用」是相對抽象不具體的，比較好的描述會是這個系統的可用性要達到幾個 9。

什麼不在討論範圍中 (out of scope)

除了討論功能與非功能需求，列清楚什麼不在討論範圍內 (out of scope) 也是非常重要的。在現實工作中，很多系統中的非主要元件，很可能早就有現成的能使用。

舉例來說，權限相關的問題，很可能公司已經有可以用的現成 SDK 可以串。因此在現實工作中，這些就不會是討論重點。同樣的道理，在面試中也有很多不是該系統的重點面向，這時不推薦大家花時間在那些面向的討論 (畢竟面試時間有限的)。

進一步說，在面試當中，去討論什麼在範圍、什麼不再範圍，可以展示出「自己有排定優先順序的能力」，這會加分很多，因此特別推薦在面試時，可以特別拉出來跟面試官確認，例如可以說「從剛剛的釐清中，我認為以下這些對這個系統來說，不是最重要的，或許我們可以先不用深入談。不知你覺得這樣如何?」。

本文為 E+ 成長計畫的深度內容，截取前三分之一開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)