本文从初创企业的视角出发，对五大基础平台支柱——计算、网络、存储、容器和数据——进行快速介绍。 对于每个支柱，你都会得到一个简短的决策表，用于将你的具体情况对应到默认服务，外加一条说明，告诉你随着初创公司规模扩大，应在何时重新评估这一选择。
本文将介绍如何
- 为你当前阶段选择合适的 Azure 计算、网络和存储基础服务。
- 确定Azure Kubernetes 服务是否是适合你的阶段的容器平台，如果不是，则改用什么。
- 跨关系、文档、矢量和分析工作负荷选取第一个数据平台。
- 采用一组精简的成本、可靠性和安全默认配置，并且在业务增长时依然适用。
- 识别那些表明默认选择已经不再适用的信号。
先决条件
- 一个有效的 “Azure” 订阅。
- 安装并登录Azure CLI。 若要登录，请运行
az login。 - 至少一个资源组的所有者或参与者访问权限。
- 熟悉Azure门户登陆页面很有帮助，但不需要。
- 基本熟悉Azure基础知识（区域、订阅和资源组）。
为什么对于初创公司来说很重要
对于一家早期阶段的初创公司来说，错误选择基础设施的代价并不在于账单本身。 等到你已经围绕这个错误的服务完成构建后，再从它迁出时，你就会白白浪费一周时间。 本文中的五大支柱，都是那些一旦默认选择不当，问题往往就会层层叠加的领域：错误的计算平台会影响你的部署流水线；错误的数据库会限制你的数据模型；错误的网络拓扑会挡住你的第一家企业客户。 无需平台团队、站点可靠性工程师或财务运营专家才能很好地做出这些选择。 你需要一个足够好、可以据此发布的默认方案，以及一个明确的信号，告诉你何时该重新审视它。 如果你的初创公司加入了 Microsoft for Startups 计划，相同的默认设置可以让你的额度用得更久，并让你在以后仍有资格获得高级权益。
计算：代码的运行位置
Azure有十几个计算服务。 好消息是：对于大多数处于早期阶段的工作负载来说，这三种就能满足你的需求。
| 你的情况 | 默认Azure服务 | 为什么 | 何时重新访问 |
|---|---|---|---|
| Web 应用或 HTTP API，一个或两个服务，你希望使用托管运行时 | Azure 应用服务 （Linux） | 不需要容器生成。 内置 TLS、自定义域、部署槽位和自动缩放。 免费层和基本层的价格足够低，适合运行预演环境，不过部署槽位和自动缩放需要标准层或更高级别。 | 如果您要运行不止少数几个服务、需要按服务分别扩缩容，或者需要边车容器。 |
| 事件驱动函数、定时任务或 Webhook 处理程序 | Azure Functions （消耗计划） | 按执行次数付费。 缩放到零。 绑定可免去用于队列、Blob 和 HTTP 触发器的大部分胶水代码。 | 冷启动会影响用户端延迟，或者导致你超出消费计划限制。 |
| 容器化微服务，你希望在无需管理 Kubernetes 的情况下使用预置约定的运行时 | Azure 容器应用 | 基于 Kubernetes 构建，并采用基于 KEDA 的自动扩缩容，但你无需管理集群。 Dapr 可作为可选集成使用。 包括缩放到零、修订和 HTTPS 入口。 | 需要群集级控制、自定义计划程序或高级网络。 |
| 长时间运行的批处理作业、GPU 训练任务，或现有虚拟机工作负载的原样迁移 | Azure 虚拟机 | 完全操作系统控制。 需要横向扩展时，请使用虚拟机扩展集。 | 补丁和镜像管理的运维开销开始拖慢交付速度。 |
| 你确定需要 Kubernetes（在作出这一假设之前，请先参见第 4 节） | Azure Kubernetes 服务 | 托管的控制平面。 适合已经具有 Kubernetes 体验或特定平台要求的团队。 | 有关 AKS 的决策标准，请参阅“容器”部分。 |
小窍门
先使用应用服务构建您的第一个面向用户的 Web 应用，对于所有事件驱动的场景，则使用 Azure Functions。 如果保持应用程序无状态并将配置写入环境变量，则可以稍后在不更改应用程序代码的情况下移动到Azure 容器应用或Azure Kubernetes 服务。
在容器应用和应用服务之间进行选择
容器应用和应用服务重叠。 说句公道话，决定因素是：如果你的应用程序已经以容器镜像形式运行，并且你希望按服务分别扩缩容（例如 Web 层和工作器使用不同的副本数），那么 Container Apps 更占优势。 如果应用程序是单个 Web 进程，并且不希望维护 Dockerfile，则应用服务将获胜。
Caution
如果您有简单方案无法满足的明确需求，请考虑 Azure Kubernetes 服务。 虽然它提供了强大的灵活性和控制，但它还引入了其他操作注意事项（例如升级、节点池大小调整、入口配置和证书管理）。 如果过早采用，团队往往会发现，投入到平台管理上的时间比开发产品功能的时间还要多。
网络设置：第一天要设置什么
大多数早期Azure工作负荷在第一天不需要虚拟网络。 应用服务、Functions、容器应用和大多数托管数据库都会提供启用 TLS 的公共终结点；只要正确配置身份验证，就可以安全地对外公开。 在有原因之前添加网络复杂性是最常见的Azure过早优化。
| 你的情况 | 默认方法 | 为什么 | 何时重新访问 |
|---|---|---|---|
| 全新的应用，公共 Web 流量，尚未满足合规性要求 | 将公共终结点与 TLS 配合使用。 无虚拟网络。 | 最低操作开销。 应用服务、容器应用和托管数据库可为你处理 TLS。 使用 Microsoft Entra ID 进行身份验证。 | 你的第一个企业客户要求建立专用连接。 |
| 需要在应用与托管数据库之间建立专用连接 | 计算端的虚拟网络集成、数据库端的专用终结点 | 流量始终通过微软骨干网络传输。 数据库不公开。 同一托管服务，不会更改应用程序。 | 如果您处理受保护的数据，那么从第一天开始就应如此；否则，等到审计或客户提出要求时再做。 |
| 您需要一个单一的公共入口点，作为多个后端的统一前端，并提供路由、TLS 终止和 Web 应用防火墙功能 | Azure Front Door（全局）或Azure 应用程序网关（区域） | Front Door 添加了全局内容分发网络和边缘缓存。 Application Gateway 是区域性的原生虚拟网络选项。 | 你已经超越了应用服务的内置 TLS 和路由。 |
| 需要出站静态 IP 地址（例如付款处理器允许列表） | 关联到虚拟网络的 NAT 网关 | 可预测的出站 IP 地址。 许多第三方 API 所要求的。 | 供应商需要它。 不要投机地添加它。 |
| 多区域或多帐户拓扑 | 虚拟网络对等互连 或 Azure 虚拟 WAN | 真正的网络体系结构从此处开始。 对大多数处于探索阶段的团队来说，这超出了其范围。 | 多区域是一个真正的要求，而不是愿望。 |
Important
在担心网络隔离之前，请先严格管控 Microsoft Entra ID 和订阅中的角色分配。 小型公司中的大多数 Azure 安全事件源于权限过高的身份，而不是网络暴露。 使用 Microsoft Entra ID 组进行工程访问控制，并且不要在订阅范围内授予“所有者”角色。
存储：Blob、文件和磁盘
Azure 存储 是一种单一资源类型（存储帐户），提供四种数据服务：Blob、文件、队列和表。 对于应用程序存储决策，你几乎总是在 Blob（对象存储）、文件（托管文件共享）和托管磁盘（附加到虚拟机的块存储）之间进行选取。
| 要存储的内容 | 默认Azure服务 | 为什么 | 何时重新访问 |
|---|---|---|---|
| 用户上传的文件、生成的报表、日志、模型项目、备份 | Azure Blob 存储 （热层） | 对象存储。 低成本、耐用、可扩展至 PB 级。 对于很少读取的数据，后续可使用冷层级或存档层级。 | 您需要 POSIX 文件语义，或者需要从多台机器对同一个文件进行随机读写。 |
| 由多个虚拟机或容器装载的共享文件系统 | Azure 文件存储（标准）或Azure NetApp 文件（高吞吐量） | 服务器消息块（SMB）或网络文件系统（NFS）共享卷。 对于适合 Blob 模型的内容，请避免使用这些。 | 你开始把文件共享当作队列或数据库来使用。 移至右侧图元。 |
| 虚拟机的磁盘 | 高级 SSD v2 托管磁盘 | 可调整性能，应用程序磁盘的性价比良好。 高级 SSD v2 不能用作 OS 磁盘;将其与 OS 的高级 SSD（v1）或标准 SSD 配对。 对于低吞吐量工作负荷，标准 SSD 是可接受的。 | 需要跨虚拟机共享块存储（使用 Azure 弹性 SAN 或 Azure NetApp 文件）。 |
| 静态网站资产（单页应用程序捆绑包、营销网站、文档） | Azure 存储静态网站托管 + Azure Front Door | Static Web Apps 是现代默认选择：内置自定义域名支持、免费的托管 TLS、全球分发、GitHub Actions CI/CD 和内置身份验证。 存储静态网站功能 + Front Door 对于成本极低的方案仍然适用，但原生不支持自定义标头或身份验证。 | 添加服务器端渲染的页面。 移动到 应用服务 或 容器应用。 |
注释
每个订阅在每个区域的存储帐户软上限为 250 个（可按请求提高到 500 个）。 对于早期团队来说，这很充分。 避免的错误是为每个微服务创建一个存储帐户;按环境（生产、过渡、开发）和访问模式（热、冷、存档）分组。
备份说明
Azure 备份和存储帐户冗余选项（本地冗余存储、区域冗余存储、异地冗余存储）可按帐户和每个磁盘进行调整。 本地冗余存储（LRS）适用于开发和暂存。 将区域冗余存储（ZRS）用于生产数据。 异地冗余存储增加了成本，不能替代应用程序级灾难恢复。
容器和Azure Kubernetes 服务
Azure有三种方法在生产环境中运行容器：Azure 容器应用、Azure 容器实例和Azure Kubernetes 服务。 它们对应于不同的团队规模和运营偏好。
| 你的情况 | 默认Azure服务 | 为什么 | 开始疼的时候 |
|---|---|---|---|
| 您已有容器镜像，并且希望获得支持 HTTPS 入口流量、可缩减为零和修订版本的托管运行时 | Azure 容器应用 | 基于 Kubernetes 且使用 KEDA 自动伸缩的无服务器平台，但您无需查看或管理集群。 为运行的内容付费。 在遇到集群级需求之前，它都很合适。 Dapr 提供可选集成。 | 需要自定义计划程序、高级网络（多个网络接口卡、自定义容器网络接口插件）或特定的 Kubernetes 操作员。 |
| 您希望将单个容器运行为一次性作业或短期批处理任务 | Azure 容器实例 | 从映像到正在运行的容器的最快路径。 无编排。 按运行时长每秒计费。 | 如果你需要类似服务网格或自动扩缩容之类的能力，而不只是单个容器。 |
| 你已在其他位置运行 Kubernetes，或者应用程序体系结构确实需要它 | Azure Kubernetes 服务 | 托管的控制平面。 自带节点池、网络插件、入口控制器和可观测性堆栈。 | 第一天。 规划正在进行的升级（每 4 个月发布的次要版本）、节点池优化和证书管理。 |
| 你不确定自己是否需要 Kubernetes | 目前的容器应用 | 如果需要，您以后可以在 Azure Kubernetes 服务 上重新构建。 迁移一个无状态容器化应用程序只需几天时间，而不是几周。 | 你有一个具体的需求（操作员生态系统，群集级策略），你可以命名。 所谓“面向未来”并不是一个具体的需求。 |
何时毕业到 AKS
如果至少有两个为 true，请转到 Azure Kubernetes 服务 (AKS)：
- 你运行着十多个在生命周期和网络方面有共同管理需求的服务。
- 你需要容器应用未提供的自定义控制器、边车容器或自定义资源定义（CRD）。
- 您需要对虚拟网络进行深度集成，并严格实施策略。
- 你正在对基于 Kubernetes 的开放源代码生态系统（Argo、Istio、KEDA 等）进行标准化。
如果采用 AKS，请遵循 AKS 基线体系结构。 Microsoft Azure Well-Architected框架和 AKS 基线参考共同涵盖所需的安全性、缩放和升级默认值。
适用于小型团队的 AKS 默认配置
| 设置 | 默认 | 为什么 |
|---|---|---|
| 节点大小 | Standard_D4s_v5系统池，Standard_D8s_v5用户池 | 通用工作负载的可预测性价比 |
| 群集自动缩放程序 | 已启用 | 避免为空闲节点付费 |
| 工作负载标识 | 已启用 | 替换 pod 标识，与 Microsoft Entra ID 集成 |
| Azure Policy加载项 | 已启用 | 免费护栏（没有特权容器，需要标签） |
| 容器洞察 | 已启用 | Azure Monitor中的一流指标和日志 |
| 私有集群 | 已开启用于生产 | 仅可通过 VNet 访问的控制平面 |
Azure 容器注册表
无论选择哪种计算平台，将映像存储在 Azure 容器注册表 中。 基础版对于早期阶段的团队来说已经足够了。 如果需要硬隔离，请使用每个环境（生产、暂存）单独的注册表;如果需要简单性，请使用具有单独存储库和基于角色的访问控制的单个注册表。
数据平台：关系、文档、矢量、分析
数据平台决策是最有可能永久的决策。 你在第一个月交付的模式，将决定未来两年里的每一个功能。 选择一个足够灵活且足以随产品一起增长的默认值，并抵制为尚未构建的功能预先选取专用数据库的诱惑。
| 你的工作负载 | 默认Azure服务 | 为什么 | 何时重新访问 |
|---|---|---|---|
| 具有已知关系架构的事务应用程序数据（用户、订单、内容） | Azure Database for PostgreSQL （灵活服务器） | 成熟、广泛理解、强大的扩展生态系统（包括用于嵌入的 pgvector）。 突发性能层的价格足够低，适合用于开发和预发布环境。 | 多区域写入或超大规模读取模式。 请考虑使用适用于 PostgreSQL 的 Azure Cosmos DB。 |
| 架构灵活的运营数据、全球分布、可预测的个位数毫秒级读取 | Azure Cosmos DB （NoSQL API） | 默认支持多区域。 无服务器层级价格足够低，适合作为起步选择。 分区设计很重要;在交付之前，请阅读分区键指南。 | 你正在强制通过应用程序层建立关系联接。 PostgreSQL 可能是正确的答案。 |
| 在结构化和非结构化内容中搜索，包括检索增强生成 | Azure AI 搜索 | 混合关键字和矢量搜索。 与 Azure OpenAI 服务 和 Cosmos DB 集成。 免费层用于原型制作。 | 您已超出当前层级的索引数量限制（Standard 1 是常见的升级选择）。 |
| 用于检索增强生成功能的向量嵌入 | 开始使用 PostgreSQL 中的 pgvector 或 Azure AI 搜索 | 对于检索功能的初版，避免使用单独的向量数据库。 你将从实际使用情况中了解实际需要的内容（筛选、混合搜索、缩放）。 | 你已对读取模式进行了特征化，并且约束为专用引擎辩护。 |
| 针对生产数据的分析、报告和临时查询 | Azure Database for PostgreSQL只读副本（探索），Microsoft Fabric（展开和提取） | 只读副本足以满足大多数探索阶段的分析需求。 当现有方案已无法满足你的需求时，Microsoft Fabric 就是现代分析平台。 | 你的只读副本跟不上负载，或者业务相关方需要一个自助式分析界面。 |
| 数据库前面的缓存层 | Azure Cache for Redis （基本层） | 标准缓存基元。 后续再添加的成本很低；不要基于臆测提前添加。 | 你会看到一个明显的热读取模式，该模式使数据库饱和。 添加前先测量。 |
Important
选择一个默认数据库并保留该数据库，只要可以。 一个只有十五名工程师的团队，却要运行 PostgreSQL、Cosmos DB、Redis、AI 搜索、消息队列和图数据库，结果不知不觉就给自己揽下了相当于一个平台团队的工作量。
Azure OpenAI 服务的定位
Azure OpenAI 服务不是数据平台，但它共享相同的决策节奏。 大多数构建生成式 AI 功能的初创公司，起步时会在单一区域中部署一个模型（通常是较新的聊天补全模型），再配合用于检索的 AI Search 或 pgvector。 在实际使用情况表明你需要添加这些内容之前，你不需要专用的微调流水线、模型网关或多个部署。
本文介绍的内容（及其未涵盖的内容）
| 主题 | 在本文中 | 何时添加 |
|---|---|---|
| 基本信息之外的标识和访问管理 | No | 第一天用于Microsoft Entra ID设置。 进行信息安全审查时的条件访问和特权标识管理 |
| 基础结构即代码（Bicep，Terraform） | No | 当对门户的手动更改开始在不同环境之间出现偏差时。 通常是在你添加暂存环境的时候前后。 |
| 持续集成和持续部署管道 | No | 第一天。 GitHub Actions 或 Azure DevOps Pipelines 都可以。 |
| 可观测性（日志、指标、跟踪） | No | Application Insights 从一开始就可用。 在你受到告警疲劳困扰时使用 Azure Monitor 工作簿。 |
| 成本管理 | No | 从第一天开始设置订阅级预算。 从一开始就为资源添加环境和所有者标签。 |
| 合规性（SOC 2、ISO 27001、HIPAA） | No | 当客户询问时。 Microsoft Defender for Cloud具有一个符合性仪表板，用于将控件映射到Azure资源。 |
| 灾难恢复和多区域 | No | 当一小时的停机时间成本超过第二个区域的工程成本时。 |
当平台默认值不再足够时
这些增长信号告诉你，特定的默认值需要更刻意的替换：
- 在应用服务或容器应用上部署了五个以上的不同服务，每个服务规模正在成为日常关注的问题。 查看Azure Kubernetes 服务。
- 你的每月Azure账单增长速度比连续两个月的月度收入快。 现在该进行成本管理评审并分析预留实例或节省计划了。
- 虚拟网络现在跨越多个订阅或区域。 了解 Azure 虚拟 WAN 和中心辐射拓扑。
- 单个 PostgreSQL 实例不能将工作集保存在内存中，只读副本不会缩小差距。 考虑使用 Cosmos DB for PostgreSQL 或分片架构。
- 生产数据库上的分析查询显著影响应用程序延迟。 将分析移动到Microsoft Fabric。
- 对于同一访问模式，每个环境运行两个以上的存储帐户。 整合。
- 你已新增了第三个拥有付费客户的国家/地区。 现在该评估另一个区域、异地冗余存储和 Front Door 路由策略了。
注释
抵制早期采用企业平台工具的诱惑。 前述大多数模式（服务网格、多区域双活、财务运营工具链、自定义 Kubernetes Operator）都会增加运维复杂度，而这些投入只有在达到一定规模时才值得。 等你有团队来维护它们时再添加，不要提前添加。
参考清单
在 Azure 上的前六个月内，每月执行一次此操作。 它能检测到最常见的漂移。
- 每个环境（生产、预发布、开发）一个订阅，或使用一个订阅，并为每个环境严格划分资源组。 不要混合。
- 每个资源都标有环境、所有者和成本中心（即使成本中心是当今所有资源的相同值）。
- 成本管理中的订阅级预算，在达到每月目标的 50%、80% 和 100% 时发出警报。
- Microsoft Entra ID组（而不是个人）在资源组上担任角色分配。 订阅范围内没有现有的所有者。
- 每个生产计算资源都启用了 Application Insights 或 Azure Monitor。
- 生产数据库备份由记录的还原测试（至少一次）进行验证。
- 机密位于Azure 密钥保管库中，不在应用程序配置中。 对于从计算资源到 Key Vault 的访问路径，请使用托管标识。
- 会扫描容器映像（使用 Microsoft Defender for Containers 或注册表内置扫描程序）。