关于Cloud Native你真正了解吗？

　　欢迎各位阅读本篇文章，Cloud Native是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)、康威定律(Conways Law)等，以及根据商业能力对公司进行重组。

     什么是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包括如下几点：

　　可移植 - 应用层与物理层隔离。应用从开发环境迁移到物理环境无需改变环境配置。

　　自动化 - 通过 持续集成和自我修复系统将IT基础设施的开发和部署进行自动化。

　　效率提升 - 通过引入全新方式来降低运维成本，让系统管理员可以有更多时间去改进系统，而不是把时间都用在维护系统上。

　　意识改变 - 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应用的服务接口优先选择 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框架的兴起，容器编排的属性最近获得了很多关注。容器运行时需要做到：

　　1.管理容器的生命周期，包括创建、运行和摧毁——强有力地控制运行在生产环境中每一个容器的生命周期，有助于实现应用的按需自动扩展。

　　2.通过约束保证资源利用是可预测的——细粒度控制每个容器实例使用的资源。

　　3.进程隔离——使用内核级别的命名空间和本地文件系统，确保不同容器的进程之间是隔离的。

　　4.通过编排实现资源的最优利用——给定一个资源池(通常是虚拟机集群)，容器编排使得应用负载分布在整个资源池中。

　　5.检测错误和从失效中恢复的方法——在生产环境中，出错是难免的。编排平台必须能检测到关键组件的失效，自动移除工作不正常的容器实例和基础设施，重新部署应用，以避免宕机。

　　通过使用 API ，cloud-native运行时能够在各种不同的基础设施上运行，不与特定的基础设施绑定。管理良好的、自动化的基础设施使得cloud-native架构更具有容错和恢复能力。

　　cloud-native基础设施的自动化

　　如果基础设施自动化做得好，生产环境架构的管理几乎不需要人工干预。

　　健壮自动化几乎能处理传统IT中需要手工处理的所有事情：当应用实例增减时更新路由器和负载均衡组件，部署应用所需的供应和联网服务，分配新的基础设施，设置监控和灾后恢复服务，日志聚合，当基础设施失效时重新部署应用。

　　像上面这些高级自动化实践，能把你从应对零日危险的痛苦中拯救出来：自动化采用滚动更新的方式，为每一个节点打上安全补丁，同时又保证服务一直在线。

　　这种水平的自动化是由结构化平台提供的。

　　从概念层次上，每一个结构化平台都必须包括：

　　1.路由和负载均衡——应用的横向扩展需要网络路由，路由是可以动态更新的，它把外来请求分散到整个资源池。

　　2.后台服务代理——大部分应用都需要各种后台服务，包括数据库、缓存和消息队列。这些服务必须是高可用的服务，通过环境变量进行配置，以便满足十二因素约定中对配置的要求。

　　3.基础设施编排——平台必须能自动管理基础设施，提供弹性扩展的计算资源。

　　4.健康管理、监控和恢复——可视化显示正在运行的应用和实例，以及当事件发生时的通知消息和审计日志。

　　5.可复用的运行时环境仓库——应用以容器镜像的形式发布，重复用于启动应用实例，这保证了整个架构同一个应用的所有实例是完全一样的。

　　6.日志聚合——高可用、横向扩展的应用需要聚合所有实例的日志，用于分析和响应发生的事故。

　　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公司一样，拥有相同的功能、灵活性、速度和安全性。

     小结：相信最后大家阅读完毕本篇文章后，一定有所收获吧？如果大家还想要学习更多相关方面的详细内容的话，请关注课课家教育平台，在课课家教育平台这个学习的天堂中，一定会收获巨大的惊喜的，课课家教育平台欢迎各位~