什麼是Web應用架構？剖解網路應用程式

世界已經轉移到網際網路上，網路應用已經成為新的工作場所和商業商店。為了適應現代網路應用的各種目的，每一個網路應用都需要被設計成高效能和可定製的。

網路應用架構解決了這個問題。

網路應用程式架構定義了基於網路的應用程式的各個組成部分是如何結構化的。這種架構對於網路應用的性質和目的來說是非常具體的。為你的網路應用程式選擇錯誤的架構會對你的業務造成嚴重的破壞。

在本指南中，我們將分解網路應用程式架構的概念，並瞭解它如何影響你的應用程式的終端使用者體驗。最後，我們還將看看你可以實施的一些最佳實踐，以獲得你的網路應用的最大收益。

1. 什麼是網路應用程式架構？
2. 為什麼網路應用程式架構很重要？
3. 網路應用程式架構是如何工作的？
4. 網路應用程式架構的型別
5. 網路應用程式架構的層級
6. 網路應用程式元件
7. 網路應用程式架構的最佳實踐

什麼是網路應用程式架構？

為了拉開討論的序幕，讓我們從網路應用架構的定義開始。

簡單地說，網路應用程式架構是你的網路應用程式的各種元件如何相互作用的一個大綱。

它可以簡單到定義客戶端和伺服器之間的關係。它也可以是複雜的，如定義容器化後端伺服器群、負載均衡器、API閘道器和麵向使用者的單頁前端之間的相互關係。

這就是說，很少有人會選擇用哪種程式語言來寫程式碼。

你如何設計你的網路應用程式對其可用性和成本優化都起著關鍵作用。下面是一個網路應用程式架構樣本的紙面情況。

一個推薦應用程式的架構圖（圖片來源：維基百科）

為什麼網路應用程式架構很重要？

毫無疑問，網路應用程式架構是你的網路應用程式中最重要的部分之一。如果你選擇以特定的架構來開發你的網路應用，那麼在維護和發展你的應用時，你肯定會收到許多好處。

然而，選擇正確的架構可以進一步放大這些好處。

以下是你應該認真考慮採用網路應用程式架構的一些首要原因。

輕鬆適應業務需求

你的應用程式是你業務的一個關鍵門戶，而業務需求隨著市場的變化而變化。為了與時俱進，你會希望你的應用程式足夠靈活，以適應你不斷變化的業務需求。如果你在建立一個應用程式時沒有考慮到內建的靈活性，你必然會花費越來越多的時間和精力來對你的應用程式進行微小的調整。

正確的網路應用程式架構已經考慮到了你的業務在未來可能需要的一些變化。例如，如果你知道你正在建立一個電子商務應用程式，該應用程式將在某一天擴充套件並滿足大量客戶的廣泛服務，那麼選擇一個微服務架構而不是單體架構將為你提供更多的靈活性。

另一方面，如果你正在為公司建立一個只有一兩個固定需求的內部應用，你可以選擇一個更簡單的微控制器，以加快開發速度並保持程式碼庫的清潔。

有組織的發展

正如我們前面提到的，正確的網路應用程式架構為你提供了一個更方便的開發路線圖。架構在你的系統中提供了足夠的模組化，以便在必要時隔離元件，你可以根據需要為每個模組和元件自由選擇合適的專案結構。

如果你在沒有考慮到架構的情況下潛入應用開發，你就有可能浪費時間和金錢來重新組織你的元件和制定新的規則，以幫助促進團隊成員之間的協作–這些時間和金錢本來可以用在其他地方。

更好的程式碼庫管理

除了編寫你的應用程式的程式碼，你還會花相當多的時間來管理它。組織你的專案檔案，將你的應用程式分解成模組，並設定自定義管道，這些只是需要積極維護以確保順利開發的少數任務。

正確的網路應用程式架構使你很容易做出改變。你可以實施特定元件的最佳實踐，將你的應用程式的痛點彼此分開，並保持每個功能的獨立和鬆散耦合。這並不是說沒有架構就不能做這些
事情，只是正確的架構讓所有這些事情變得更加簡單。

遵循預先定義的架構也使你很容易更快地開發你的應用程式。正確的架構與完善的版本控制策略相結合，可以使你的開發人員相互平行工作，更快地構建功能。

