云原生参考文档
- DevOps 研究： https://cloud.google.com/architecture/devops/technical?hl=zh-cn
- 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 之上创建了一个平台，该平台建立在动态创建的基础设施之上，以抽象出单个服务器并促进动态资源分配调度。
自动化与自治不一样。自动化使人类对他们所采取的行动产生更大的影响。
云原生是关于不需要人类做出决定的自治系统。它仍然使用自动化，但只有在决定了所需的操作之后。只有在系统不能自动确定正确的事情时才应该通知人。
具有这些特征的应用程序需要一个能够实际监控，收集度量标准并在发生故障时做出反应的平台。