转载

云原生机制的三个核心思想及其未来之路

摆脱临时性自动化方案之定位，发挥优势以实现可预测功能。

云原生机制的三个核心思想及其未来之路

您能否以每周为单位向客户发布各类新功能?甚至进一步达到以每天乃至每小时为单位?新晋开发人员能否在上班的第一天即进行代码部署，或者是在工作审查过程中完成功能交付?了解到新员工完成代码部署后，应用程序仍能完美运行，大家肯定可以睡个好觉。事实上，这种快捷的发布周期需要配合一系列流程、工具甚至是管理文化，从而共同支撑起一套安全且可靠的云原生应用程序运作机制。而这也成为软件驱动型企业的核心战略因素之一，其目标在于以更快速度发布软件成果，且同时降低潜在风险。在拥有了这种快速发布软件的能力之后，我们将拥有更为紧凑的反馈循环，从而高效响应客户的每一项基本需求。

持续交付能力正是软件迈向云原生方向的主要动力：软件发布速度的加快能够有效降低反馈周期的持续时间。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为代表的各类框架已经为云契约构建起了很好的立足根基。它们的存在不仅能帮助我们节约大量时间，同时也让开发者能够将精力集中在编写作为应用核心的关键性业务逻辑身上，而非劳心劳力将代码粘接在一起以实现正常运行。

当我们的应用程序符合运行时契约要求时，这意味着大家可以对其进行编排、管理并通过弹性云原生运行时环境对其进行规模伸缩。

正文到此结束