核心启动堆栈体系结构

在大型公司中学到的许多教训并不直接适用于初创公司的第一个堆栈。 在产品的初始 探索 阶段，需要针对速度、成本和 可选性优化部署。 可选是指在给定体系结构中更改方向的速度。

在产品开发的 扩展 或 提取 阶段的业务可能会使用面向服务或微服务的体系结构。 这种类型的部署体系结构很少适合尚未找到产品/市场适合或商业牵引的初创公司。

对于核心启动堆栈，简单的整体设计最好。 此设计限制了管理基础结构所需的时间，同时在启动赢得更多客户时提供充足的缩放能力。

可能的用例

本文演示了一个简单的核心启动堆栈示例，并讨论了其组件。

建筑

一家初创公司 Contoso 构建了一个应用程序原型，其中包含 Ruby on Rails 后端和一个用 TypeScript 编写的 React 前端。 Contoso 团队一直在他们的笔记本电脑上运行演示。 现在，他们希望为他们的第一次客户销售会议部署应用。

虽然应用雄心勃勃，但它尚不需要复杂的微服务驱动体系结构。 Contoso 选择了一个简单的整体设计，其中包括建议的启动堆栈组件。

下载此体系结构的 Visio 文件。

数据流

在此核心启动堆栈体系结构中：

• Azure 应用服务 提供一个简单的应用服务器来部署可缩放的应用程序，而无需配置服务器、负载均衡器或其他基础结构。 应用服务支持容器部署，如以下示例所示，还支持适用于 ASP.NET、ASP.NET Core、Java、Ruby、Node.js、PHP 或 Python 的无容器部署。

• Azure Database for PostgreSQL 是领先的开源关系数据库管理系统（RDBMS）的 Azure 数据库服务。 你可以专注于开发应用程序，而不是管理数据库服务器。

  Azure 还提供 适用于 SQL、 MySQL、 MongoDB、 Apache Cassandra、 Gremlin 和 Redis 的托管数据库服务。

  除了托管产品/服务之外，Azure 市场还包括在启动体系结构中使用的数据库，例如 CockroachDB、 Neon 无服务器 Postgres 和 SQLite。

• Azure 虚拟网络 将网络流量分段，并保护内部服务免受 Internet 威胁的影响。 应用服务器使用 虚拟网络集成 与数据库通信，而不会暴露在 Internet 上。

• GitHub Actions 将持续集成和持续部署（CI/CD）构建到源代码管理中。 GitHub Actions 对不同语言具有广泛的支持，并与 Azure 服务有很强的集成。

• Azure Blob 存储 存储静态资产，并将负载移出应用服务器。

• 使用 WAF 的 Azure Front Door 通过全局内容分发网络（CDN）和 Web 应用程序防火墙向用户加速和保护内容分发。

• Azure Monitor 监视 和分析应用程序基础结构中发生的情况。

核心启动堆栈组件

复杂堆栈可以生成需要持续关注的 bug。 复杂的体系结构可能会削弱生成产品。 Bug 不是由复杂性引起的，但复杂的堆栈可以更轻松地交付 bug。 并非所有复杂的体系结构都是浪费能源，但如果尚未找到适合的产品/市场，它们会浪费资源。 你的第一个启动堆栈应该是简单的，并摆脱你的方式，以便你可以专注于产品开发。

以下简单关系图显示了建议的核心启动堆栈。 这些组件足以让你的产品脱离地面，并掌握客户之手。 对于 80% 的启动，此堆栈是测试产品中内置的基本假设所需的一切。 在机器学习、物联网（IoT）或高度管控环境中工作的初创公司可能需要更多组件。

CDN

一开始，很少有客户，CDN 似乎还为时过早。 但是，将 CDN 添加到生产环境中已有的产品可能会产生意外的副作用。 最好提前实现 CDN。 CDN 会缓存离客户更近的静态内容，并提供一个外观，可在其中循环访问 API 和体系结构。

应用服务器

代码需要在某个位置运行。 理想情况下，此平台应使部署变得简单，同时需要最少的作输入。 应用服务器应水平缩放，但一些手动缩放干预在仍处于探索阶段时是正常的。

与此堆栈中的大多数一样，应用服务器基本上应该自行运行。 传统上，应用服务器是虚拟机，或者是裸机服务器上运行的 Web 服务器实例。 现在，可以查看平台即服务（PaaS）选项（如应用服务上方和容器），以消除作开销。

静态内容

从应用服务器提供静态内容会浪费资源。 配置 CI/CD 管道后，使用每个版本生成和部署静态资产的工作是微不足道的。 大多数生产 Web 框架使用 CI/CD 部署静态资产，因此，最好先遵循此最佳做法。

数据库

应用运行后，需要将数据存储在数据库中。 在大多数情况下，关系数据库是最佳解决方案。 关系数据库具有多种访问方法和经过时间测试的解决方案的速度。 关系数据库包括 Azure SQL 数据库 和 Azure Database for PostgreSQL。 某些用例需要文档数据库或 NoSQL 数据库，例如 MongoDB 或 Azure Cosmos DB。

日志聚合

如果应用出现问题，你希望花费尽可能少的时间诊断问题。 通过聚合日志并使用从头开始的应用程序跟踪，可帮助团队专注于问题本身。 无需访问应用服务器上的文件并仔细查看日志以获取监视数据。

CI/CD

缺乏可重复且快速的部署是迭代产品时速度最差的障碍之一。 配置良好的 CI/CD 管道简化了应用服务器上的代码部署过程。 快速而简单的部署意味着快速查看劳动的结果。 频繁集成可避免导致合并冲突的发散代码库。 对于使用 Dockerfile 生成的大多数项目，概念和技术都是相同的。

供稿人

本文由Microsoft维护。 它最初是由以下贡献者撰写的。

主要作者：

• 安德鲁·哈维 |CTO 和启动大使

其他参与者：

• 尼克·沃德 |云解决方案架构师

后续步骤

• 使用 GitHub Actions 自动执行工作流

相关资源

• 用于启动的体系结构
• 云应用程序中的最佳做法
• 使用内容分发网络 (CDN) 的最佳做法
• Azure 应用程序的十项设计原则