Infrastructure
Category
Enterprise
Complexity
企业级 SaaS, 金融服务
Industries
2+
Technologies
何时需要此方案
您的基础设施通过点击云控制台进行管理。预生产环境和生产环境之间的环境漂移导致基础设施层面出现“在我的机器上能跑”的问题。扩展需要手动干预，部署涉及 SSH 进入服务器，灾难恢复是一个没人测试过的 Google Doc。您需要可重现、版本控制、自愈和可观测的基础设施——一个团队无需“英雄知识”即可操作的基础设施。
模式概述
云原生基础设施将基础设施视为代码 (IaC)，在由 Kubernetes（或托管的等效服务）编排的容器中运行工作负载，通过 GitOps 管道进行部署，并在运维权衡有利时使用托管服务。该模式涵盖了实现可用性的多区域部署、实现弹性的水平 Pod 自动扩缩、用于服务间通信的服务网格以及全面的可观测性。目标不是“在云上运行”——而是构建默认自动化、可重现和弹性十足的基础设施。
Related Architecture Patterns
Explore more design patterns and system architectures
常见问题
Cloud-native 意味着专门设计应用程序以利用云能力，例如弹性伸缩、托管服务和分布式架构，而不是简单地将本地应用程序迁移到云中的虚拟机上。MicrocosmWorks 使用容器化、声明式基础设施即代码、服务网格和 CI/CD 自动化来构建 cloud-native 系统，这些技术将基础设施视为临时的、可替换的，而非宝贵的、长期存在的。实际的区别在于，一个 cloud-native 应用程序可以自动从 10 个用户扩展到 10,000 个用户，在无需人工干预的情况下从基础设施故障中恢复，并每天部署数十次更新。
MicrocosmWorks 推荐 Kubernetes 适用于运行 10 个以上 microservices 并需要 auto-scaling、rolling deployments、service discovery 和多环境一致性等高级编排功能的组织，而 AWS ECS、Google Cloud Run 或 Azure Container Apps 等更简单的平台更适合服务数量较少或 Kubernetes 经验有限的团队。我们观察到许多团队过早地采用了 Kubernetes，结果将更多时间花在了管理集群上，而不是构建新功能，因此在推荐编排层之前，我们会评估您的实际工作负载复杂性和团队成熟度。我们的评估包括一项 TCO 分析，比较托管 Kubernetes、serverless containers 和 platform-as-a-service 选项在您的特定规模下的适用性。
MicrocosmWorks 将 Terraform 作为多云基础设施配置的标准化工具，同时为偏好使用 TypeScript 或 Python 等编程语言而非 HCL 的团队提供 Pulumi。所有基础设施定义都存储在 Git 中，并通过与应用程序代码相同的 CI/CD 管道进行部署。我们将 IaC 存储库构建为用于网络、计算、数据库和可观测性的可重用模块，这些模块可以组合成特定于环境的配置，从而确保开发、预生产和生产环境之间的一致性。每次基础设施变更都会经过拉取请求评审，并附带自动化的计划预览，这些预览准确显示在任何变更应用之前将创建、修改或销毁哪些资源。
MicrocosmWorks 设计 cloud-native 架构时采用抽象层，该抽象层将特定于云的依赖项隔离在定义良好的接口之后，从而可以在不重写整个应用程序的情况下为单个服务更换提供商。我们尽可能使用 Kubernetes、PostgreSQL、Redis 和 OpenTelemetry 等可移植技术，并将 DynamoDB 或 Cloud Spanner 等特定于云的服务封装在适配器层中，这些适配器层可以为其他提供商重新实现。这种方法在初始开发期间增加的开销极小，但如果您以后需要将工作负载迁移到不同的提供商，或者出于合规性或弹性原因采用 multi-cloud 策略，则可节省数月的迁移工作。
一个典型的云原生基础设施合作项目从为期两周的评估开始，在此期间 MicrocosmWorks 将评估您当前的架构、工作负载和团队能力，紧接着是为期 4-8 周的平台构建阶段，旨在提供包括容器编排、CI/CD 流水线、可观测性和安全控制在内的基础架构。之后，我们将进行为期 4-6 周的应用程序迁移阶段，在此阶段，我们将把您的首批 2-3 个服务容器化并部署到新平台上，您的工程团队将与我们团队紧密合作，进行实践知识转移。我们的云原生咨询费率范围为 $10-$40/小时，整个合作项目从评估到生产就绪通常持续 10-16 周。
