精华内容
下载资源
问答
  • 开启云原生时代Serverless之门,教你Knative 云原生应用开发从入门到精通,结合云原生开发实战进行讲解,很不错,快来下载吧。
  • 《Knative 云原生应用开发指南》
  • 云原生应用开发原则与最佳实践指南.pptx
  • 云原生应用开发原则与最佳实践指南.pdf
  • 2018 红帽论坛,超过500位客户亲临现场。演讲人 Alan Liu 高级解决方案架构师。
  • 什么是云原生应用开发 构建和运行应用的现代化理念; 集成和协同方法;2: 加快现有应用 快速一体化应用 将应用服务器迁移到基于容器的平台;14;2: 加快现有应用 淘汰一体化应用用微服务代替;3: 使用应用服务;4: 为正确...
  • 点击下载《Knative 云原生应用开发指南》 自 2018 年 Knative 项目开源后,就得到了广大开发者的密切关注。Knative 在 Kubernetes 之上提供了一套完整的应用 Serverless 编排服务,让应用开发者可以不用为底层的基础...

    file

    点击下载《Knative 云原生应用开发指南》

    自 2018 年 Knative 项目开源后,就得到了广大开发者的密切关注。Knative 在 Kubernetes 之上提供了一套完整的应用 Serverless 编排服务,让应用开发者可以不用为底层的基础设施分心,把更多的精力投入到业务逻辑上。

    Knative 的一个很重要的目标就是制定云原生、跨平台的 Serverless 编排标准。它的优势在于:

    • 基于 Kubernetes 实现 Serverless 编排;
    • 基于 Istio 实现服务的接入、服务路由的管理以及灰度发布等功能。

    今年 5 月份,我们推出了 Knative 系列文章,由阿里云容器平台技术专家牛秋霖(冬岛)及阿里云容器平台高级开发工程师李鹏(元毅)结合自身的实践经验,由浅入深的介绍了 Knative 的使用、剖析其内部实现。

    为了进一步方便大家理解 Knative,我们整理了系列文章中的 25 篇重点内容编排成书《Knative 云原生应用开发指南》,并开放分享给大家,希望能够帮助更多技术爱好者快速掌握 Knative 的应用 Serverless 编排技能,揭开 Knative 的神秘面纱。

    为什么你要读这本书?

    对于开发者而言,本书可以让你快速掌握 Knative 的应用 Serverless 编排技能;对于管理者或决策者而言,可以通过本书的介绍和案例深入了解企业为什么需要应用的 Serverless 编排;如何对普通应用进行 Serverless 编排;应用编排和 IaaS 无服务器计算的关系以及为什么会是 Knative 等问题。

    本书主要分为入门、进阶和实战三个部分。

    • 入门篇可以帮助你快速掌握 Knative 的核心理念和关键设计,让你对应用的云原生编排应该具备什么能力有一个清晰的认识;

    • 进阶篇会对 Knative 各大核心模块的高级功能进行更深入的介绍,剖析 Knative 是如何构建在 Kubernetes 之上的;

    • 实战篇给出了很多基于 Knative 的云原生实战,让你对 Knative 的使用有一个更直观的体感。

    file
    《Knative 云原生应用开发指南》目录

    在 All in Cloud 的时代,对云的驾驭能力已经成为企业的核心竞争力,云正在重塑企业 IT 架构。每个企业都在思考如何最大化利用“云”的能力,最大化发挥“云”的价值。而企业上云的过程中是要直接面对众多的云厂商和各种繁杂的云产品,比如最基本的 IaaS 资源,同样是 VM 在不同的云厂商就有不同的特性、不同的 OpenAPI 和不同的创建与销毁方式。

    这给企业上云带来了巨大的复杂度,大大打击了企业上云的积极性。所以对于上云的企业和提供云服务的厂商而言都在摸索寻找一个折中的平衡点,既能帮助企业上云,又能帮助云厂商释放云的能力。

    云原生理念的形成与完善

    云原生理念是在以上过程中逐渐形成和完善的。这套理念是协调所有参与方对服务上云逐渐形成的统一标准,它可以很好地帮助企业上云、帮助云厂商释放云的能力。云原生旨在以更标准化的方式衔接云厂商和上云企业:

    • 这种方式对于企业而言降低了上云和跨云的成本,让企业始终保有和云厂商议价的能力;
    • 对于云厂商而言,因为企业跨云迁移的成本低,所以只要能提供性价比更高的云服务,就能很容易的聚集大量用户。

    云原生是在不断促进整个系统的良性循环:既能让企业始终保有选择的能力,又能让优秀的云厂商快速服务更多的客户。如果客户的业务服务能像水一样低成本在不同云厂商之间流动,那么云厂商提供的服务就能像货币一样在客户之间流通。这是一个多赢的局面。

    Kubernetes 已经成为分布式资源调度和资源编排的事实标准,它屏蔽了底层基础架构的差异,帮助应用轻松运行在不同的基础设施之中。

    目前云原生生态已经在 Kubernetes 之上构建了大量的上层服务支撑框架。比如:服务网格 Istio、 Kubeflow 、各种上层服务的 Operator 等等。我们可以看到构建在 Kubernetes 之上的云原生操作系统的雏形开始出现,这是开发者最好的时代,极大地提升了业务创新的速度。

    无服务器(Serverless)的出现

    随着 Kubernetes 的普及,开发者已经不需要关心基础设施,有了更多的精力放在业务的核心逻辑上,随之而来的就是无服务器计算的出现。

    无服务器首先是在 IaaS 层的变革,用户无需提前准备冗余的 IaaS 资源,只需要在使用的时候自动扩容不用的时候自动缩容。因为应用真正需要的是 IaaS 资源的按需分配按量计费,而不是长期保有 IaaS 资源。

    无服务器这个词是从 Serverless 翻译过来的,其实 Serverless 除了基础 IaaS 资源的按量分配以外还有一层就是对应用的 Serverless 编排。

    Knative 出现的必然性

    IaaS 资源可以按需分配只是一个开始,当 IaaS 完成了 Serverless 进化以后,应用层应该如何做呢?比如:一个普通应用需要具备什么能力才能按量使用 IaaS 资源呢?对应用进行 Serverless 编排是否能保证应用可以很容易的在不同的云厂商之间跨云迁移?

    Knative 就是应用 Serverless 编排的云原生解决方案。

    Knative 建立在 Kubernetes 和 Istio 之上,通过 Kubernetes 的跨云能力能够让企业应用原生具备跨云迁移的能力。在多云、混合云以及云边端互通的时代,基于 Knative 的应用 Serverless 云原生编排能力可以极大降低企业上云的成本。

    云原生时代,如何在云上玩转 Knative?

    《Knative 云原生应用开发指南》一书中共收录了 8 篇具体的 Knative 开发实践案例,给出了很多基于 Knative 的云原生实战,借此讲述了如何正确使用 Knative 中的 Build、Serving 以及 Eventing 三大组件来发挥其作用,逐渐精简我们的代码;直观地展示了如何使用 Knative 来一步步简单高效地开发云原生应用,让你对通过  Knative 来实践 Serverless 有一个更全面的体感。

    期待《Knative 云原生应用开发指南》能够帮助更多的开发者真正开启云原生时代的 Serverless 之门,轻松解决迎面难题,避免踩坑!

    点击下载《Knative 云原生应用开发指南》

    file

    阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

    展开全文
  • 云计算原理与实践 Principles and Practice of Cloud: Computing 云计算原理与实践课程总览 原理与技术 开发与运维 概念与基础 应用与案例 虚拟化技术 云原生应用 云计算概述 桌面云 分布式存储 云操作系统 分布式...
  • 自 2018 年 Knative 项目开源后,就得到了广大开发者的密切关注...Knative 在 Kubernetes 之上提供了一套完整的应用 Serverless 编排服务,让应用开发者可以不用为底层的基础设施分心,把更多的精力投入到业务逻辑上。
  • 该文档来自OpenStack Days China 2016。HPE高级架构师梁建民发表的题为“基于Stackato的云原生应用开发”的主题演讲,欢迎下载!
  • 不过不管怎么说,12原则依旧是业界最为系统的云原生应用开发指南,我们可以把它作为一个非常有力的参考,但是也千万不要教条。 原则1:一份基准代码,多份部署 这个原则不管对微服务模式还是其他软件...

    http://www.sohu.com/a/149177203_671228

    本文节选自普元信息即将出版的《微服务企业架构最佳实践》一书,本文作者普元云计算架构师宋潇男,为该书的合著者之一。转载本文需注明出处:微信公众号EAWorld,违者必究。

    作者自序:

    12原则的提出已有五年之久,可惜业界一直缺乏一篇对其进行简明解读的指导性文章,所以我决定写这样一篇文章。在微服务模式的大背景下,力求对12原则的来龙去脉做出明确和完备的解释,并对12原则原文的含糊之处做出澄清。如果各位读者对本书的其他内容感兴趣,那么也敬请关注我们的公众号eaworld。

    12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出(原文参见12factor.net),目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。距离12原则的提出已有五年之久,12原则的有些细节可能已经不那么跟得上时代,也有人批评12原则的提出从一开始就有过于依赖Heroku自身特性的倾向。不过不管怎么说,12原则依旧是业界最为系统的云原生应用开发指南,我们可以把它作为一个非常有力的参考,但是也千万不要教条。

    原则1:一份基准代码,多份部署

    这个原则不管对微服务模式还是其他软件开发模式来说都非常基本,所以被列为12原则的第一条,该原则包括如下四个子原则

    1. 使用代码库管理代码,一般是Git或者SVN,这个要求非常初级,相信本书的读者都会遵守。

    2. 一份基准代码(即一个代码库)对应一个应用。如果通过一份基准代码可以编译出多个应用,那么应该考虑将该基准代码按应用拆分为多份;如果一个应用需要多份基准代码,那么要么考虑将多份基准代码合并,要么考虑将该应用按基准代码拆分为多个。

    3. 不允许多个应用共享一份基准代码,如果确实需要共享,那就把需要共享的基准代码的稳定版本发布为类库,然后通过依赖管理策略进行加载。

    4. 同一应用的多份部署可以使用同一份基准代码的不同版本,但是不可以使用不同的基准代码,类似原则2,使用不同基准代码的应用不应被视为同一应用。

    违反子原则2和3,会给代码管理和编译工作带来麻烦:

    1. 如果一份基准代码可以编译出多个应用,那么这几个应用之间必然会存在不清晰的依赖关系,随着时间的推移,这种依赖关系会变得愈加混乱,以至于修改一个应用的代码,会给其他应用带来不可预知的影响。这样的基准代码显然极难维护。

    2. 基准代码的划分和应用的划分非常类似,也是系统边界的一种体现,如果一个应用需要从多份基准代码编译,那么多数情况下这个应用的内外部边界问题会存在问题。如果边界不存在问题,那么请将多份基准代码合并为一份,而不是维持这种古怪的设计。

    3. 如果多个应用不是通过类库,而是直接共享一份基准代码,那么这份被共享的基准代码会很难维护,对这份基准代码的修改必须谨慎考虑对多个应用可能造成的影响。正确的方式是将这份基准代码发布为类库,保持清晰的边界和接口约定供其它应用调用。

    原则2:显式声明依赖关系

    这里的依赖指所有的依赖,包括应用程序本身的类库和操作系统层面被应用程序所使用的库文件或者其他二进制文件,都必须进行显示声明,并对版本做出明确的指定。不要假定运行环境中已经存在应用所需要的任何依赖项,而是应该假定什么都没有(即使有也很可能不是应用所需要的版本)。

    如果使用容器方式进行部署,容器的基础镜像很可能是Busybox或者Alpine之类的迷你Linux,那么就几乎等于什么都没有。如果使用微服务模式,理想情况下,微服务之间的依赖关系也应该进行显示声明。

    以前我们往往不会对依赖做如此严格的管理,因为应用不会有太大规模的部署,也不会进行频繁的发布,如果发现运行环境里缺少某些依赖,那么就临时手工处理一下,也不是什么太大的问题。如今在微服务模式下,应用的部署规模大、发布频率高,还记得前文所说的“不可变服务器”吗?如果这个时候还是使用原有的模式,则会带来混乱。

    声明依赖的方式有很多,常见的方式是使用依赖清单,根据依赖清单进行依赖检查,同时使用依赖隔离工具保证应用不会调用系统中存在但是依赖清单中未声明的依赖项;另一种方式是使用容器技术,将应用和依赖打包为容器镜像,依赖的声明和隔离就一并解决了。

    原则3:在环境中存储配置

    首先需要明确的是,这里的配置指与部署环境有关的配置,例如:

    • 数据库、消息代理、缓存系统等后端服务的连接配置和位置信息,如URL、用户名、密码等。

    • 第三方服务的证书。

    • 每份部署独有的配置,例如:域名、连接数、与部署目标环境资源规模有关的JVM参数等。

    所有部署中都相同的信息,例如原则2里讲到的依赖信息,不在本原则所讨论的范围内一些虽然在不同的部署中有所差异、但是和业务相关的信息,例如资金结算的转换比例,也不属于本原则所讨论的配置。

    我想大多数的开发者都知道如何通过使用配置文件实现配置和代码的分离,但是这种方式仍然存在一些缺点,例如:

    1. 配置文件容易被开发人员不小心提交到代码库中,造成密码、证书等敏感信息泄露。提交到代码库中的配置文件还容易被和应用一起部署到目标环境中,很可能会导致在目标环境中应用了错误的配置或者造成配置冲突。

    2. 配置文件会分散在不同的目录中,并且有不同的格式(配置文件的格式往往与开发语言和框架相关),这会给配置的统一管理造成困难。

    为了避免上述问题,本原则要求将在环境中存储配置。一种典型的方式是把配置存储在环境变量中,这会使配置和代码彻底的分离,格式上也与开发语言和框架再无瓜葛,并且也不会被误提交到代码库中。还可以使用Spring Cloud Config Server这类配置管理服务进行配置推送,并将配置的历史版本和变更原因也一起管理起来。

    原则4:把后端服务当作附加资源

    这里的后端服务指的是应用运行所依赖的各种服务,例如数据库、消息代理、缓存系统等,对于云原生应用来说,往往还会有日志收集服务、对象存储服务、以及各种通过API访问的服务;当作附加资源指的是把这些服务作为外部的、通过网络调用的资源。

    该原则有如下几层含义:

    1. 不要将这些服务放在应用本地:云原生应用要求应用本身无状态化,那么状态信息就应该存储在外部服务中(参见不可变服务器)。同时,微服务模式要求应用责权单一以实现可靠性和扩展性,如果在应用本地放置数据库,那么微服务平台将无法通过更换应用的故障实例实现应用的高可用性,也无法通过自动化的横向伸缩实现扩展性,因为应用实例内包含两种性质完全不同的软件(应用和数据库),无法对两者使用同一种方式进行横向扩展。另外,如果将这些服务放在应用本地,那么也无法通过充分利用云平台提供的能力简化运维工作,例如,如果在应用本地放置数据库,而不是使用云平台提供的数据库服务,那么显然无法利用数据库服务提供的自动备份、安全、和高可用等特性。

    2. 通过URL或者服务注册/认证中心访问这些后端服务:应用应该能够在不进行任何代码修改的情况下,在不同的目标环境中进行部署,应用不应该和后端服务的任何一种具体实现存在紧耦合关系。

    3. 类似“显式声明依赖关系”原则,应用最好也能够对其使用的这些后端服务进行显示声明,以方便云平台对服务资源进行自动绑定,在后端服务出现故障的时候,云平台也能够对其进行自动恢复。

    原则5:严格分离构建、发布和运行

    在本原则中,构建、发布和运行这三个概念可能和从前有所不同,因此有必要首先对其进行明确:

    • 构建指的是将应用代码转化为执行体的过程:构建时会拉取特定版本的代码和依赖项,将其编译为二进制文件(针对编译型语言),并和资源文件一起打包。

    • 发布指的是将构建的结果和部署所需的配置相结合,并将其放置于运行环境之中。

    • 运行指的是将发布的结果启动为运行环境中的一个或多个进程。

    本原则要求构建、发布和运行这三个步骤严格区分:

    1. 禁止直接修改运行状态的代码或者对应用进行打补丁,因为这些修改很难再同步回构建步骤,这时运行状态的代码就成为了“孤本”。同时,也不应该在运行期间修改应用的配置,配置的修改应该仅限于发布阶段(参见不可变服务器)。

    2. 运行这一步骤应该非常简单,仅限于启动进程,资源文件的关联应仅限于构建阶段,配置的结合应仅限于发布阶段。

    同时,每一次发布都应该对应一个唯一的发布ID,发布的版本应当像一个只能追加的账本,一旦发布就不能修改。这么做的好处是:

    1. 每一份运行状态的代码都可以在对应的发布和构建阶段找到它的来源,这是实现重新发布、故障实例的自动替换、发布出错后的版本回退等机制的基础。

    2. 运行步骤非常简单,这样在硬件重启、实例故障和横向扩展等情况下,应用可以简单和快速的实现重启。

    原则6:以一个或多个无状态的进程

    运行应用

    本原则要求应用进程的内部不要保存状态信息,任何状态信息都应该被保存在数据库、缓存系统等外部服务中。应用实例之间的数据共享也要通过数据库和缓存系统等外部服务进行,直接的数据共享不但违反无状态原则,还引入了串行化的单点,这会为应用的横向扩展带来障碍。

    在微服务模式下,应用不应该在自身进程内部缓存数据以供将来的请求使用,因为微服务模式以多实例方式运行应用,将来的请求多半会被路由到其他实例,此时虽然可以使用粘滞会话将请求保持在同一个实例上,但是无论是云原生应用还是微服务模式都极力反对使用粘滞会话,原因如下:

    1. 很难对粘滞会话实现负载均衡,因为粘滞会话的均衡性不仅决定于负载均衡策略,还和会话本身的行为相关,例如,可能存在应用某些实例上的会话已经大量退出,而另一些实例上的会话依然处于活动状态,此时这两部分实例的负载处于不均衡状态,而负载均衡器无法将活动会话转移到空闲的应用实例。

    2. 启动新的应用实例不会立即提高应用的整体处理能力,因为这些新实例只能承接新会话,旧的会话依旧粘滞在旧的应用实例上。

    3. 应用实例退出会导致会话丢失,所以在实例发生故障时,即使云平台可以对故障实例进行自动替换,也会导致用户数据丢失。即使是对应用实例进行人工维护,也需要在维护之前对该实例上的会话进行转移,这往往意味着需要编写复杂的业务代码。

      在传统模式下,可以通过在双机之间进行会话复制来实现对用户无感知的单机下线维护(虽然会付出处理能力减半的代价),但是在微服务模式下,应用的实例数量往往远不止两个,在大量的实例之间进行会话复制会使实例之间原本非常简单的逻辑关系复杂化,此时将无法通过云平台对其进行无差别的自动化维护。另外,在实例之间进行会话复制也意味着实例之间存在着直接的数据共享,这会为应用的横向扩展带来障碍。

    所以,粘滞会话是应用实现可用性和扩展性的重要障碍,使用粘滞会话显然是种得不偿失的选择。更好的实现方式是将会话信息存储在缓存服务中。

    原则7:通过端口绑定提供服务

    服务端应用通过网络端口提供服务,这点毋庸置疑,但是本原则还有如下两个深层次的含义:

    1. 无论是云原生应用还是微服务模式都要求应用应该完全自我包含,而不是依赖于外部的应用服务器,端口绑定指的是应用直接与端口绑定,而不是通过应用服务器进行端口绑定。

      如果一定要使用应用服务器,那就使用嵌入式应用服务器,无论是云原生应用还是微服务模式都极力反对将多个应用放置于同一个应用服务器上运行,因为在这种模式下,一个应用出错会对同一个应用服务器上的其他应用造成影响,也无法针对单一应用做横向扩展。

    2. 端口绑定工作应该由云平台自动进行,云平台在实现应用到端口的绑定之外,还需要实现内部端口到外部端口的映射和外部端口到域名的映射。在应用的整个生命周期内,应用实例会经历多次的重新部署、重启或者横向扩展,端口会发生变化,但URL会保持不变。

    原则8:通过进程模型进行扩展

    与通过进程模型进行扩展相反的方式是通过线程模型进行扩展,这是一种相对较为传统的方式,典型的例子是Java应用。当我们启动一个Java进程的时候,通常会通过JVM参数为其设置各个内存区域的容量上下限,同时还可能会在应用层面为其设置一个或者多个线程池的容量上下限,当外部负载变化时,进程所占用的内存容量和进程内部的线程数量可以在这些预先设置好的上下限之间进行扩展,这种方式也被称为纵向扩展或者垂直扩展。

    但是这种方式存在一些问题,首先,在进程的内存容量和线程数量提高时,应用的某些性能指标可能不会得到同步提高,甚至可能会下降(这往往是因为程序对某些无法扩展的资源进行争用所造成的),这种参差不齐的性能扩展对外部负载提高的承接能力会很不理想,有时甚至会适得其反;

    其次,为了使进程本身可以完成纵向扩展,还需要在虚拟机层面或者容器层面为其预留内存资源和对应的CPU资源,这会造成大量的资源浪费(当然,也可以使虚拟机或者容器跟随进程一起进行纵向扩展,这在技术上是可行的,但是会为虚拟机或者容器管理平台的资源调度造成一些不必要的困难,例如频繁的虚拟机迁移或者容器重启)。

    所以,现在更为推崇使用“固定的”进程(对前面Java应用的例子来说,就是固定的内存容量和线程池容量),在外部负载提高时,启动更多的进程,在外部负载降低时,停止一部分进程,这种方式就是本原则所说的通过进程模型进行扩展,有时候也被称为横向扩展或者水平扩展。

    这种扩展方式的好处是,在进程数量增加的时候,应用的各种性能指标会得到同步的提高,这种提高即使不是线性的,也会按照一种平滑和可预期的曲线展开,可以更为稳定的应对外部负载的变化。

    云原生应用和微服务模式极力推崇将通过进程模型进行扩展作为唯一的扩展方式,除了前文所述,还有一个原因是进程是云平台可以操作的最小运行单元(当然,可以通过其他技术手段去操作线程,但是那不会成为云平台的通用技术特性),云平台可以根据各个层面的监控数据,通过预设规则决定是否为应用增加或者减少进程,例如,当前端的负载均衡器检测到访问某个后端应用的并发用户数超过某个阈值时,可以立即为这个后端应用启动更多的进程,以承接更大的负载,同时还可以选择是否对该应用后端的数据库进行扩展。

    如果此时选择对应用进行纵向扩展,则云平台既不知道应用处理能力的变化,也无法对这种变化进行预期管理,更无法使应用的前后端对这种变化进行联动,即该应用的扩展行为脱离了云平台的管理。在微服务模式下,如果大量的进程都采用纵向扩展方式,则会为平台的资源调度带来极大的混乱。

    注3:该原则似乎更适合被称为横向扩展原则,但是为了和12原则的原文保持一直,这里我们仍然将其称为“通过进程模型进行扩展”。

    原则9:快速启动和优雅终止

    可最大化健壮性

    该原则要求应用可以瞬间(理想情况下是数秒或者更短)启动和停止,因为这将有利于应用快速进行横向扩展和变更或者故障后的重新部署,而这两者都是程序健壮性的体现。

    前文不止一次提到过应用的快速启动,在理念章节的开头,我们提到过平价的进程生成对多道程序设计至关重要,而微服务模式在某种程度上可以认为是多道程序设计在Web领域和分布式系统下的进一步扩展,这里所说的平价进程生成指的是操作系统的一种特性,是应用快速启动的基础,除此之外为了保证应用可以在数秒内完成启动,还需要大量的优化工作,需要开发人员掌握复杂的调优技术与工具,有些工作必须在应用的初始设计阶段完成,例如:如果应用体积过大或者是引用了太多的库文件,那么再多的后期优化也无法将启动时间降低到数秒以内。

    “原则5:严格分离构建、发布和运行”中我们还提到,应用的运行步骤应该非常简单,这里的“简单”也隐含着快速的意思,目的是为了在硬件重启、实例故障和横向扩展等情况下,应用可以快速的实现重启。除此之外,“原则6:以一个或多个无状态的进程运行应用”也与应用的快速启动有关,遵守无状态原则,使用云平台提供的缓存服务,而不是在应用内部加载缓存,可以避免在应用启动期间进行耗时的缓存预热。

    比起应用的快速启动,优雅终止(Graceful Shutdown)需要考虑的问题会更为广泛一些。优雅终止需要尽可能降低应用终止对用户造成的不良影响(对于微服务应用,用户可能是人,也可能是其他微服务)。

    对于短任务来说,这一般意味着拒绝所有新的请求,并将已经接收的请求处理完毕后再终止;对于长任务来说,这一般意味着应用重启后的客户端重连和为任务设置断点并在重启后继续执行。除此之外,优雅终止还需要释放所有被进程锁定的资源,并对事务的完整性和操作的幂等性做出完备的考虑。

    最后,应用还必须应对突如其来的退出,在硬件出现故障时或者进程崩溃时,应用需要保证不会对其使用的数据造成损坏,遵守无状态原则、将数据交由后端服务处理的应用可以很容易的将应对突然退出的复杂度外部化。

    原则10:开发环境与线上环境等价

    本原则的浅层次含义是要求在开发环境和线上环境中使用相同的软件栈,并尽可能为这些软件栈使用相同的配置,以避免“It works on my machine.”这类问题。本原则反对在不同的环境中使用不同的后端服务,虽然可以使用适配器或者在代码中做出兼容性考虑以消除后端服务的差异,但是这将牵扯开发人员和测试人员大量的精力以保证这些适配器和代码确实可以按预期工作,在应用的整个开发周期中,这将积累极大的额外工作量,是一种非常不必要的资源浪费。

    近年来个人电脑的性能大幅提高,开发人员一度得以在本地开发环境中运行与生产环境中一致的软件栈,而不是像曾经那样采用轻量的替代方案。但是随着云原生应用和微服务模式的流行,情况又发生了微妙的变化:开发微服务时需要依赖云平台提供的基础服务和其他微服务,越来越难以把这些服务完整的运行在本地,与此同时,完全的在线开发愈发成为一种趋势,那样的话至少在软件栈上开发环境和线上环境就真的没有任何区别了。

    在我编写这段文字的时候,Red Hat公司刚好在洽购在线开发环境创业公司Codenvy用以充实他们的云平台产品OpenShift,而另一家与Codenvy类似的创业公司Cloud9在差不多一年前被Amazon公司收购。

    本原则的深层次含义是尽量缩小开发环境和线上环境中时间和人员的差异。开发环境中的代码每天都在更新,而这些更新往往会累积数周甚至数月才会被发布到线上环境,这是开发环境和线上环境在时间上的巨大差异;开发人员只关心开发环境,运维人员只关心线上环境,开发人员和运维人员在工作上鲜有交集,这是开发环境和线上环境在人员上的巨大差异。

    对于前一个差异,本原则要求更为密集和频繁的向线上环境发布更新,要求建立机制以保障开发人员可以在数小时甚至数分钟内既可将更新发布到线上,这也正是本章理念部分中持续交付所提倡的;对于后一个差异,本原则要求开发人员不能只关心开发环境中自己的代码,更要密切关注代码的部署过程和代码在线上的运行情况,这也正是DevOps所提倡的。

    原则11:把日志当作事件流

    应用程序应该将其产生的事件以每个事件一行的格式按时间顺序输出,这点毋庸置疑,但是本原则想说的其实是:应用程序不要自行管理日志文件。

    以前我们习惯将应用程序产生的事件分门别类的输出到不同的日志文件,并为每个日志文件指定在本地文件系统上的存储位置,为了避免单一日志文件过大,还会为它们配置轮转策略。

    该原则极力反对上述做法,而是要求应用程序将日志以事件流的方式输出到标准输出STDOUT和标准错误输出STDERR,然后由运行环境捕获这些事件流,并转发到专门的日志处理服务进行处理。这样做的原因是:

    1. “原则6:以一个或多个无状态的进程运行应用”要求应用程序无状态,那么应用程序就不应该将日志文件这种价值信息存储在本地文件系统上。当然,可以在本地运行一个日志收集进程读取日志文件,并将其转发到专门的日志处理服务,以保证价值信息不被意外丢弃,但是这带来了如下问题:

    • 需要提供一种机制以保证日志收集进程可靠运行。

    • 需要通过配置文件告知日志收集进程去哪里读取日志文件。

    • 需要在应用程序所在的虚拟机或者容器上为日志收集进程开放一个网络端口以供其发送日志内容,这不仅增加了网络的复杂度,还给网络安全带来了隐患。

    由此可见,直接将日志输出到STDOUT和STDERR并由运行环境对其进行捕获远比这种方案来的简洁和可靠。

    2. 在存在专门的日志处理服务时,由应用程序自行对日志进行分类显得死板和毫无必要;只需将日志以事件流方式发送给日志处理服务,日志处理服务可以对这些日志按不同视角进行灵活的分类,而不是受限于一种既定的分类规则。

    3. “原则6:以一个或多个无状态的进程运行应用”中还提到“微服务模式以多实例方式运行应用,将来的请求多半会被路由到其他实例”,所以单个应用实例的日志无法描述完整的业务操作,不具备业务层面的价值。必须将应用所有实例的日志汇总到日志处理服务,由日志处理服务按特定规则(如按用户ID或者对象ID)对其进行聚合,才能完整展现应用在业务层面的操作过程。

    应用在以多实例方式运行时,应用的单个实例可能会因为软硬件故障而重启,或者被横向扩展机制创建和销毁,所以必须将应用所有实例的日志汇总,才能完整的描述应用的运行情况。

    原则12:后台管理任务当作一次性进程运行

    这是12原则的最后一条,也是最晦涩的一条。如果你在看过原文之后觉得哪里有些不大对,不必担心,因为很多人的想法和你一样。在本节的开头曾提到有人批评12原有过于依赖Heroku自身特性的倾向,这些批评多半可能是本原则导致的。

    事实上,通过SSH接入线上环境并使用脚本语言执行管理任务的做法已经不再被提倡,无论是云原生应用还是微服务模式都极力反对这种做法,原因可以参见“理念五:不可变服务器”和“理念六:提供声明式接口”。另外还有一个原因显而易见:你的应用有数个或者数十个实例,那么应该登录到哪个实例中执行管理任务呢?如果在管理任务执行的过程中,所在实例因为软硬件故障重启,或者被横向扩展机制销毁,那又该怎么办?

    正确的做法是,如果管理任务是修改应用配置,那么应该通过配置管理服务进行操作,参见“原则3:在环境中存储配置”;如果管理任务是批处理任务,例如数据的迁移、清洗或者检查,那么应该通过云平台的批处理机制进行操作,大多数的云平台都会提供这种机制,例如Kubernetes的Jobs。

    本原则还提到“应用的管理进程应该和应用的常驻进程运行于同一环境,并使用相同的代码、版本和配置”,这是一条比较有价值的建议,可以避免由于环境或代码等不一致造成的一些潜藏问题。虽然现在不提倡通过SSH接入应用常驻进程所在的环境并执行管理任务,但是如果你使用容器技术,那么很容易通过容器模板创建一个和应用常驻进程一致的运行环境,并在其中执行管理任务。

    关于作者:宋潇男

    Unix和分布式系统专家,网格时代的幸存者,在云计算行业有近十年的研发和市场工作经验,对操作系统、中间件和云平台有深入研究和大型项目经验。曾在华为云计算部门负责产品规划、商业洞察、以及EMEA地区的市场推广与技术合作工作。现任普元云计算架构师。

    关于EAWorld

    微服务,DevOps,元数据,企业架构原创技术分享EAii(Enterprise Architecture Innovation Institute)企业架构创新研究院旗下官方微信公众号。

    展开全文
  • 随着微服务和云原生相关技术的发展,应用程序的架构模式已从传统的单体架构或分层架构转向了分布式的计算架构。尽管分布式架构本身有一定的开发成本和运维成本,但它所带来的收益是显而易见的。 在实现分布式应用...

    前言

    随着微服务和云原生相关技术的发展,应用程序的架构模式已从传统的单体架构或分层架构转向了分布式的计算架构。尽管分布式架构本身有一定的开发成本和运维成本,但它所带来的收益是显而易见的。

    在实现分布式应用程序时,我们必须考虑两个因素:网络协议和传输载荷的编码。从最早的 RMI+Java 原生序列化,到 HTTP+JSON/XML,业界一直在尝试寻找一种兼具高效性和可读性的方案。虽然在实践微服务的过程中,大家普遍愿意采用更具语义化的 HTTP+JSON 形式,但这种形式有其自身的局限性,比如其网络传输载荷低效、接口规范松散等。

    正是在这样的背景下,gRPC 应运而生,借助优异的性能和谷歌的大力推广,gRPC 受到众多大厂青睐。目前,gRPC 已经成为云原生计算基金会的孵化项目,并被广泛应用于众多开源项目和企业级项目中。

    gRPC 最大的特点是高性能,HTTP/2+protocol buffers 的组合使其在性能方面具备了天然的优势,这也是 gRPC 广受欢迎的重要原因。但是,相对于更成熟稳定的 HTTP+JSON 组合,gRPC 的风险不容低估,比如其协议不够稳定、社区相对较小等,这些都是在做技术选型的时候需要考虑的重要因素。正如我们所熟知的,从来就没有“银弹”,作为技术从业者,我们只能去分析和对比各种可用的技术,根据自身需求选择最合适的技术方案。

    如今,软件应用程序会经常通过计算机网络,借助进程间通信技术实现彼此间的连接。gRPC 是一种基于高性能 RPC(远程过程调用)的现代进程间通信风格,适用于构建分布式应用程序和微服务。随着微服务云原生应用程序的出现,gRPC 的采用率正在呈指数级增长。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    本文由浅入深,介绍了 gRPC 相关技术,从通信模式到消息编码,从服务跟踪到容器化部署,并且文中的所有示例都提供了 Java 语言和 Go 语言的两种实现。不管你是只想了解这项新技术,还是想为自己的项目寻找新方案,相信都能从本文中找到感兴趣的话题。

    目录

    我们以实际用例阐述理论、概念的方式编排了本文的内容。全文广泛使用 Go 和 Java 编写示例代码,帮助你实际运用每个概念。我们将本文分为 8 章。

    第 章 gRPC 入门;你将了解 gRPC 的基础知识,并将它与 REST、GraphQL 和其他RPC 技术等类似的进程间通信风格进行对比。

    现代软件应用程序很少是孤立运行的,相反,它们会通过计算机网络连接在一起,并且以互相传递消息的方式进行通信和协调。因此,现代软件系统是分布式软件应用程序的集合,这些应用程序在不同的网络位置运行,并且运用不同的通信协议在彼此间传递消息。例如,一个在线零售软件系统会由多个分布式应用程序组成,如订单管理应用程序、商品目录应用程序和数据库等。为了实现在线零售系统的业务功能,这些分布式应用程序需要相互连接。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    第 章 开始使用 gRPC;你将初次体验使用 Go 或 Java 构建完整的 gRPC 应用程序。

    关于 gRPC 的理论知识已经介绍得差不多了,接下来根据第 1 章介绍的知识从头构建真正的 gRPC 应用程序。本章将分别使用 Go 和 Java 构建简单的 gRPC 服务以及调用该服务的客户端应用程序。在此过程中,我们将学习如何使用 protocol buffers 声明 gRPC 服务定义、生成服务器端骨架和客户端存根、实现服务的业务逻辑、在 gRPC 服务器上运行我们实现的服务并通过 gRPC 客户端应用程序调用该服务。

    本章继续使用第 1 章的在线零售系统,并在这个系统中构建一个管理零售商店中所有商品的服务。该服务可以进行远程访问,服务的消费者能够向系统添加新的商品,并可以根据所提供的商品 ID 检索商品详情。我们将使用 gRPC 建模该服务及其消费者。你可以使用任意喜欢的语言来实现这些功能,但本章将使用 Go 和 Java 来实现。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    第 章 gRPC 的通信模式;在这一章中,我们将使用真实的示例探索 gRPC 通信模式。

    第 1 章和第 2 章介绍了 gRPC 进程间通信技术的基础知识,其中还涉及构建简单的 gRPC 应用程序。到目前为止,我们已经完成了定义服务接口、实现服务、运行 gRPC 服务器以及通过 gRPC 客户端应用程序远程调用服务等操作。客户端和服务器端之间的通信模式是简单的请求–响应风格的通信,这里每个请求都会得到一个响应。但是,借助 gRPC,可以实现不同的进程间通信模式(也称 RPC 风格),而不仅仅是简单的请求–响应模式。

    本章将讨论 gRPC 应用程序的 4 种基础通信模式:一元 RPC、服务器端流 RPC、客户端流 RPC 以及双向流 RPC。在这个过程中,我们会使用一些真实用例来展示每种模式,使用 gRPC IDL 进行服务定义,并使用Go 语言来实现服务和客户端。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    第 章 gRPC 的底层原理;如果你是 gRPC 高级用户,并且对 gRPC 的底层原理感兴趣,那么可以通过这一章来学习这些知识。这一章讲述在服务器端和客户端之间进行 gRPC 通信的步骤以及如何通过网络实现。

    本章将探索 gRPC 通信流的实现方式、所使用的编码技术以及 gRPC 中的底层网络通信技术的使用方法等,介绍涉及客户端调用给定 RPC 的消息流,并探讨其他相关问题,包括如何将其编排为网络上的 gRPC 调用、如何使用网络通信协议、如何在服务器端解排,以及如何调用对应的服务和远程函数等。

    另外,本章将 protocol buffers 作为 gRPC 的编码技术,将 HTTP/2 作为gRPC 的通信协议,并介绍它们的实现方法,最后研究 gRPC 实现架构以及围绕它所构建的语言支持栈。尽管对大多数 gRPC 应用程序来说,这里要讨论的底层细节作用有限,但在设计复杂的 gRPC 应用程序或设法调试现有的应用程序时,理解底层通信细节很有帮助。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    第 章 gRPC:超越基础知识;这一章讲述 gRPC 的一些非常重要的高级特性,如拦截器、截止时间、元数据、多路复用、负载均衡等。

    当构建真正的 gRPC 应用程序时,可能需要增强它们的各种能力以满足需求,比如拦截 RPC 的输入和输出、弹性处理网络延迟、处理错误、在服务和消费者之间共享元数据等。

    本章将介绍一些关键的高级 gRPC 功能,包括使用 gRPC 拦截器在服务器端和客户端拦截 RPC、使用截止时间来指定等待 RPC 完成的时间、服务器端和客户端错误处理的最佳实践、使用多路复用在同一台服务器上运行多个服务、在应用程序间共享自定义的元数据、在调用其他服务的时候使用负载均衡和命名解析技术,以及压缩 RPC 调用以高效使用网络带宽。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    第 章 安全的 gRPC;你将全面理解如何保护通信通道、如何认证以及如何控制用户对gRPC 应用程序的访问。

    基于 gRPC 的应用程序会通过网络彼此进行远程通信,这需要每个gRPC 应用程序向其他需要与之通信的应用程序暴露其入口点。从安全的角度来看,这并不是一件好事。拥有的入口点越多,攻击面就越广,受到攻击的风险也就越高。因此,保护通信和保护入口点的安全对于任何真实的使用场景都至关重要。每个 gRPC 应用程序都必须能够处理加密的消息,加密所有节点间的通信,并对所有消息进行认证和签名等。

    本章将介绍一组安全基础措施和模式,以应对我们在启用应用级安全性时所面临的挑战。简而言之,我们将探索如何保护微服务之间的通信通道,并对用户进行认证和访问控制。让我们从保护通信通道开始讨论吧。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    第 章 在生产环境中运行 gRPC你将了解 gRPC 应用程序的整个开发生命周期。我们将讨论测试;gRPC 应用程序、与 CI/CD 集成、在 Docker 和 Kubernetes 上部署与运行以及观察 gRPC 应用程序。

    前面的章节涵盖了设计和开发 gRPC 应用程序的各个方面。现在该深入研究在生产环境中运行 gRPC 的细节了。本章将讨论如何为 gRPC 服务和客户端开发单元测试和集成测试,以及如何将它们与持续集成工具集成到一起。随后,将转向 gRPC 应用程序的持续部署,这里会探讨一些在虚拟机(VM)、Docker 和 Kubernetes 上的部署模式。最后,为了在生产环境中运行 gRPC 应用程序,需要有一个坚实的可观察性平台。在此方面,我们会讨论面向 gRPC 应用程序的多种可观察性工具,还会探讨 gRPC 应用程序的问题排查和调试技术。下面从测试这些应用程序开始进行讨论。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    第 章 gRPC 的生态系统;在这一章中,我们将讨论围绕 gRPC 所构建的有用的支撑组件。在使用 gRPC 构建真正的应用程序时,这些项目中的大多数是有用的。

    本章将讨论一些并非 gRPC 核心实现的项目,但它们对于构建和运行真正的 gRPC 应用程序非常有帮助。这些项目是 gRPC 生态系统父项目的一部分,对于运行 gRPC 应用程序来说,这里提到的技术都不是强制要求的。如果你的需求与这些项目提供的功能类似,请探索并评估这些技术。

    我们首先讨论 gRPC 网关。

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    谷歌架构师分享gRPC与云原生应用开发Go和Java为例文档

     

    需要这份【gRPC与云原生应用开发:以Go和Java为例】文档的小伙伴,可以转发此文关注小编,私信小编【技术】来获取!!

    读者对象

    本文最直接的读者是使用不同的进程间通信技术构建分布式应用程序和微服务的开发人员。在构建这样的应用程序和服务时,开发人员需要学习 gRPC 的基础知识,以及何时和如何将其用于服务间通信、在生产环境中运行 gRPC 服务的最佳实践。同时,对于采用微服务或云原生架构并设计服务间通信的架构师来说,也能从本文中受益匪浅,这是因为文中对比了 gRPC 和其他的技术,指出了何时应该使用它、何时应该避免使用它。

    我们假定开发人员和架构师都对分布式计算的基础,如进程间通信技术、面向服务的架构(SOA)和微服务,有基本的了解。

    展开全文
  • 云原生应用的12要素

    2021-01-27 11:04:21
    在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生,而针对云原生应用开发的最佳实践原则,12-Factor脱颖而出,同时也带来了新的解读。12-Factor,...
  • 云原生应用敏捷开发之旅.pptx
  • 原文转自InfoQ云原生应用的基本概念云原生应用,是指原生为在云平台上部署运行而设计开发的应用。公平的说,大多数传统的应用,不做任何改动,都是可以在云平台运行起来的,只要云平台支持这个传统应用所运行的...

    原文转自InfoQ

    一、云原生应用的基本概念

    云原生应用,是指原生为在云平台上部署运行而设计开发的应用。公平的说,大多数传统的应用,不做任何改动,都是可以在云平台运行起来的,只要云平台支持这个传统应用所运行的计算机架构和操作系统。只不过这种运行模式,仅仅是把虚拟机当物理机一样使用,不能够真正利用起来云平台的能力。

    二、云原生应用与相关技术理念的关系

    1.云原生应用与云平台的关系

    云平台是用来部署、管理和运行SaaS云应用的。SaaS是云计算的三种服务模型之一,即跟业务相关的应用即服务。云计算最根本的特性是提供按需分配资源和弹性计算的能力,而云原生应用的设计理念就是让部署到云平台的应用能够利用到云平台的能力,实现按需使用计算资源和弹性伸缩,成为一个合格的SaaS应用。

    2. 云原生应用与12要素的关系

    12要素是PaaS平台Haroku团队提出的应用设计理念,是有关SaaS应用设计理念的红宝书;可以说,12要素应用就是云原生应用的同义词。

    3. 云原生应用与Stateless和Share Nothing架构的关系

    为了实现水平伸缩的能力,云原生应用应该是Stateless和Share Nothing的。

    4. 云原生应用与微服务架构的关系

    微服务架构是实现企业分布式系统的一种架构模式,即将一个复杂的单体应用按照业务的限定上下文,分解成多个独立部署的组件。这些独立部署的组件,就称为微服务。而在谈论云原生应用与微服务架构关系的时候,根据上下文不同可能是有两种不同的含义。一种含义是宏观的云原生应用,即将整个分布式系统看作一个应用,这种语境下,微服务架构是实现云原生应用的一种架构模式;另一种含义是微观的云原生应用,即每个微服务是一个应用,这种语境下,每个微服务要按照云原生应用的设计理念去设计,才能真正实现微服务架构所要达到的目的,即让分布式系统具备按需使用计算资源和弹性伸缩的能力,这里“应用”和“服务”变成了同义词。

    5. 云原生应用与宠物和牲畜的关系

    云原生应用的设计理念是希望把应用当作牲畜来养,而不是当作宠物来养。部署一个云原生应用的集群,就好像圈养了一大群奶牛,目的主要是为了产奶,对待每头牛就像对待机器一样没有什么感情,死了一头就再养一头,而不会像对待宠物那样细心呵护。而传统应用,因为往往因为对运行环境依赖严重,运维人员需要细心照顾、维护,万一出现宕机,一般要在原来的服务器上修复问题再恢复运行;如果恢复不了,整个应用系统就瘫痪了,因此会令运维人员像“宠物死了”一样伤心。

    三、云原生应用的设计理念——12要素

    1. 一个应用对应一套代码多次部署

    这一理念主要是强调应用应该清晰明确地区分什么是应用,什么是部署。一个应用对应的就是一个代码仓库,一个软件产品;一次部署对应的是一个运行起来的应用;因此应用与部署的关系是一对多。这种一对多的关系也体现了应用代码的可重用性,一套代码可以重用到多次的部署中去;不同部署之间的区分是配置,而代码是共享的。对应用架构来说,最基本的是要区分运行时行为和非运行时行为,一个应用的非运行时的代表就是一个代码仓库,它可能有多个运行时实例,每个实例就是一次部署。

    2. 明确地声明并隔离依赖的程序库

    不管用什么语言开发应用,编程语言一定都有管理程序库的机制。这一理念强调所有依赖库一定要明确的声明出来,因为只有这样,在运行应用的时候,才能保证所有运行所需要的程序库都正确部署到了云环境中。

    3. 将配置存储到部署环境中

    正像前面所说,一个应用的不同部署之间是共享一套代码的,不同之处是配置。代码是存储到代码仓库中的,那自然配置不应该是存到代码仓库中。每次部署都有自己独立的部署环境,每次部署所对应的配置要存到这次部署所对应的部署环境中去,因此配置的另一个同义词就是环境变量。这里的部署,不包括应用内部的配置,例如Java的Properties文件或者是Servlet的映射配置文件web.xml等,这些算作是代码而不是配置。这是一个容易令人混淆的地方,那到底什么算代码,什么算配置?判断的标准很简单,就是变化的频率。变动导致产品版本更新的,就是代码;每次部署都可能变更,而每次变动不导致产品版本更新的,就是配置,就是环境变量。

    4. 将后端支撑服务作为挂载资源来使用

    这一理念强调应用使用后台支撑服务的方式。不同的服务之间的区别就只是资源的URL不同,也就是设定这个资源的相关环境变量不同。不管是本地资源还是远程资源,应用程序都可以正常使用,区别只是环境变量的值不同,而应用本身并不会因为环境变量不同而有所区别。最常用的后台支撑服务就是数据库、缓存、消息队列等服务。这一理念可以保证应用在任何环境都可以正常运行,不会因为后台支撑服务的变化而导致应用无法运行。

    5. 严格区分构建阶段和运行阶段

    这一理念跟区分应用和部署类似,本质上也是要严格区分应用的非运行时行为和运行时行为。构建是将应用的代码仓库编译打包成可运行的软件的过程,是非运行时行为。因此说,这一理念另一方面也说明要防止在运行阶段改代码的行为,这样才能够保证运行中应用的稳定性。

    6. 将应用作为无状态的进程来运行

    这一理念要求所有的用户数据都要通过后端支撑服务来存储,而应用本身是无状态的,因为只有这样,应用才能做到水平伸缩,从而利用云平台弹性伸缩的能力。

    7. 仅需要绑定一个端口就可以对外发布一个服务

    这一理念强调应用本身对于发布服务的环境不应该有过多的要求,而应该是完全自包含的,也就是说不需要依赖云平台提供应用运行容器,而只需要云平台分配某个端口对外发布服务。这一理念保证应用可以使用云平台中任意分配的端口发布服务。

    8. 可以像UNIX进程一样水平扩展

    在UNIX操作系统上,不同的进程彼此独立地运行着,共享这整个操作系统管理的计算机资源。云原生应用在云平台上的运行模式也是类似的,云平台就是分布式操作系统,不同的云原生应用彼此独立互补干扰的运行在一个云平台上,可以充分利用云平台的整体计算能力。

    9. 可以快速启动和优雅地关闭

    快速启动是为了能充分利用云平台根据需要调度资源的能力,能够在需要的时候,以最小的延时扩展计算能力提供服务。优雅地关闭,一方面是为了释放资源,将不再使用的计算资源归还云平台;另一方面也是为了保证应用逻辑的完整性,将该完成的任务正确完成,未能完成的任务重新交回到系统由其它应用的运行实例来继续完成。要假设云原生应用的目标工作环境中随时有大量同样的应用实例在运行、启动和关闭,因此快速启动和优雅关闭对高性能和稳定的系统非常重要。

    10. 保持开发环境、预发布环境和生产环境尽量一致

    保持环境一致,是为了提高开发单元测试、功能测试和集成测试的有效性,避免出现开发测试中正常而在生产环境中出现问题的情况。

    11. 将日志作为事件流来处理

    云原生应用运行在复杂的分布式基础设施之上,如果日志不通过简单统一的模式来管理,将给系统排错或通过日志挖掘信息带来很大困难。同时,如果应用将日志输出到系统的文件中,也会给系统的存储空间造成压力,增加系统运维的复杂性。因此这一理念推荐应用将日志输出到标准输出,然后由云平台统一收集处理。

    12. 将应用管理任务当作一次性进程来运行

    将应用的管理任务与应用的业务请求以相似的方式运行,以同样的方式进行调度、日志和监控,将有利于系统的稳定性和分析系统的整体行为。

    四、云原生应用的挑战

    1. 处理分布式系统的网络通信问题

    云原生应用必须要针对分布式系统中网络通信的复杂性进行设计。对于分布式系统,如果还像单一进程应用那样考虑问题,就会进入所谓的“分布式系统的认识误区”,包括武断地认为:网络是可靠的;网络的延时为零;网络带宽是无限大的;网络是安全的;网络拓扑是不变的;系统中只有一个管理员和网络环境都是统一一致的。也许现在很少会有人幼稚到真的认为分布式环境中的交互处理和运行在单一进程中的函数调用是一样的;但开发的复杂度、功能上线的压力,经常会使开发人员把这些复杂问题暂时放在一边,不断积累起越来越多的“技术负债”。

    2. 处理分布式系统的状态一致性问题

    分布式系统的CAP理论认为,在分布式系统中,系统的一致性、可用性和分区容忍性,三者不可能同时兼顾。当然,实际在分布式系统中,由于网络通信固有的不稳定,分区容忍性是必须要存在的,因此在设计应用的时候,就要在一致性和可用性之间权衡选择。

    3. 最终一致性

    很多情况下,在一致性和可用性之间,云原生应用比传统应用更加偏向可用性,而采用最终一致性代替传统用事务交易保证的ACID一致性。传统的ACID一致性编程模型与业务无关,开发人员对它经验丰富,而最终一致性的交互模式与业务相关,必须通过业务的合理性来校验阶段不一致的合理性,这使得最终一致性比ACID一致性复杂得多。

    4. 服务发现和负载均衡

    云原生应用的运行实例随时可能关闭和启动,因此需要机制使得访问应用服务的客户端随时都能找到健康运行的实例,放弃对宕机实例的访问,这就是服务发现的问题。与服务发现同时存在的,是在多个健康实例中选择一个实例真正为某个客户请求提供服务的过程,这就是负载均衡。

    5. 任务分解和数据分片

    大的任务要分解成很多小任务,分配到各个运行实例上去执行,然后再将执行结果汇总,这就是任务分解。数据分布到各个实例上做处理和存储,这个就是数据分片。这些都需要适应云计算环境的机制去支持。

    6. 主控角色选举

    不管是任务分解还是数据分片,每个应用实例上负责的子任务和数据分片虽然是不同的,但如何分解、谁负责谁这种分配映射表一定是完全相同的;因此在这种情况下,需要负责计算分配映射表的主控角色;而因为云计算环境下没有实例是永远保证健康运行的,主控角色不可能是永远固定的;这就需要主控角色选举的机制,能够在主控角色空白或出现故障宕机的情况下,自选举出新的主控角色。

    像设计模式解决面向对象设计中的复杂问题一样,面对云原生应用的复杂应用场景,我们也需要一些典型的设计模式能够可重用地解决一些特定场景的问题。

    展开全文
  • 上一篇文章中我们介绍过CNCF 给出的云原生定义中包括微服务、容器、服务网格、不可变基础设施和声明式 API 等代表技术,构建云原生应用就主要靠这些关键技术。下面我们就来具体介绍下这 5 个关键技术。 1. 微服务 ...
  • 阿里云原生技术+云原生架构+云原生实践等资料合集,13份。 2021阿里巴巴DevOps实践手册 2021云原生开发者洞察白皮书 ...Knative 云原生应用开发指南 Serverless入门与实战 Spring Cloud Alibabab 从入门到实战
  • Kyma一种在云原生世界中连接和扩展企业应用程序的灵活而简便的方法
  • Rainbond 是云原生且易用的云原生应用管理平台,云原生应用交付的最佳实践,简单易用。专注于以应用为中心的理念。赋能企业搭建云原生开发云、云原生交付云。 对于企业: Rainbond 是开箱即用的云原生平台,借助 ...
  • 构建微服务云原生应用——服务开发框架设计和实践.pdf
  • 云原生与云原生应用概念解析

    千次阅读 2018-09-25 17:10:35
    在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生。 云原生是面向“云”而设计的应用,因此技术部分依赖于在传统云计算的3层概念(基础设施即服务...
  • 摘要:在近日于上海召开的第六届Gopher China大会上,华为云微服务首席架构师田晓亮分享了《华为云的Go语言云原生实战经验》,讲述如何构建韧性、高可靠、安全的云原生应用系统,并孵化云原生应用开发框架Go chassis...
  • 8.1.1 云原生简介;8.1.1 云原生简介;8.1.2 云原生的内容;图8.1 云原生的内容;8.1.2 云原生的内容;8.1.2 云原生的内容;图8.2 持续交付流程示例;8.1.2 云原生的内容;图8.3 DevOps强调组织的沟通与协作;8.1.2 云原生的...
  • 云原生应用程序是基于云计算基础设施设计的,云计算本身的应用程序开发并不是围绕内部服务器、数据库、连接等建立,而是依赖抽象出硬件和维护的服务,在某些情况下还包括操作系统本身,因此开发人员可以专注于真正...
  • 构建云原生应用程序

    千人学习 2016-08-08 09:16:39
    pivotal云原生活动将与您一起遍览云原生软件的源起 、发展以及交付方法。我们将与您分享云原生软件组织的能力和预期成果,内容涵盖基础设施自动化、容器编排和生命周期管理及应用程序框架。
  • 云原生应用概念解析

    2020-03-26 00:35:07
    在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生。 云原生是面向“云”而设计的应用,因此技术部分依赖于在传统云计算的3层概念(基础设施即...
  • VMware的云原生应用技术揭秘

    千人学习 2016-07-25 13:44:52
    本次分享将主要介绍VMware全面开放的云原生应用平台,在演讲中将分别从开发栈、生产栈和DevOps等方面做具体的介绍,揭密相关的技术细节,包括Harbor企业级容器镜像Registry、企业级容器运行平台vSphere Integrated ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 59,421
精华内容 23,768
关键字:

云原生应用开发