編輯

核心啟動堆疊架構

Azure App Service
Azure Blob 儲存體
Azure 內容傳遞網路
適用於 PostgreSQL 的 Azure 資料庫
Azure 虛擬網路

您在大型公司中學到的許多教訓都不適用於初創公司的第一個堆疊。 在產品的初始 探索 階段中，您必須將部署優化，以達到速度、 成本和選擇性 。 選擇性是指您可以在指定架構內變更方向的速度。

在產品開發的擴充 或 擷取 階段中的企業 可能會使用服務導向或微服務架構。 這種類型的部署架構很少適合尚未找到產品/市場適合或商業牽引的初創公司。

針對核心啟動堆疊，簡單的整合型設計最好。 此設計會限制管理基礎結構所花費的時間，同時在啟動贏得更多客戶時提供充足的規模調整能力。

潛在的使用案例

本文提供簡單核心啟動堆疊的範例，並討論其元件。

架構

啟動 Contoso 已使用 Ruby on Rails 後端和 以 TypeScript 撰寫的 React 前端建置應用程式原型 。 Contoso 小組已在他們的膝上型電腦上執行示範。 現在，他們想要為其第一次客戶銷售會議部署應用程式。

雖然應用程式雄心勃勃，但還不需要複雜的微服務導向架構。 Contoso 選擇簡單的整合型設計，其中包含建議的啟動堆疊元件。

Diagram that shows the core startup stack architecture Contoso used to deploy their application.

下載此架構的 Visio 檔案 。

資料流程

在此核心啟動堆疊架構中：

  • Azure App 服務 提供簡單的應用程式伺服器來部署可調整的應用程式，而不需要設定伺服器、負載平衡器或其他基礎結構。
  • 適用於 PostgreSQL 的 Azure 資料庫 是領先開放原始碼關係資料庫管理系統 （RDBMS） 的 Azure 資料庫服務。 您可以專注于開發應用程式，而不是管理資料庫伺服器。
  • Azure 虛擬網絡 區隔網路流量，並保護內部服務不受網際網路威脅的影響。 您的應用程式伺服器會使用 虛擬網路整合 來與資料庫通訊，而不會暴露在網際網路上。
  • GitHub Actions 會將持續整合和持續部署 （CI/CD） 建置至原始程式碼管理。 GitHub Actions 對不同語言具有廣泛的支援，並與 Azure 服務進行強式整合。
  • Azure Blob 儲存體 儲存靜態資產，並將負載從應用程式伺服器移開。
  • Azure 內容傳遞網路 （CDN） 可透過全域網路加速將內容傳遞至使用者。
  • Azure 監視器 會監視和分析應用程式基礎結構中發生的情況。

核心啟動堆疊元件

複雜的堆疊可能會產生需要持續注意的 Bug。 複雜的架構可能會減去建置您的產品。 Bug 並非由複雜性所造成，但複雜的堆疊可讓您更輕鬆地寄送 Bug。 並非所有複雜的架構都是浪費能源，但如果您尚未找到適合的產品/市場，則會浪費您的資源。 您的第一個啟動堆疊應該很簡單，並擺脫您的方向，因此您可以專注于產品開發。

下圖顯示建議的核心啟動堆疊。 這些元件足以讓您的產品落地，並掌握在客戶手中。 對於 80% 的啟動，您只需要測試產品內建的基本假設。 在機器學習、物聯網（IoT）或高度管制環境中工作的初創公司可能需要更多元件。

A block diagram that shows a core startup stack.

CDN

一開始很少有客戶，CDN 可能還為時過早。 不過，將 CDN 新增至已在生產環境中的產品可能會產生非預期的副作用。 最好是預先實作 CDN。 CDN 會快取更接近客戶的靜態內容，並提供一個外觀，讓您能夠反覆運算 API 和架構。

應用程式伺服器

您的程式碼必須在某處執行。 在理想情況下，此平臺應該讓部署變得簡單，同時需要最少的作業輸入。 應用程式伺服器應該水準調整，但當您仍在探索階段時，某些手動調整操作就沒問題。

如同此堆疊的大部分，應用程式伺服器基本上應該自行執行。 傳統上，應用程式伺服器是虛擬機器，或是在裸機伺服器上執行的 Web 服務器實例。 現在，您可以尋找平臺即服務 （PaaS） 選項和容器，以移除作業額外負荷。

靜態內容

從您的應用程式伺服器提供靜態內容會浪費資源。 設定 CI/CD 管線之後，使用每個版本建置及部署靜態資產的工作十分簡單。 大部分的生產 Web 架構都會使用 CI/CD 部署靜態資產，因此最好先遵循此最佳做法。

Database

應用程式執行之後，您必須將資料儲存在資料庫中。 在大部分情況下，關係資料庫是最佳解決方案。 關係資料庫具有多個存取方法和經過時間測試的解決方案速度。 關係資料庫包括 Azure SQL 資料庫 、 適用於 PostgreSQL 的 Azure 資料庫 和 適用於 MariaDB 的 Azure 資料庫 。 某些使用案例需要檔資料庫或 NoSQL 資料庫，例如 MongoDB 或 Azure Cosmos DB 。

記錄匯總

如果您的應用程式發生問題，您想要花費盡可能少的時間來診斷問題。 藉由從頭匯總記錄和使用應用程式追蹤，可協助小組專注于問題本身。 您不需要存取應用程式伺服器上的檔案，並仔細查看記錄以取得監視資料。

持續整合與持續傳遞

缺乏可重複且快速的部署，是反復查看產品時速度最差的障礙之一。 設定良好的 CI/CD 管線可簡化應用程式伺服器上的程式碼部署程式。 快速且簡單的部署表示您快速看到勞動的結果。 頻繁整合可避免導致合併衝突的發散程式碼基底。

部署此案例

對於您使用 Dockerfile 建 置的大部分專案，概念和技術都相同。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

下一步