一個網路應用程式架構還能使你的應用程式面向未來。一旦你圍繞如何組織你的應用程式的元件定義了一個堅實的戰略，你可以很容易地將這些元件逐一遷移到較新的技術，而不必重新做你的整個應用程式。

增強安全性

大多數網路應用程式架構在構建元件時都考慮了安全因素。開發人員可以提前計劃實施的措施和做法，以便在向使用者推出之前提高應用程式的安全性。

例如，使用微服務構建一個同時提供付費和免費內容的OTT視訊流應用更有意義，因為微服務架構使你能夠將你的應用分割成業務友好的元件，如使用者認證和免費或付費內容流。如果你的使用者認證模組出現故障，你可以很容易地配置你的應用程式，限制對付費內容模組的訪問，直到認證恢復，而免費內容模組仍然可以為你的使用者提供。

在另一種情況下，同樣的應用程式被設計成緊密耦合的單體，認證服務癱瘓將意味著應用程式癱瘓或付費內容被免費提供–你會想不惜一切代價避免這種結果。

網路應用程式架構是如何工作的？

在我們談論網路應用程式架構如何工作之前，重要的是要了解一個簡單的網站如何工作：

1. 使用者在瀏覽器的位址列中輸入你的應用程式的URL或點選一個連結。
2. 瀏覽器在DNS伺服器中查詢該URL，並確定你的應用程式的IP地址。
3. 瀏覽器向你的應用程式傳送一個HTTP請求。
4. 你的應用程式以正確的內容（通常是一個網頁）作出反應。
5. 瀏覽器將網頁呈現在螢幕上。

如果你再深入一點，以下是一個網路應用如何處理一個請求：

1. 使用者通過你的前端使用者介面向你的應用程式傳送一個請求。
2. 如果你設定了相關的快取，應用程式會首先檢查它是否有一個有效的記錄，可以直接發回給客戶端。如果有，快取的內容就會被送回來，而請求將被標記為完成。
3. 如果沒有快取，請求將被轉發到負載平衡器。
4. 負載平衡器確定一個可以處理請求的伺服器例項，並將其轉發。
5. 伺服器例項處理請求並在需要時呼叫任何外部API。
6. 一旦在一個地方收集到結果，伺服器就會將響應發回給負載均衡器。負載均衡器將響應返回給API閘道器，而API閘道器又將其下發到前端客戶端的使用者手中。然後，該請求被標記為完成。

網路應用程式架構的型別

現在你對什麼是網路應用程式架構有了一個基本的概念，讓我們詳細瞭解一下整個網路應用程式架構的一些流行型別。

單頁結構

單頁應用程式（SPA）的架構和它的名字一樣簡單：整個應用程式基於一個單頁。一旦使用者拉起你的應用程式，他們不需要導航到任何其他網頁。該應用被做成動態的，足以在使用者瀏覽應用本身時獲取和呈現符合使用者要求的螢幕。

當涉及到為終端使用者或消費者提供快速和無縫的體驗時，SPA是很好的。然而，它們缺乏傳統網站的觸感，而且它們可能難以為搜尋引擎優化。

SPA架構的優點

SPA架構的一些優點包括：

• 你可以建立高度互動的網路應用。
• SPA很容易擴充套件。
• 優化SPA的效能並不需要太多的努力。

SPA架構的缺點

SPA架構的幾個缺點是：

• SPA限制了超連結和SEO的靈活性。
• 最初的渲染通常很慢。
• 通過該應用程式的導航可能是不直觀的。

漸進式網路應用程式架構

漸進式網路應用程式（PWA）架構建立在單頁架構之上，為您的網路應用程式提供離線功能。Capacitor和Ionic等技術被用來構建PWA，可以為使用者提供跨平臺的統一體驗。

與SPA類似，PWA是平滑和無縫的。由於增加了安裝在使用者裝置上的能力（通過服務工作者），你的使用者在你的應用程式上得到了更統一的體驗。

同時，為搜尋引擎優化這類應用程式可能很困難，而且已安裝的應用程式的更新也很難推動。

PWA架構的優點

PWA架構有許多好處，包括：

• 應用程式執行非常流暢，並提供跨平臺的相容性。
• 可擴充套件性很簡單。
• 開發人員可以訪問離線訪問和裝置原生API，如後臺工作者和推送通知。

