Cloud Native Philosophy

AI 摘要: 云原生是一种基础设施,云原生应用是在其上运行的应用。云原生设计哲学包括面向分布式、配置、韧性、弹性、交付、性能、自动化、诊断和安全。云原生应用具有弹性、敏捷、可操作和可观察的特性。它们通过微服务、健康报告、遥测数据和声明式设计实现。云原生应用与传统应用和IAAS有所不同,需要自主应用管理的基础设施。

云原生参考文档

  1. DevOps 研究: https://cloud.google.com/architecture/devops/technical?hl=zh-cn
  2. API 管理:https://cloud.google.com/apigee?hl=zh-cn

云原生的设计哲学

云原生本身甚至不能称为是一种架构,它首先是一种基础设施,运行在其上的应用称作云原生应用,只有符合云原生设计哲学的应用架构才叫云原生应用架构。

设计理念

  • 面向分布式设计(Distribution):容器、微服务、API 驱动的开发;
  • 面向配置设计(Configuration):一个镜像,多个环境配置;
  • 面向韧性设计(Resistancy):故障容忍和自愈;
  • 面向弹性设计(Elasticity):弹性扩展和对环境变化(负载)做出响应;
  • 面向交付设计(Delivery):自动拉起,缩短交付时间;
  • 面向性能设计(Performance):响应式,并发和资源高效利用;
  • 面向自动化设计(Automation):自动化的 DevOps;
  • 面向诊断性设计(Diagnosability):集群级别的日志、metric 和追踪;
  • 面向安全性设计(Security):安全端点、API Gateway、端到端加密;

云原生基础设施的一些注意

  • 光是租用服务器并不会使您的基础设施云原生化;
  • 云原生不是指在容器中运行应用程序;
  • 即使应用程序是通过 CI/CD 渠道自动构建和部署的,也不意味着您就可以从增强 API 驱动部署的基础设施中受益。
  • 并不意味着您只能运行容器编排器(例如 Kubernetes 和 Mesos)
  • 云原生不是微服务或基础设施即代码(IAAS)。微服务意味着更快的开发周期和更小的独特功能,但是单片应用程序可以具有相同的功能,使其能够通过软件有效管理,并且还可以从云原生基础设施中受益。
  • 云原生与 12 因素应用程序不同,即使它们可能共享一些类似的特征。

配置管理工具 Chef 和 Puppet,以机器可解析语言或领域特定语言(DSL)定义、自动化您的基础设施(基础设施即代码),尽管配置管理工具为操作系统的资源(例如软件包管理器)提供了一些抽象,但它们并没有抽象出足够的底层操作系统来轻松管理系统资源,同时无法更好地管理应用程序,且配置可变性方面支持不足(只能以固定方式支持)!

云原生应用程序

云改变了业务和基础设施之间的关系一样,云原生应用程序也改变了应用程序和基础设施之间的关系。

云原生应用程序被设计为在云平台上运行,并设计用于弹性,敏捷性,可操作性和可观察性。弹性包含失败而不是试图阻止它们;它利用了在平台上运行的动态特性。敏捷性允许快速部署和快速迭代。可操作性从应用程序内部控制应用程序生命周期,而不是依赖外部进程和监视器。可观察性提供信息来回答有关应用程序状态的问题。

调度与编排

术语“调度器”和“编排器”通常可以互换使用。

  • 编排器多数情况负责集群中的所有资源利用(例如:存储,网络和 CPU)
  • 调度器是编排平台的一个子集,仅负责选择运行在每台服务器上的进程和服务。

云原生应用特性

  • 微服务
    • 单体的弊端,随业务时间增长,变得复杂,缺乏灵活;微服务,可以拆分成更细粒度,选择合适语言编写,方便独立扩缩容;
    • 遵循服务契约,应用程序就能够快速改进
    • 拥有微服务并不意味着您拥有云原生基础设施,它们不是云原生应用程序的必需条件。
  • 健康报告
    • 停止逆向工程应用程序并开始从内部进行监控。
    • 通过应用程序提供 Web 服务,返回 HTTP 状态码来检查健康状态。
    • 通过遥测收集服务健康数据,做服务级别目标(SLO)违规警报
    • 应用程序不仅仅有健康或不健康的状态,应该包括启动和关停中的状态,平台需要知道应用程序何时可以接收流量。
  • 遥测数据
    • 遥测数据是进行决策所需的信息,遥测数据应该用于提醒而非健康监测。
    • 健康报告通知我们应用程序生命周期状态,而遥测数据通知我们应用程序业务目标。
    • 测量的指标有时称为服务级指标(SLI)或关键性能指标(KPI)。这些是特定于应用程序的数据,可以确保应用程序的性能处于服务级别目标(SLO)内。
    • 通常采用时间序列数据库(例如 Prometheus 或 InfluxDB)进行聚合
    • 至少应该收集应用程序的速率(QPS),错误和执行时间(RT)。
    • 警报也不应该与日志记录混淆。
  • 弹性
    • 弹性是基础设施的责任,但云原生应用程序也需要承担部分工作。
    • 在任何平台上,尤其是在云中,最重要的特性是其可靠性。
    • 我们将在云原生应用程序中考虑弹性的两个主要方面:
      • 为失败设计: 平均无故障时间(MTBF)和平均恢复时间(MTTR)。无论发生什么故障,云原生应用程序都应该是可适应的。
      • 优雅降级:服务级别协议(SLA)。云原生应用程序需要有一种方法来处理过载,无论它是应用程序还是负载下的相关服务。
  • 声明式,而非命令式:传统的服务间调用通过消息中间件这类技术保障消息可靠(发送应用程序挂掉,消息仍然能照常进行),通信方式基于事件作出响应;但声明式的通信模式,相信网络传递消息,也相信应用程序将返回成功或错误,这并不是说应用程序监视变化并不重要。 Kubernetes 的控制器正是这样做到 API 服务器。但是,一旦发现变更,他们就会声明一个新的状态,并相信 API 服务器和 kubelets 会做必要的事情。这有助于简化应用程序,并使它们彼此的行为更具可预测性。

云原生应用与传统应用程序区别

云原生应用程序不能直接在 PaaS 上运行或与服务器的操作系统紧密耦合,它们期望在一个拥有大多数自治系统的动态环境中运行。

云原生应用与 IAAS 的关系

云原生基础设施在提供自主应用管理的 IaaS 之上创建了一个平台,该平台建立在动态创建的基础设施之上,以抽象出单个服务器并促进动态资源分配调度。

自动化自治不一样。自动化使人类对他们所采取的行动产生更大的影响。

云原生是关于不需要人类做出决定的自治系统。它仍然使用自动化,但只有在决定了所需的操作之后。只有在系统不能自动确定正确的事情时才应该通知人。

具有这些特征的应用程序需要一个能够实际监控,收集度量标准并在发生故障时做出反应的平台。