什么是cloud-native?cloud-native框架、cloud-native运行时和cloud-native基础设施的自动化又有哪些内容?读完这篇文章，就能有一个大概的了解。
你能做到每周、每天甚至每个钟头向客户发布新特性吗?新加入的开发者能够在他们工作的***天甚至面试阶段就能部署代码吗?部署新员工的代码后，你能因为确信应用程序运行正常而安然入睡吗?建立快速发布机制，包括支持cloud-native应用的安全与可靠的运维的流程、工具和文化，已经成为软件驱动组织的关键战略因素。有了快速发布机制，这些组织就能在降低风险的同时更快地发布软件。发布软件越快，得到的反馈循环就越紧密，企业就能更有效地响应客户的需要。
持续交付是软件正在变成cloud-native应用的原因：更快地交付软件，降低反馈循环的时间。完全实现cloud-native战略，需要文化和技术两方面的改变，DevOps是应对这些改变的方法。微服务是应用最成功的软件体系架构模式，它扩展了开发和交付操作，避免缓慢、充满风险的单体部署策略。例如，如果还没有建立“快速失败”和“自动优先”的 DevOps 文化，很难成功地实施微服务战略。
持续交付、DevOps和微服务分别描述了cloud-native应用的为什么、怎么做和是什么。这些竞争优势迅速成为玩转软件游戏的赌注。深究起来，上述三个概念纠缠在一起，不可区分。这就是cloud-native的含义所在。
cloud-native能做些什么?
贯穿软件交付生命周期的cloud-native能让用户更有效地运维和扩展，成功拥有“敏捷性”：能够快速为软件添加新功能，同时保持生产环境的稳定性和安全性。cloud-native能做到这一点的原因是它把运行应用程序所需的基础设施、中间件和后台服务完全自动化。
传统的自动化方法建立在面向虚拟化的编排的基础上，需要用户编写定制的自动化脚本。cloud-native完全超越这种自动化方法。真正的 cloud-native架构包含完全自主的自动化和编排，用户只需提出自己的需求，不用描述如何做。在一个cloud-native环境中，很难维护临时、专门的自动化。cloud-native架构内置的自动化管理服务起到了契约的作用，执行策略和保证承诺。换句话说，这种自动化使得构建能被自动管理的应用程序变得容易。
新的体系架构方法，要求新的软件开发方法。开发者必须运用新的一系列架构实践——例如微服务和容器——来确保应用程序能被cloud- native平台恰当地管理。cloud-native不仅带来软件开发速度的提升，还有运维方面的好处：方便移植的应用实例，一致的日志记录和保证应用在线和数据流的监控功能。
想要了解cloud-native的好处，一种方法是引入运行时契约，即运行软件的一系列指南。cloud-native框架帮助开发者编写满足云平台运行时契约的应用程序。
cloud-native框架
cloud-native应用的本质是它们满足如下特点的契约：通过可预测的行为，***化复原。云平台使用的高度自动化、容器驱动的基础设施，***软件的编写方式。开发者必须改变编码方式，在开发者和运行应用的基础设施之间建立一种新的契约。一个很好的契约例子是十二因素应用。
其中，大多数因素的内容有重叠，相互补充。这些因素的描述尽量保证直接和可操作：
- 从一个代码库部署到多个环境——一个代码库，包括生产环境软件包，确保了单一的信任源，从而保证了更少的配置错误和更强的容错和复原能力。
- 依赖管理是声明式的——云平台根据这些声明管理依赖，确保云应用所需的库和服务。
- 配置信息保存在环境中——环境变量是一种清楚、容易理解和标准化的配置方法，特别适合用不同编程语言编写的无状态应用的使用。
- 将后台服务视为附加的资源——将每一种资源都视为一种远程的资源，应用因此具有容错和复原能力，因为它一方面要求编码时就要考虑资源不可用的情况，另外一方面也增强微服务方法的好处。
- 区分构建、发布和运行阶段——cloud-native应用的构建流程把大部分发布配置挪到开发阶段，包括实际的代码构建和运行应用所需的生产环境配置。
- 作为无状态进程运行——尽量保持应用栈每一层的轻量级，保证cloud-native基础设施的速度和效率。
- 通过端口绑定对外暴露服务——cloud-native应用的服务接口优先选择 HTTP API 作为通用的集成框架。
- 通过添加无状态进程实现横向扩展——强调无状态、无共享的设计，这意味着依赖底层平台就能实现横向扩展，不需要技术难度高的多线程编码。
- 快速地启动，优雅地关停——假设任何进程随时都能启动和关停。
- 开发、预发布和生产环境运行同样的应用和依赖配置——由于强调自动化和在每个阶段使用同一个云平台，如果每个人用同样的服务器配置，那么“应用在我这里是可以的”就意味着在其他人或者环境那里也是可以的。
- 日志输出到标准输出，方便日志聚合和事件响应——当日志是由云平台而不是应用包含的库处理时，日志处理机制必须保持简单。
- 临时任务作为短时进程运行——在cloud-native中，管理任务也是一个进程，而不是特别的工具;同样重要的是，管理任务的进程不应使用秘密的 API 或者内部机制。
遵循上述原则的应用程序，具有一致的架构接口。为了使创建的分布式应用马上就可以部署在云中，这些接口的构建采用一种无状态、面向进程的设计模式。 Ruby on Rails 是一种革命性的 web 应用开发框架，它采用强制性的、约定高于配置的方法。从***版 Rails 发布之日算起，已经九年半过去了，整个业界认识到了遵循约定的框架的威力。
像 Java 的 Spring Boot/Cloud 和 Dropwizard 、Node.js 的 Seneca 框架，甚至包括 Ruby on Rails (外加几个 gem 包)在内，它们都能很好地满足cloud-native契约的要求，这势必节省开发者的时间，让开发者专心编写应用的核心代码——关键业务逻辑，不必费心于支持应用工作的胶水代码。
当应用程序遵循运行时的契约时，弹性的cloud-native运行时就能编排、管理和扩展这些应用。
cloud-native运行时
容器已经成为云运行时的关键组件。容器的轻量本质和强力的资源管理特性，特别适合cloud-native，为之增加了速度和资源效率。容器将一个cloud-native应用打包成一个遵循云平台约定的可执行物件。
与其它进程一样，可在任何一台主机(物理机或者虚拟机，无所谓)上运行很多容器。在开发阶段，把应用构建为一个容器，使得开发者编码和创建完整构建的周期大大缩短，这甚至运行开发者在他们的笔记本电脑上运行一个开发云，***程度地减少了在生产环境的云运行时无法正常运行的可能性。在生产环境中，容器提供的关键好处包括更好的进程间安全、稳定性和准确地预测每个进程消耗的资源。更进一步，还能预报由于增长带来的基础设施耗费。
要有效地使用容器，就必须实现容器编排。编排是指无需人工交互和规划，就能启动、关停和分发容器到计算资源池中;一个弹性运行时。编排是对部署请求、自动扩展的流量分析、甚至是基础设施失效的响应。完整的容器编排还要做到检测和回滚变化，管理生产环境中应用的不同版本来完成 A/B 测试和每日部署。打包容器只是cloud-native架构需求的一部分：编排和管理容器在生产环境中的部署和运行，这比容器的打包重要得多。
随着前述cloud-native框架的兴起，容器编排的属性最近获得了很多关注。容器运行时需要做到：
- 管理容器的生命周期，包括创建、运行和摧毁——强有力地控制运行在生产环境中每一个容器的生命周期，有助于实现应用的按需自动扩展。
- 通过约束保证资源利用是可预测的——细粒度控制每个容器实例使用的资源。
- 进程隔离——使用内核级别的命名空间和本地文件系统，确保不同容器的进程之间是隔离的。
- 通过编排实现资源的***利用——给定一个资源池(通常是虚拟机集群)，容器编排使得应用负载分布在整个资源池中。
- 检测错误和从失效中恢复的方法——在生产环境中，出错是难免的。编排平台必须能检测到关键组件的失效，自动移除工作不正常的容器实例和基础设施，重新部署应用，以避免宕机。
通过使用 API ，cloud-native运行时能够在各种不同的基础设施上运行，不与特定的基础设施绑定。管理良好的、自动化的基础设施使得cloud-native架构更具有容错和恢复能力。
cloud-native基础设施的自动化
如果基础设施自动化做得好，生产环境架构的管理几乎不需要人工干预。
健壮自动化几乎能处理传统IT中需要手工处理的所有事情：当应用实例增减时更新路由器和负载均衡组件，部署应用所需的供应和联网服务，分配新的基础设施，设置监控和灾后恢复服务，日志聚合，当基础设施失效时重新部署应用。
像上面这些高级自动化实践，能把你从应对零日危险的痛苦中拯救出来：自动化采用滚动更新的方式，为每一个节点打上安全补丁，同时又保证服务一直在线。
这种水平的自动化是由结构化平台提供的。
从概念层次上，每一个结构化平台都必须包括：
- 路由和负载均衡——应用的横向扩展需要网络路由，路由是可以动态更新的，它把外来请求分散到整个资源池。
- 后台服务代理——大部分应用都需要各种后台服务，包括数据库、缓存和消息队列。这些服务必须是高可用的服务，通过环境变量进行配置，以便满足十二因素约定中对配置的要求。
- 基础设施编排——平台必须能自动管理基础设施，提供弹性扩展的计算资源。
- 健康管理、监控和恢复——可视化显示正在运行的应用和实例，以及当事件发生时的通知消息和审计日志。
- 可复用的运行时环境仓库——应用以容器镜像的形式发布，重复用于启动应用实例，这保证了整个架构同一个应用的所有实例是完全一样的。
- 日志聚合——高可用、横向扩展的应用需要聚合所有实例的日志，用于分析和响应发生的事故。
cloud-native基础设施编排提供了直到基础设施的结构化平台。这是与底层 API 集成的一层;也是cloud-native架构的基础，cloud-native架构支撑了运行时编排的安装、扩展、管理和更新。
以上是对成功交付cloud-native应用的理论思考的概述。cloud-native在加速软件交付的同时，降低了运维中的修正代价，无论是时间还是压力方面。如果部署和运维的代价高，持续交付和微服务是站不住脚的。这里主要关注工具的功能，但是不能低估所需要的高度信任文化和过程。(有人甚至认为文化和过程是更为关键的成功因素，那需要讨论的内容就更多了)。
cloud-native如此
那些想把持续交付的速度和好处***化的人，需要支持cloud-native应用的体系架构，作为贯穿整个软件交付周期的使能技术。应用是用满足cloud-native运行时契约要求的cloud-native框架构建的，cloud-native基础设施自动化大大改变了组织交付软件的能力。这个平台还包括用以实现持续交付、敏捷开发和 DevOps 运动的生产环境承诺的实践和过程;云基础设施的可用性和可靠性。
cloud-native做到了稳定性和敏捷性兼顾。有了cloud-native架构，就可以像Netflix这样的cloud-native公司一样，拥有相同的功能、灵活性、速度和安全性。最终你就有时间欣赏此前错过的动画片《我的小马驹：友谊是神奇的》。