PWA架構的缺點

PWA架構的一些缺點可能包括。

• 對連結管理和SEO的支援有限。
• 向離線的PWA推送更新比本地應用程式更復雜。
• 各個網路瀏覽器和作業系統對PWA的支援都很有限。

伺服器端渲染的架構

在伺服器端渲染（SSR）中，前端的網頁在被使用者請求後在後端伺服器上進行渲染。這有助於減少客戶端裝置的負載，因為它收到的是靜態HTML、CSS和JS網頁。

SSR應用程式在部落格和電子商務網站中非常流行。這是因為它們使連結管理和SEO變得相當簡單。此外，SSR應用程式的首次渲染是相當快的，因為客戶端不需要處理任何JS程式碼來渲染螢幕。

SSR架構的優點

下面列出了SSR架構的一些優點：

• 這些應用程式對於SEO重的網站來說是非常好的。
• 在大多數情況下，第一頁的載入幾乎是即時的。
• 你可以將它與快取服務配對，以進一步提高你的應用程式的效能。

SSR架構的缺點

使用SSR架構的幾個缺點包括：

• 對於複雜或繁重的網頁，不建議使用這種方法，因為伺服器可能需要時間來完全生成頁面，導致首次渲染延遲。
• 它主要被推薦給那些不太關注使用者介面，只想提高可擴充套件性或安全性的應用程式。

預先渲染的應用程式架構

預先渲染的應用程式架構也被稱為靜態網站生成架構。在這種架構中，應用程式的前端網頁是預先生成的，並作為普通的HTML、CSS和JS檔案儲存在伺服器上。一旦使用者請求一個頁面，它就
被直接獲取並顯示給他們。這使得網路應用非常快，任何型別的載入時間都最小。

然而，這種架構增加了應用程式的構建時間，因為網頁是在構建過程中渲染的。當你想生成靜態內容，如部落格或不經常變化的產品細節時，預渲染的網頁應用程式是很好的選擇。你還可以利用模板來簡化你的網頁設計。然而，使用這種架構幾乎不可能建立動態的網路應用。如果你想建立一個以查詢為路徑的搜尋頁面（類似 https://myapp.com/search/foo+bar），你就找錯地方了。

由於應用程式的每條可能的路線都是在構建過程中預先渲染的，所以不可能有上述的動態路線，因為有無限的可能性，在構建過程中無法預先渲染（而且這樣做也沒有意義）。

預渲染架構的優點

預渲染應用程式架構的幾大好處是：

• 網頁是用純HTML、CSS和JS生成的；因此其效能與使用vanilla JS構建的應用程式相似。
• 如果你知道你的應用程式的所有可能的路線，SEO就會變得超級容易。

預渲染架構的缺點

與任何建築模型一樣，預渲染也有其缺點：

• 動態內容不能通過這些應用程式提供。
• 對網路應用的任何改變都意味著完全重建並從頭部署該應用。

同構的應用架構

同構應用程式是那些混合了伺服器端渲染的應用程式和SPA的應用程式。這意味著這類應用首先在伺服器上被渲染成普通的伺服器端渲染的應用。一旦被客戶端接收，該應用就會將自己水化，並附加上虛擬DOM，以便更快、更有效地進行客戶端處理。這實質上將應用程式變成了一個單頁應用程式。

Isomorphic將兩個世界的優點結合起來。由於SPA的存在，你可以在客戶端獲得超快的處理和使用者介面。由於伺服器端的渲染，你還可以得到快速的初始渲染和成熟的SEO和連結支援。

同構式架構的優點

以下是使用同構式應用架構的一些好處：

• Isomorphic應用程式具有超快的初始渲染和對SEO的全面支援。
• 這些應用程式在客戶端也表現良好，因為它們在載入後變成了SPA。

同構式架構的缺點

同構應用架構的一些缺點可以是：

• 設定這樣的應用程式需要熟練的人才。
• 當涉及到設計一個同構的應用程式時，技術棧的選擇是有限的。你只能從少數幾個（大部分）基於JS的庫和框架中選擇。

面向服務的架構

面向服務的架構是最受歡迎的替代傳統的微控制器構建應用程式的方式之一。在這種架構中，網路應用被分解為代表每個業務功能單元的服務。這些服務被鬆散地耦合在一起，並通過訊息傳遞的媒介相互作用。

