《我的專案筆記 #24》搞懂系統架構，讓你知道工程師在說什麼!!

某日，老闆突然說，我們的系統目標要乘載50萬會員同上，並且這50萬會員可以看到相同的資訊，研發同仁們各個驚嚇不已，某位技術主管說，這樣我們要改動整個系統架構，我們現在的系統是採用分區分流的方式…。

老闆就說，50萬會員同上是基本，我們之後好好聊一下可以怎麼改動。接下來，就可以看到整個研發團隊焦躁不安，想著怎麼說服老闆，不要改動系統架構。

年初的時候，公司的產品受到外部的連線攻擊，導致會員登入的入口網頁癱瘓，老闆這時候提說，有沒有辦法增加會員登入的進入點，這樣我們還有其他的入口可以提供給會員登入。技術人員就說，這樣我需要增加機器、對外連線的IP、調整系統架構，也需要提供不同入口的域名給會員。

常常，在開發過程中，我們會聽到工程師或是技術人員一直提到「系統架構」，可是卻又不是很明白什麼是「系統架構」。

如果去查查《維基百科》，就會得到下面這段文字：

系統架構是定義系統的結構、行為及其他視圖（view）的概念模型。架構敘述（architecture description）是有關系統的正式描述以及呈現，以有助於瞭解系統結構和行為的方式來組織。

系統架構可以包括系統中的組件以及子系統，這些元件以及子系統共同工作來實現整個系統。有許多人設法將描述系統架構的語言形式化，這些語言稱為架構描述語言（ADL）。

這根本就是寫給懂技術的人看的文字。

另外，就算去Google查，也只會得到下面這些資料，然後一頭霧水。

我也問過很多工程師「什麼是系統架構？」，不過得到的答案又都不一樣。

後來我漸漸明白，為什麼「系統架構」看起來就是很具體的東西，卻總是得到虛無飄渺的答案。

因為在開發過程中，提到的「系統架構」包含下列三種概念：

1. 業務層面：以User角度，去描述的「產品架構」，包含各種需求
2. 軟體層面：以RD角度，去描述的「軟體架構」，包含各種服務
3. 硬體層面：以IT角度，去進行的「硬體架構」，包含各種機器

簡單來說，依據產品需求，設計軟體系統架構，再依據軟體系統的需求，規劃機器佈署的架構。

不過，這樣說還是很抽象，以我最近常常在玩的遊戲《Rush Royale》為例，如下圖。

■什麼是「產品架構」？

所謂的「產品架構」，就是在將產品眾多的功能進行整理，最終產生的一個「架構圖」，如下圖。

以「玩家資訊系統」來說，主系統、子系統、功能的關係，如下圖。「玩家資訊系統」為一個主系統，其中的「郵件管理」則為一個「子系統」。而這個「郵件管理」的子系統，包含了「郵件列表、郵件內文、刪除郵件」三種功能。

在規劃產品架構的時候，若是只有「架構圖」的資料，其實還不夠，建議需要搭配上Wireframe(框線圖)或介面的示意圖。

為什麼這麼說？

一樣以《Rush Royale》為例，如下圖。用紅色框起的兩個部分，因為功能面相當接近，這時候技術在開發時，就有機會將這兩個部分設計為共用元件，在後期維護上，可以稍微減少重複修正BUG的數量。當然這只是有機會成為共用元件，如果未來這兩個區塊的功能有不同的規劃，那就無法成為共用元件。

■什麼是「軟體架構」？

軟體架構是有關軟體整體結構與組件的抽象描述，用於指導大型軟體系統各個方面的設計。軟體架構會包括軟體組件、組件之間的關係，組件特性以及組件間關係的特性。

–《維基百科》

簡單來說，「軟體架構」就是用來描述各系統、子系統或各組件間的關聯、溝通與通訊規則。其實，這樣說還是有點抽象。

讓我們用常見的「軟體分層架構」來說明，如下圖。

這樣看，其實也不容易看得懂，讓我們用最常用的系統功能「登入」來說明，如下圖。

使用者透過登入介面輸入帳號密碼，將帳密資訊進行登入驗證處理，也就是在「登入服務(LoginService)」中進行驗證，驗證過程中可能會從「玩家數據資料庫」中取用資料，驗證結果也會存放在「登入歷程資料庫」中。

※如果想要更加了解系統功能流程，可以參考這篇《搞懂系統功能流程》的文章。

■什麼是「硬體架構」？

其實所有的系統、功能或服務，都必須依靠某個「設備」才能運作，例如使用者介面，就必須透過螢幕顯示，可以是電腦螢幕，也可以是手機螢幕。而所有的系統都必須在某個伺服器上才能運行，而資料都必須存放在資料庫中，資料庫也會存在某個伺服器中。

以剛剛的「登入」來說，登入介面是透過手機，登入服務(Login Service)存在登入伺服器中，玩家數據資料及登入歷程資料，也會存放在相關的資料庫中。

另外，在設計硬體架構的時候，還會考量負載的問題，假設期望的同時登入玩家數量為20,000人，若一台登入伺服器乘載人數為5,000人，這個時候就考量「負載平衡」，甚至還要增加登入伺服器的數量，如下圖。

透過這樣的概念逐步拓展整個設備的架構，也因此常常會聽到工程師說，「要提升乘載量，那就加機器就好。」當然直接提升機器的數量或規格，是可以有效提升效能，但是這就是用金錢換取空間。

講了這麼多，回到剛剛提到「系統架構」包含的三種概念：

1. 業務層面：以User角度，去描述的「產品架構」，包含各種需求
→指的就是「規劃產品需求，包含各種系統、子系統、功能。」

2. 軟體層面：以RD角度，去描述的「軟體架構」，包含各種服務
→指的就是「依據產品需求，去規畫各種對應的系統服務，與各服務間的關聯及溝通。」

3. 硬體層面：以IT角度，去進行的「硬體架構」，包含各種機器
→指的就是「依據各系統服務，在設備上進行配置，並建立各服務間的連線與通訊。」

因此，當我們和研發人員溝通時，提到的系統架構，多半指的是軟體層面，也就是各項系統服務間的關聯；但是如果是和技術人員溝通時，提到的系統架構，指的就會是硬體設備，伺服器間的關聯。

搞懂系統架構，才能讓你知道工程師在說什麼!! 

《如果覺得這邊文章有幫到你，歡迎請我喝杯咖啡》

——–

大家好，我是 數位產品開發教練 – 陳俊聖/廣三/HeroMi
17年數位產品開發經驗。經手至少80個大小專案。
擅長解決與工程師的溝通問題，幫你建構工程思維。

合作邀約：info@hero-mi.com

*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。