MEAN Stack-是否應該分離服務器？

Question

我正在使用MEAN堆棧進行個人項目，非常感謝您在設置服務器體系結構時應該采取的路線建議。 性能和可擴展性對我來說很重要，因為我將來想構建企業級的Web應用程序。

該項目將是一個圖像托管應用程序，它將包括前端，專用API和文件存儲系統。

選項1：全部在同一台服務器上

選項2：同一台服務器上的前端API和專用API。 文件存儲在單獨的服務器上。

選項3：前端，專用API和文件存儲都在自己的服務器上。

我認為選項2可能是最好的選擇，但是我很想向那些在構建具有類似架構的應用程序方面有經驗的人學習。

謝謝！

Answer 1

根據您期望的規模以及您希望在服務器基礎結構上花費的金額，適合不同的情況。 我將盡力解釋這兩者的優點。

• 對於所有基於API的服務，它們應位於可擴展的基礎架構上。 因此，它們主要是服務器形式，始終位於負載平衡器之后。 根據流量類型和區域進行縮放。 為此，當前業界最喜歡的是基於docker的微服務。 另一個可比較的解決方案是Google App Engine。
• 對於所有基於前端/ UI的內容，應將它們存儲在CDN上以優化交付。 使用CDN，您可以確保即使基於私有API的服務運行緩慢，最終用戶仍可以使用應用程序的UI。 CDN價格便宜，對您的最終用戶有很大的影響。
• 對於圖像/文件存儲，應使用基於Blob存儲的解決方案。 如今，您的服務器HDD大多是SSD，而且價格不菲。 此外，這些磁盤已連接到服務器，因此確實容易出現錯誤或安全問題。 使用Blob存儲非常有用，因為它可以處理冗余和可擴展的存儲以及某種形式的安全性。

使用此模型，您將確保文件安全且遠離業務邏輯，即使您的核心服務很慢，您的最終用戶也可以訪問您的Web應用程序，並且可以輕松地管理基於API /服務的擴展服務器。

Answer 2

您不應該直接烘焙服務器架構。 但是要一路測量並改善所需的缺少功能。

因此，一開始我會采用相同的服務器方法 。

但是將Frontend設計為無服務器架構 。

創建用於讀取/寫入的專用API和單獨的文件存儲API 。 這些可以是隨時可以擴展的微服務。

您可以將片段托管在其他雲上，也可以使用自己的片段垂直/水平或地理縮放。

因此，您可以將縮放部分烘焙到設計中，但僅在需要時縮放。

基本上，您現在唯一需要注意的是，您的體系結構已分解為多個部分，因此您可以在需要時進行擴展。

注意 ：以下是有關該主題的兩個不錯的讀物： 基礎設施即代碼 ， 構建微服務