面向服務的架構為你的應用技術棧增加了穩定性和可擴充套件性。然而，SOA中的服務規模沒有明確的定義，通常與業務元件而不是技術元件相聯絡；因此，維護有時會成為一個問題。

面向服務的架構的優點

面向服務的架構的主要好處包括：

• 這種架構有助於建立高度可擴充套件和可靠的應用程式。
• 元件是可重複使用的，並被共享以加強開發和維護工作。

面向服務的架構的缺點

這裡列出了使用面向服務架構的潛在缺點：

• SOA應用程式仍然不是100%的靈活，因為每個服務的規模和範圍都不固定。可能會有企業應用程式大小的服務難以維護。
• 元件共享引入了服務之間的依賴性。

微服務架構

微服務架構的設計是為了解決面向服務架構的問題。微服務是更加模組化的元件，它們配合在一起構建一個網路應用。然而，微服務專注於保持每個元件的小型化和有邊界的上下文。有界限的上下文字質上意味著每個微服務的程式碼和資料都耦合在一起，對其他微服務的依賴性最小。

微服務架構可能是構建旨在有朝一日擴充套件到數千乃至數百萬使用者的應用程式的最佳架構。每個元件都是有彈性的，可擴充套件的，並且易於維護。然而，維護基於微服務的應用程式的DevOps生命週期需要額外的努力，因此它可能不適合較小的用例。

微服務架構的優點

微服務架構的一些優點包括：

• 與面向服務架構的元件相比，應用程式元件具有高度的模組化、獨立性，並且可以在更大程度上被重複使用。
• 每個元件都可以獨立擴充套件，以滿足不同的使用者流量。
• 基於微服務的應用程式具有高度的容錯性。

微服務架構的缺點

微服務架構的一個缺點可能是：

• 對於較小的專案，微服務架構可能需要太多的精力來維護。

無伺服器架構

無伺服器架構是網路應用程式架構世界中的另一個熱門加入者。這種架構的重點是將你的應用分解為它應該執行的功能。然後，這些功能被託管在FaaS（Function-as-a-Service，功能即服務）平臺上，當有請求時被呼叫。

與本列表中的大多數其他架構不同，使用無伺服器架構構建的應用程式不會一直保持執行。它們的行為就像函式一樣–等待被呼叫，並在被呼叫後，執行所定義的流程並返回結果。由於這種性質，它們減少了維護成本，並且不費吹灰之力就能高度擴充套件。然而，使用這種元件很難執行長期執行的任務。

無伺服器架構的優點

以下是無伺服器架構的主要好處：

• 無伺服器應用程式具有高度和輕鬆的可擴充套件性。它們甚至可以實時適應進入的流量，以減少基礎設施的負載。
• 這類應用程式可以利用無伺服器平臺的按使用量付費的定價模式來降低基礎設施成本。
• 無伺服器應用程式的構建和部署相當容易，因為你所要做的就是編寫一個函式並將其託管在Firebase函式、AWS Lambda等平臺上。

無伺服器架構的缺點

以下是無伺服器架構的一些弊端：

• 在這樣的架構上，長期執行的任務可能成本很高。
• 當一個函式在很長時間後收到一個請求時，它被稱為冷啟動。冷啟動很慢，會給你的終端使用者帶來不好的體驗

網路應用程式架構的層級

雖然你在上面看到的網路應用程式架構可能看起來都很不一樣，但它們的元件可以邏輯地組合成明確的層，幫助實現業務目標。

表示層

表示層指的是網路應用中暴露給終端使用者的一切。主要來說，表示層是由前端客戶端組成的。然而，它也包含了你在後端編寫的任何邏輯，以使你的前端動態化。這為你提供了空間，使你可以根據使用者的情況和要求定製UI，為使用者提供服務。

三個基本技術被用來建立這個層。HTML、CSS和JavaScript。HTML描述了你的前端，CSS為它設計了樣式，而JS則為它注入了活力（即，當使用者與它互動時控制它的行為）。在這三種技術之上，你可以使用任何一種框架來幫助你的開發變得簡單。一些常見的前端框架包括Laravel、React、NextJS、Vue、GatsbyJS等。

業務層

