摆脱临时性自动化方案之定位，发挥优势以实现可预测功能。
您能否以每周为单位向客户发布各类新功能?甚至进一步达到以每天乃至每小时为单位?新晋开发人员能否在上班的第一天即进行代码部署，或者是在工作审查过程中完成功能交付?了解到新员工完成代码部署后，应用程序仍能完美运行，大家肯定可以睡个好觉。事实上，这种快捷的发布周期需要配合一系列流程、工具甚至是管理文化，从而共同支撑起一套安全且可靠的云原生应用程序运作机制。而这也成为软件驱动型企业的核心战略因素之一，其目标在于以更快速度发布软件成果，且同时降低潜在风险。在拥有了这种快速发布软件的能力之后，我们将拥有更为紧凑的反馈循环，从而高效响应客户的每一项基本需求。
持续交付能力正是软件迈向云原生方向的主要动力：软件发布速度的加快能够有效降低反馈周期的持续时间。DevOps代表着我们全面实现云原生战略过程中需要遵循的文化与技术转变。微服务则是一套软件架构模式，其已经被成功且广泛地应用于开发及交付运营工作的规模扩展当中，且能够有效规避缓慢、高风险及单一性部署策略。举例来说，如果大家无法真正推广“快速失败”与“自动化优先”的DevOps文化，那么微服务机制将很难获得成功。
持续交付、DevOps以及微服务分别面向云原生机制的三项根本性重点，即为什么、如何以及什么。这些竞争优势已经迅速成为企业在软件成果对抗当中胜出的有力武器。作为最为先进的概念性载体，它们往往相互交织在一起并呈现出不可分割的态势——而这，正是云原生机制的实际表现形式。
云原生机制对我们意味着什么?
在软件交付生命周期当中引入云原生机制之后，大家将能够提高运营及规模化效率，进而实现所谓“敏捷性”：也就是快速为软件添加新功能，同时又不影响其在生产环境下的稳定性与安全性水平的能力。众所周知，我们的应用程序在运行过程中需要基础设施、开发者中间件以及支持服务的多方配合，而云原生方案则通过对这些因素的自动化改造实现上述目标。
这类方案绝不仅仅是在传统面向虚拟化的编排体系基础之上建立而成的临时性自动化解决办法。一套全面的云原生架构当中包含自动化与编排两类机制，能够帮助用户直接获得相关效果，而无需再将自动化流程作为可定制设计进行编写。其内置自动化管理方案可作为契约起效，从而执行政策并保障效果承诺。换句话来说，这类自动化方案使我们得以更为轻松地构建出可以自动化方式管理的应用程序。
当然，新型基础设施方案的出现同时也会对软件的开发方式提出新的要求。开发人员必须利用一整套新的架构实践组合——例如微服务与容器技术——从而确保应用程序能够在云平台之上得到妥善管理，这也是我们在软件开发提速之外需要认真考量的保障前提。新方案在运营层面亦带来多项助益，具体包括应用程序实例可迁移、统一化登录以及通过监控手段保障应用程序及数据流正常运作等等。
要发挥云原生方案的固有优势，较为理想的途径之一就是将其作为运行时契约加以审视。所谓运行时契约，本质上是一套运行软件所需遵循的指南组合。云原生框架能够帮助开发人员编写出符合云平台之上运行时契约要求的应用程序。
云原生框架
云原生应用程序的一大关键性特质在于，其需要遵循一套设计契约以最大程度实现行为的可预测性。云平台当中所使用的高自动化、容器驱动型基础设施也对软件的编写方式提出了要求。开发人员必须改变自己的编程习惯，在开发人员与基础设施之间创建出一套用于指导应用程序运行的新型“契约”。下面我们就通过“应用十二要素”中所提出的十二项基本原则来了解如何打造出一套理想的“契约”机制。
这十二项因素之间存在一定交集，同时亦相互支撑。大家在具体实施过程中，应当尽可能保持其直接关联与可行性：
1.立足于单一代码库向多种环境部署 – 包括生产性组件在内的单一代码库能够确保代码的单一来源，从而降低配置错误数量并提高弹性水平。
2.以声明方式管理依赖性 – 云平台需要引入必要的关联性声明并加以妥善管理，从而确保相关云应用程序始终具备必要的库及服务支持。
3.使用保存在环境当中的配置信息 – 环境变量能够提供一套简洁、易于理解且符合标准要求的使用方式，从而为以多种编程语言编写而成的无状态应用程序提供良好的配置机制。
4.将后端服务作为附加资源处理 – 将每种资源都作为远程资源处理的思路成就了弹性这一概念，这不仅从编程层面考虑到了资源不可用情况，同时也最大程度发挥了微服务方案当中的固有优势。
5.将构建、发布以及运行阶段区分开来 – 云原生应用程序的构建流程将大部分发布配置工作转移到了“开发”阶段，这意味着发布包当中将包含有代码本身以及运行应用程序所必需的生产配置方案。
6.以无状态方式运行 – 云原生基础设施的速度表现与成本效益要得到切实体现，要求应用程序堆栈中的第一层拥有尽可能高的轻量化水平。
7.将服务与端口绑定 – 云原生应用程序当中的服务接口一般倾向于利用基于HTTP的API作为通用集成框架。
8.通过添加无状态进程实现横向扩展 – 对于无状态非共享式设计思路的强调，意味着扩展工作能够依赖于底层平台——而非智能化多进程代码——来完成。
9.启动速度快，允许正常关闭 – 假定任意给定进程都能够随时进行启动与关闭。
10.在开发、分段与生产环境下拥有统一运行效果 – 由于高度强调自动化机制并在各生命周期阶段使用同样的云平台，因此只要大家使用的是同一套“平台”、那么我这边能用的在你那边也同样能用。
11.对汇总及事件响应的标准输出结果进行记录 – 当日志记录由云平台而非应用程序内的库负责处理时，将记录机制作为功能实体则变得非常关键。
12.允许临时性任务以短期进程方式运行 – 在云原生方案当中，管理任务可以单纯转化为另一种进程、而非特定工具，而且必须保证其行为方式要与使用“机密”API以及内部机制有所区别。
遵循以上指导性原则，我们完全可以在应用程序当中利用统一的架构接口构建起一套无状态且面向过程的设计模式，从而打造出适合运行在云环境之下的分布式应用程序。Ruby on Rails凭借着所坚持的、基于配置的公约方式在Web开发领域给应用程序框架带来了一次革命。自Rails首次发布至今的九年半时间里，充分利用框架潜能的意识已经深入到了整个技术行业当中，而云原生机制的出现也将继续延续这一发展趋势。
以Spring Boot/Cloud以及Dropwizard for Java、Seneca for Node.js甚至是Ruby on Rails为代表的各类框架已经为云契约构建起了很好的立足根基。它们的存在不仅能帮助我们节约大量时间，同时也让开发者能够将精力集中在编写作为应用核心的关键性业务逻辑身上，而非劳心劳力将代码粘接在一起以实现正常运行。
当我们的应用程序符合运行时契约要求时，这意味着大家可以对其进行编排、管理并通过弹性云原生运行时环境对其进行规模伸缩。
#p#
云原生运行时
容器技术已经兴起并发展成为云运行时环境当中的关键性组成部分。它们的轻量级特性以及紧凑的资源管理机制能够极好地同云应用程序方案加以配合，从而在提高速度的同时改进资源利用效率。容器技术相当于将一款能够运行于云平台之上的应用程序打包成一套独立的可执行组件，且确保其与云平台的契约要求相兼容。
与其它任意进程一样，大家也可以在每一台主机设备上运行多套容器系统(无论是裸机还是虚拟机)。在开发阶段中，利用容器方案构建应用程序能帮助开发人员降低耗费在编程方面的时间周期，同时在笔记本设备上创建出一套完整的、甚至能够面向开发者运行的云环境，从而模拟出整个生产流程。在生产环境下，容器提供的密钥机制能够更好地保障不同进程之间的安全性，帮助各进程拥有更出色的稳定性与可预测的资源消耗水平。而着眼于下一个层级，我们还能够借此预测基础设施在响应需求过程中的成长增长进度。
要有效运用容器技术，我们必须对其精心编排。编排是一种手段，目的是在无需人为介入或者制定规划的前提下以消耗性资源池为基础，实现容器的启动、中止以及资源分发——这实际上是一套弹性运行时。编排方案当中需要包含部署请求、自动伸缩流量分析以及基础设施发生故障时的响应措施等要素。完整的容器编排方案还能够实现诊断及变更回滚，同时对处于生产环境下的不同实验性应用程序版本进行管理及A/B测试乃至试探性部署。相比之下，简单的打包容器则仅仅属于云原生架构需求当中的一部分，负责编排并管理相关容器的部署方式——在这种情况下，容器在生产环境下的具体效果甚至要比容器自身的打包方式更加重要。
随着云原生框架方案的持续兴起，容器编排的出色属性已经受到业界的广泛关注。下面我们来总结享受容器运行时优势时需要保证的几项前提：
1.对生命周期的创建、运行以及中止加以管理 – 对运行在生产环境中的各容器的生命周期进行严格管理能够帮助大家根据实际需求对应用程序规模加以自动伸缩。
2.通过约束性手段以可预测方式运用资源 – 容器机制允许我们对每项实例所使用的资源进行细化控制。
3.进程隔离 – 同样的，容器机制能够利用内核层级的命名空间与本地文件系统保证各个进程之间彼此隔离。
4.通过编排机制优化资源利用方式 – 考虑到资源池通常由一系列虚拟机系统共同构成，容器会以分布式管理方式将工作负载分发至整个资源池当中。
5.故障诊断及生产恢复方式 – 生产环境下总会有组件发生故障，而这套编排平台应当以自动化方式对关键性故障作出响应，包括移除异常实例及基础设施并重新均衡负载以避免宕机等。
云原生运行时能够运行在类别广泛的不同基础设施之上，且通过API消除对具体基础设施类型的依赖性。当然，拥有妥善管理的自动你可以基础设施能够让我们的云原生架构在弹性方面更上一层楼。
云原生基础设施自动化
以合理实施作为出发点，基础设施自动化将使整套生产架构以全面托管方式运作，且几乎无需人为因素的介入。
强大的自动化机制能够处理几乎任何原本需要由传统IT人员完成的任务：新型路由器及负载均衡机制能够完成应用实例的启动与中止、配置以及网络服务等应用程序部署过程中必需的环节，同时实现新基础设施资源分配、设置监控方案与灾难恢复场景、日志汇总甚至是在基础设施出现故障时对工作负载进行重新分配。
这类先进的自动化实践能够帮助我们免受零日安全漏洞的侵扰：自动化方案会在每个节点之上进行部署操作，从而在不产生任何停机时间的前提下应用安全补丁。
要实现这种级别的自动化效果，我们需要使用所谓结构化平台。从宏观角度看，这类结构化平台必须拥有以下能力：
1.路由与负载均衡 – 通过容器编排对应用程序进行横向扩展必然要求网络路由加以配合，而后者则能够以动态方式对面向整套资源池的输入请求进行均衡。
2.支持服务代理 – 大部分应用程序在运行过程中都需要外部支持服务作为配合，例如数据库、缓存解决方案以及消息队列机制等等，而这一切都应当由该平台作为贯穿整个环境的高可用性服务加以交付，且符合前面提到的十二项配置基本原则。
3.基础设施编排 – 平台应当自动管理整套基础设施，从而对计算资源进行弹性规模伸缩。
4.运行状况管理、监控与恢复 – 当事件发生时，将平台之上所运行应用程序之虚拟化、实例以及通知与审计全部纳入日志记录。
5.可重复使用的运行时环境库 – 容器镜像在创建过程中需要考虑到不同应用程序实例启用时的发布及可重复使用能力，从而确保整套架构中的全部实例皆拥有完全一致的运行前提。
6.日志汇总 – 高可用性横向扩展应用需要对来自全部实例的日志信息加以汇总，从而进行分析并针对突发情况作出快速响应。
云原生基础设施编排机制提供一套贯彻基础设施始终的结构化平台，它既是整合了底层API的完整层级，同时也作为云原生架构中的基础性组成部分存在，从而保证运行时编排体系得以安装、扩展、管理以及更新。
这正是保障云原生应用程序交付成功的宏观层面考量方向，同时也是在运营过程中降低修复时间与压力成本并加快软件交付速度的有效途径。如果部署与运营成本过于高昂，那么持续交付与微服务架构将无从谈起。我们当然需要着眼于此类工具的主要功能，但同时也必须重视高可信度文化及流程的建立。(在某些情况下，文化与流程甚至会成为左右实际结果的关键性因素，但这就不在今天的讨论范围之内了。)
迈向云原生之路
对于希望最大程度享受持续交付机制所带来的速度与效益的用户来说，拥有一套能够支持云原生应用程序的架构显然极为重要，只有这样面向整体软件交付生命周期的技术方案才能落实到位。以符合云原生容器运行时特性的云原生框架为前提构建应用程序，同时实现云原生基础设施自动化，这样企业业务能力才能在软件交付过程中得到保证。此类平台还包含大量用于实现持续交付、敏捷开发以及DevOps活动的具体实践及流程，同时带来云基础设施所固有的可用性及可靠性优势。
总而言之，享受云原生的稳定性与敏捷性优势不应以牺牲固有效益为代价。在云原生架构当中，我们可以拥有同样的资源储备、灵活性水平、速度表现乃至安全成效——Netflix等云原生企业已经给出了实证。保持信心，同时谨慎对待，这正是在云原生之路上高歌猛进的重要原则。
原文标题：The cloud-native future
