核心启动堆栈体系结构

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

处于产品开发扩展或提取阶段的业务可能使用面向服务或微服务体系结构。 此类型的部署体系结构并不适合尚未找到产品/市场或商业吸引力的初创企业。

对于核心启动堆栈，最好采用简单的整体式设计。 此设计减少了管理基础结构所花费的时间，同时提供了充足的缩放能力，让初创公司赢得更多客户。

可能的用例

本文提供简单核心启动堆栈的示例，并讨论其组件。

体系结构

初创公司 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 是一项 Azure 数据库服务，适用于领先的关系数据库管理系统 (RDBMS)。 你可以专注于开发应用程序，而不是管理数据库服务器。 Azure 还提供适用于 SQL、MySQL、MariaDB、MongoDB、Apache Cassandra、Gremlin 和 Redis 的托管数据库服务。
• 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 和 Azure Database for MariaDB。 某些用例需要文档数据库或 NoSQL 数据库，例如 MongoDB 或 Azure Cosmos DB。

日志聚合

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

CI/CD

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

作者

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

首席作者：

• Andrew Harvey | CTO 及创业大使

其他参与者：

• Nick Ward | 云解决方案架构师

后续步骤

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

相关资源

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