業務層負責持有和管理你的應用程式的工作邏輯。它通常是一個後端服務，接受來自客戶端的請求並處理它們。它控制使用者可以訪問的內容，並決定如何利用基礎設施來服務於使用者請求。在酒店預訂應用程式的情況下，你的客戶端應用程式作為一個門戶，供使用者輸入酒店名稱和其他相關資料。

然而，一旦使用者點選搜尋按鈕，業務層就會收到請求並啟動邏輯，尋找符合你要求的可用酒店房間。然後，客戶只是收到一個酒店房間的列表，而不知道這個列表是如何生成的，甚至不知道為什麼列表中的專案會以它們被髮送的方式排列。

這樣一個層的存在確保了你的業務邏輯不會暴露給你的客戶，最終也不會暴露給使用者。隔離業務邏輯對處理支付或管理健康記錄等敏感業務有極大的幫助。

持久層

持久層負責控制對你的資料儲存的訪問。它在你的資料儲存和你的業務層之間充當了一個額外的抽象層。它從業務層接收所有與資料相關的呼叫，並通過與資料庫的安全連線來處理它們。

這一層通常由一個資料庫伺服器組成。你可以通過在你的內部基礎設施中配置一個資料庫和一個資料庫伺服器來自己設定這一層，或者選擇一個由領先的雲基礎設施供應商如AWS、GCP和Microsoft Azure等提供的遠端/管理的解決方案。

網路應用程式元件

現在你已經瞭解了網路應用程式架構的內容，讓我們來詳細瞭解一下構成網路應用程式的每個元件。我們將討論分為兩個大標題–伺服器端元件和客戶端元件，或後端和前端元件。

伺服器端元件

伺服器端元件是那些駐紮在你的Web應用後臺的元件。這些元件並不直接暴露在使用者面前，而是為你的網路應用儲存最重要的業務邏輯和資源。

DNS & Routing

DNS負責控制你的應用程式是如何暴露在網路上的。DNS記錄被HTTP客戶端（也可以是瀏覽器）用來尋找和傳送請求到你的應用程式的元件。DNS也被你的前端客戶在內部使用，以解決你的網路伺服器和API端點的位置，以傳送請求和處理使用者操作。

負載平衡是網路應用架構的另一個流行的組成部分。負載平衡器被用來在多個相同的網路伺服器之間分配HTTP請求。擁有多個網路伺服器背後的意圖是保持冗餘，這有助於提高容錯能力，以及分配流量以保持高效能。

API端點是用來向前端應用程式暴露後端服務的。這些有助於促進客戶端和伺服器之間的通訊，有時甚至是多個伺服器之間的通訊。

資料儲存

資料儲存是大多數現代應用程式的關鍵部分，因為總有一些應用程式的資料需要跨使用者會話持續存在。資料儲存有兩種型別。

• 資料庫：資料庫是用來儲存資料以實現快速訪問的。通常情況下，它們支援儲存少量的、被你的應用程式定期訪問的資料
• 資料倉儲：資料倉儲是用來儲存歷史資料的。這些資料在應用程式中通常不是經常需要的，但會定期處理以產生業務洞察力。

快取

快取是一種可選的功能，通常在網路應用程式架構中實現，以更快地向使用者提供內容。很大一部分應用程式的內容通常在一定時間內是重複的，即使不是一直如此。與其從資料儲存中訪問它並在將其送回給使用者之前對其進行處理，不如將其快取起來。下面是在整個網路應用中使用的兩種最流行的快取型別：

• 資料快取：資料快取為你的應用程式提供了一種方法，可以輕鬆快速地訪問經常使用的、不經常變化的資料。諸如Redis和Memcache等技術可以實現資料快取，以節省昂貴的資料庫查詢，而這些查詢只是為了重複檢索相同的資料。
• 網頁快取：CDN（內容交付網路）快取網頁的方式與Redis快取資料的方式相同。類似於
  只有不經常變化的資料才會被快取，通常只有靜態網頁才被建議快取。對於伺服器端渲
  染的網路應用，快取的作用不大，因為其內容應該是高度動態的。

工作和服務

除了向使用者暴露介面（前端）和處理他們的請求（後端）之外，還有另一類稍不流行的Web應用元件。工作通常是後臺服務，旨在完成不具時間敏感性或同步性的任務。

