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