核心啟動堆疊架構

Azure App Service

Azure Blob 儲存體

Azure 內容傳遞網路

適用於 PostgreSQL 的 Azure 資料庫

Azure 虛擬網路

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

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

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

潛在應用情境

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

建築

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

備註

Ruby、React 和 TypeScript 在這裡的技術選擇只是說明。 此啟動架構同樣適用於許多其他語言和架構。

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

下載此架構的 Visio 檔案。

數據流

在這裡核心啟動堆疊架構中：

• Azure App Service 提供簡單的應用程式伺服器來部署可調整的應用程式，而不需要設定伺服器、負載平衡器或其他基礎結構。 App Service 支援容器部署，如這裡範例所示，也支援 ASP.NET、ASP.NET Core、Java、Ruby、Node.js、PHP 或 Python 的無容器部署。

• 適用於 PostgreSQL 的 Azure 資料庫 是領先開放原始碼關係資料庫管理系統 （RDBMS） 的 Azure 資料庫服務。 您可以專注於開發應用程式，而不是管理資料庫伺服器。

  Azure 也有適用於 SQL、 MySQL、 MongoDB、 Apache Cassandra、 Gremlin 和 Redis 的受控資料庫服務。

  除了受控供應專案之外，Azure Marketplace 也包含啟動架構中使用的資料庫，例如 CockroachDB、 Neon 無伺服器 Postgres 和 SQLite。

• Azure 虛擬網路 會區隔網路流量，並保護內部服務不受因特網威脅的影響。 您的應用程式伺服器會使用 虛擬網路整合 來與資料庫通訊，而不會暴露在因特網上。

• GitHub Actions 會將持續整合和持續部署 （CI/CD） 建置至原始程式碼管理。 GitHub Actions 對不同語言具有廣泛的支援，並與 Azure 服務進行強式整合。

• Azure Blob 記憶體 會儲存靜態資產，並將負載從應用程式伺服器移開。

• 具有WAF的 Azure Front Door 可透過全域內容傳遞網路 （CDN） 和 Web 應用程式防火牆，加速和保護使用者的內容傳遞。

• Azure 監視器 會監視和分析應用程式基礎結構中發生的情況。

核心啟動堆疊元件

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

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

CDN

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

應用程式伺服器

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

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

靜態內容

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

資料庫

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

記錄匯總

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

CI/CD

缺乏可重複且快速的部署，是反覆查看產品時速度最差的障礙之一。 設定良好的 CI/CD 管線可簡化應用程式伺服器上的程式碼部署程式。 快速且簡單的部署表示您快速看到勞動的結果。 頻繁整合可避免導致合併衝突的發散程式代碼基底。 對於您使用 Dockerfile 建置的大部分專案，概念和技術都相同。

貢獻者們

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主要作者：

• 安德魯·哈威 |CTO 和啟動大使

其他貢獻者：

• 尼克·沃德 |雲端解決方案架構師

後續步驟

• 使用 GitHub Actions 將工作流程自動化

相關資源

• 新創企業的架構
• 雲端應用程式中的最佳做法
• 使用內容傳遞網路的最佳做法 （CDN）
• Azure 應用程式的十項設計原則

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

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

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

潛在應用情境

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

建築

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

備註

Ruby、React 和 TypeScript 在這裡的技術選擇只是說明。 此啟動架構同樣適用於許多其他語言和架構。

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

下載此架構的 Visio 檔案。

數據流

在這裡核心啟動堆疊架構中：

• Azure App Service 提供簡單的應用程式伺服器來部署可調整的應用程式，而不需要設定伺服器、負載平衡器或其他基礎結構。 App Service 支援容器部署，如這裡範例所示，也支援 ASP.NET、ASP.NET Core、Java、Ruby、Node.js、PHP 或 Python 的無容器部署。

• 適用於 PostgreSQL 的 Azure 資料庫 是領先開放原始碼關係資料庫管理系統 （RDBMS） 的 Azure 資料庫服務。 您可以專注於開發應用程式，而不是管理資料庫伺服器。

  Azure 也有適用於 SQL、 MySQL、 MongoDB、 Apache Cassandra、 Gremlin 和 Redis 的受控資料庫服務。

  除了受控供應專案之外，Azure Marketplace 也包含啟動架構中使用的資料庫，例如 CockroachDB、 Neon 無伺服器 Postgres 和 SQLite。

• Azure 虛擬網路 會區隔網路流量，並保護內部服務不受因特網威脅的影響。 您的應用程式伺服器會使用 虛擬網路整合 來與資料庫通訊，而不會暴露在因特網上。

• GitHub Actions 會將持續整合和持續部署 （CI/CD） 建置至原始程式碼管理。 GitHub Actions 對不同語言具有廣泛的支援，並與 Azure 服務進行強式整合。

• Azure Blob 記憶體 會儲存靜態資產，並將負載從應用程式伺服器移開。

• 具有WAF的 Azure Front Door 可透過全域內容傳遞網路 （CDN） 和 Web 應用程式防火牆，加速和保護使用者的內容傳遞。

• Azure 監視器 會監視和分析應用程式基礎結構中發生的情況。

核心啟動堆疊元件

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

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

CDN

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

應用程式伺服器

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

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

靜態內容

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

資料庫

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

記錄匯總

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

CI/CD

缺乏可重複且快速的部署，是反覆查看產品時速度最差的障礙之一。 設定良好的 CI/CD 管線可簡化應用程式伺服器上的程式碼部署程式。 快速且簡單的部署表示您快速看到勞動的結果。 頻繁整合可避免導致合併衝突的發散程式代碼基底。 對於您使用 Dockerfile 建置的大部分專案，概念和技術都相同。

貢獻者們

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主要作者：

• 安德魯·哈威 |CTO 和啟動大使

其他貢獻者：

• 尼克·沃德 |雲端解決方案架構師

後續步驟

• 使用 GitHub Actions 將工作流程自動化

相關資源

• 新創企業的架構
• 雲端應用程式中的最佳做法
• 使用內容傳遞網路的最佳做法 （CDN）
• Azure 應用程式的十項設計原則