CRON作業是那些在固定時間段內反覆執行的作業。這些工作是在後檯安排的，在設定的時間自動執行維護程式。一些常見的例子包括從資料庫中刪除重複的/舊的記錄，向客戶傳送提醒郵件，等等。

客戶端元件

客戶端元件是那些直接或間接暴露給使用者的元件。這個類別中主要有兩種型別的元件。

前端使用者介面

使用者介面是你的應用程式的視覺方面。它是你的使用者為了訪問你的服務而看到的和與之互動的東西。

前臺介面主要是建立在三種流行的技術上。HTML、CSS和JavaScript。前端使用者介面本身可以是一個應用程式，有自己的軟體開發生命週期。

這些使用者介面並不容納你的很多業務邏輯，因為它們直接暴露在你的使用者面前。如果一個惡意的使用者試圖對你的前端應用程式進行逆向工程，他們可以獲得關於你的業務如何運作的資訊，並進行品牌冒充和資料盜竊等非法活動。

另外，由於前端的使用者介面直接暴露在使用者面前，你要對其進行優化，以達到最小的載入時間和響應能力。有時這可以幫助你為使用者提供更好的體驗，從而提高你的業務增長。

客戶端業務邏輯

有時你可能需要在你的客戶端儲存一些業務邏輯，以便快速執行更簡單的操作。通常駐留在你的前端應用程式內的客戶端邏輯可以幫助你跳過前往伺服器的旅程，為你的使用者提供更快的體驗。

這是客戶端元件的一個可選的功能。在某些情況下，應用程式的業務邏輯完全儲存在客戶端（特別是在沒有傳統後臺伺服器的情況下構建）。諸如BaaS這樣的現代解決方案可以幫助你在前端應用中隨時訪問常見的操作，如認證、資料儲存、檔案儲存等。

在向使用者推廣之前，有一些方法可以混淆或簡化這些程式碼，以減少反向工程的機會。

網路應用程式元件的模式

網路應用程式架構有多種模式，每種模式都是基於網路伺服器如何連線到其資料儲存。

一個伺服器，一個資料庫

最簡單的模型是一個網路伺服器連線到一個資料庫例項。這樣的模型很容易實現和維護，而且在生產中使用它也是相當容易的。

由於其簡單性，這種模式適用於學習和不會暴露於高流量的小型實驗性應用。新手開發者可以輕鬆地設定和修補這些應用程式，以學習網路應用程式開發的基本原理。

然而，這種模式不應該在生產中使用，因為它是非常不可靠的。伺服器或資料庫的問題都可能導致停機和業務損失。

多個伺服器，一個資料庫

這種模式通過設定多個伺服器的冗餘和一個共同的資料庫例項，將應用提高了一個檔次。

由於多個網路伺服器同時訪問資料庫，可能會出現不一致的問題。為了避免這種情況，網路伺服器被設計為無狀態。這意味著伺服器不保留跨會話的資料；它們只是處理資料並將其儲存在資料庫中。

使用這種模式製作的應用程式當然比以前的模式更可靠，因為多個Web伺服器的存在增加了Web應用程式的容錯性。然而，由於資料庫仍然是一個共同的例項，它是架構中最薄弱的環節，可能成為故障的來源。

多個伺服器，多個資料庫

這種模式是最常見的、傳統的設計網路應用的模式之一。

在這種情況下，將你的應用邏輯部署為多個相同的Web伺服器例項，並在負載平衡器後面將其聚集在一起。你的資料儲存也在多個資料庫例項中維護，以增加容錯。

你也可以選擇在可用的例項中拆分你的資料庫以提高效能，或者維護整個資料儲存的副本以實現冗餘。在任何一種情況下，你的資料庫的任何一個例項的故障都不會導致應用程式的完全中斷。

這種模式因其可靠性和可擴充套件性而受到高度讚賞。然而，使用這種模式開發和維護應用程式是相對複雜的，需要昂貴的、經驗豐富的開發人員。因此，這種模式只建議在你大規模建設時使用。

應用服務

雖然上面提到的三種模式很適合單體應用，但還有一種模式適合模組化應用。

應用服務模型根據業務功能將一個應用程式分解成更小的模組。這些模組可以小到一個功能，大到一個服務。

這裡的想法是使每個業務功能獨立和可擴充套件。這些模組中的每一個都可以獨立連線到資料庫。你甚至可以有專門的資料庫例項來配合你的模組的可擴充套件性需求。

在非微控制器應用中，這種模式相當流行。傳統的微控制器經常被遷移到這種模式，以利用其可擴充套件性和模組化的優勢。然而，管理建立在這種模式上的應用程式往往需要經驗豐富的開發人員，特別是在DevOps和CI/CD方面的經驗。

網路應用程式架構的最佳實踐

這裡有一些最佳實踐，你可以在你的網路應用程式專案中實施，以獲得你所選擇的網路應用程式架構的最大收益。

1. 使你的前臺具有響應性

這一點怎麼強調都不為過。始終以響應式前端為目標。無論你的網路應用內部有多龐大和複雜，它都是通過前端的網頁、應用和螢幕暴露在你的使用者面前。

如果你的使用者發現這些螢幕是不直觀的或緩慢的，他們就不會停留足夠長的時間來檢視和欣賞你的網路應用的工程奇蹟。

因此，設計可訪問的、易於使用的、輕量級的前臺是非常重要的。

網路上有大量的UI/UX最佳實踐，可以幫助你瞭解什麼對你的使用者最有效。你可以找到擅長製作使用者友好型設計和架構的專業人士，他們可以使你的使用者從你的應用程式中獲得最大的收益。

我們建議在向使用者推出你的產品之前，認真考慮你的前端的響應性。

2. .監控載入時間

除了易於理解之外，你的前臺還需要快速載入。

根據Portent，最高的電子商務轉換率發生在載入時間在0-2秒之間的頁面上，根據Unbounce，大約70%的消費者承認，頁面載入時間是他們選擇從網上賣家購買的一個重要因素。

在設計移動原生應用程式時，你通常無法確定你的使用者的裝置規格。任何不符合你的應用程式要求的裝置通常被宣佈為不支援該應用程式。

然而，這與網路是完全不同的。

當涉及到網路應用時，你的使用者可能使用任何東西，從最新的蘋果Macbook M1 Pros到老式的黑莓和諾基亞手機來檢視你的應用。為如此廣泛的使用者優化你的前端體驗，有時會很困難。

談到前端效能時，人們會想到LightHouse和Google PageSpeed等服務。在將你的前端應用部署到生產中之前，你應該使用這樣的工具來對其進行基準測試。大多數這樣的工具為你提供了一個可操作的提示列表，以幫助儘可能地提高你的應用程式的效能。

應用的最後5-10%的效能通常是針對你的用例的，只能由熟悉你的應用及其技術的人解決。對網路效能進行投資永遠不會有壞處!

3. 在可能的情況下首選PWA

如前所述，PWA是未來的設計。它們可以很好地適應大多數的使用情況，而且它們在主要的平臺上提供最統一的體驗。

你應該儘可能多地考慮為你的應用程式使用PWA。跨越網路和移動的原生體驗對你的使用者有巨大的影響，同時也可以減少你自己的很多工作量。

PWA的載入速度也很快，易於優化，而且構建迅速。選擇使用PWA可以幫助你在早期將大量的注意力從開發轉移到業務上。

4. 保持你的程式碼庫簡潔明瞭

一個乾淨的程式碼庫可以幫助你在造成損害之前發現並解決大多數問題。下面是一些你可以遵循的提示，以確保你的程式碼庫不會給你帶來任何不必要的麻煩。

• 專注於程式碼重用。在整個程式碼庫中維護相同程式碼的副本不僅是多餘的，而且還可能導致差異的出現，使你的程式碼庫難以維護。始終專注於盡可能地重複使用程式碼。
• 規劃你的專案結構。軟體專案會隨著時間的推移而變得非常龐大。如果你開始時沒有計劃好程式碼組織和資源的結構，你最終可能會花更多的時間去尋找檔案而不是寫有用的程式碼。
• 編寫單元測試。每一塊程式碼都有可能被破壞。手動測試所有的程式碼是不可行的，所以你需要一個固定的策略來對你的程式碼庫進行自動測試。測試執行器和程式碼覆蓋率工具可以幫助你確定你的單元測試工作是否產生了預期的結果。
• 高度模組化。在編寫程式碼時，要始終關注模組化。編寫與其他程式碼緊密耦合的程式碼會使其
  難以測試、重複使用和在需要時進行修改。

5. 自動化你的CI/CD流程

CI/CD是持續整合/持續部署的意思。CI/CD流程對你的應用程式的開發至關重要，因為它們可以幫助你輕鬆地構建、測試和部署你的專案。

然而，你不希望每次都要手動執行它們。相反，你應該建立管道，根據你的專案活動自動觸發。例如，你可以建立一個管道，在你提交程式碼到版本控制系統時自動執行你的測試。也有很多更復雜的用例，比如每當建立一個版本時，從你的程式碼庫中生成跨平臺的人工製品。

可能性是無窮無盡的，所以要看你如何能使你的CI/CD管道發揮最大作用。

6. 納入安全功能

大多數現代應用程式是由多個元件組成的。以下面這個應用程式為例：

無伺服器網路應用架構的例子

客戶端請求是通過API閘道器轉到應用程式的。雖然這個閘道器目前只允許直接請求到應用程式的主模組，但在未來，它可以允許訪問更多的元件，而不需要通過主模組。

接下來，主頁模組在允許訪問之前檢查外部認證BaaS。一旦通過認證，客戶可以訪問 “更新資料 “或 “檢視資料 “頁面。這兩個頁面都與處理檔案資料的通用管理資料庫解決方案互動

正如你所看到的，該應用程式似乎是一個非常基本和最小版本的線上人物目錄。你可以新增/更新你自己的個人資料或檢視其他可用的個人資料。

這裡有一個關於架構中各個組成部分的快速圖例：

• Blue boxes: 應用模組，可能作為微服務或無伺服器功能託管。
• Red boxes: 提供認證和資料庫的外部BaaS元件。
• Green box: 路由元件，對來自客戶端的傳入請求進行調節。
• Black box: 你的客戶端應用程式暴露在使用者面前。

上述每種顏色的元件都容易受到各種安全威脅。這裡有一些安全結構，你可以把你的風險降到最低：

• 應用程式模組（藍色）: 由於這些是無伺服器的功能，這裡有一些加強其安全性的提示:
  • 隔離應用程式的祕密，並獨立於你的原始碼進行管理
  • 通過IAM服務維持訪問控制
    改進你的測試工作，通過SAST等技術尋找安全威脅。
• 外部服務（紅色）:
  • 通過其IAM模組設定訪問控制，以規範訪問
  • 選擇API速率限制
    對於資料庫等服務，要設定更精細的控制許可權，比如誰可以訪問配置檔案的資料，誰可以檢視使用者的資料，等等。許多服務，如Firebase，提供了一套詳細的此類規則。
• 路由元件（綠色）:
  • 像所有其他元件一樣，實施訪問控制
  • 設定授權
    仔細檢查標準的最佳做法，如CORS
• 客戶:
  • 確保你的客戶無法獲得任何應用程式的機密資訊
    混淆你的客戶端程式碼，以減少逆向工程的機會

雖然這些只是一些建議，但它們說明了一個問題，即應用安全是複雜的，你有責任確保不給攻擊者留下任何漏洞。你不能依靠一箇中央安全元件來保護你的業務；應用程式的安全是分佈在你的應用程式架構中。

7. 收集使用者反饋

使用者反饋是瞭解你的應用程式在業務和技術效能方面表現如何的重要工具。你可以建立世界上最輕、最流暢的應用程式，但如果它不能讓你的使用者做他們期望的事情，那麼你所有的努力就會付諸東流。

有多種方法來收集使用者反饋。雖然快速和匿名的調查是傳統的方法，但你也可以選擇更復雜的解決方案，如使用者活動的熱圖。

選擇收集反饋的方法不如對收集到的反饋採取行動重要。客戶喜歡那些傾聽他們問題的企業。像麥當勞和特斯拉這樣的巨頭都是這樣做的，這也是他們在市場上持續成功的原因之一。

小結

網路是一個巨大的遊樂場，裡面有各種各樣的應用程式，每一個都以自己獨特的方式設計。多種型別的架構為網路應用的多樣化、蓬勃發展和為全球使用者提供服務創造了條件。

在本指南中，我們分解了網路應用程式架構的不同模式，並向你展示了它們對一個應用程式的發展有多麼關鍵。