精华内容
下载资源
问答
  • 云原生模式书籍介绍:https://item.jd.com/12704245.html 记录一些书中的总结 第一部分云原生上下文 1.什么是云原生 (1)即使遇到基础设施不断变化甚至发生故障的情况,云原生应用程序依然可以保持稳定。 (2)现代应用...

    云原生模式书籍介绍:https://item.jd.com/12704245.html
    记录一些书中的总结

    第一部分云原生上下文

    1.什么是云原生

    (1)即使遇到基础设施不断变化甚至发生故障的情况,云原生应用程序依然可以保持稳定。
    (2)现代应用程序的关键要求是支持快速迭代和频繁发布新版本、零停机时间以及大量新的设备连接。
    (3)云原生应用程序的模型有三个关键实体:

    • 云原生应用程序
    • 云原生数据
    • 云原生交互
      (4) “云”是指软件在哪里运行,而“云原生”指的是软件如何运行。
      (5) 云原生并不是非此即彼的架构。一些软件可以采用许多新的云原生架构模式,一些软件可以仍然继续使用较老的架构,还有一些软件可以采用混合架构(新旧架构结合)。

    2.在生产环境中运用云原生应用程序

    (1)为了让编写的代码实现价值,你需要做到两件事:能够简单且频繁地发布,让它在生产环境中良好地运行。
    (2) 如果这两个目标其中之一没有实现,不应该归咎于开发人员或者运维人员。一个失败的系统才是“罪魁祸首”。
    (3) 系统之所以失败,是因为采用了定制化从而难以维护的解决方案,它的环境给软件部署本身带来了风险,同时它将软件和环境中的变化视为一种例外情况。
    (4)当部署存在风险时,部署频率就会降低,但这只会让部署有更大的风险。
    (5) 你可以反过来看面对的这些问题,即关注可重复性、确保部署的安全性、拥抱变化,并创建一个支持部署而非阻碍部署的系统。
    (6) 可重复性是优化IT运维的核心,自动化不仅适用于软件的构建过程,还适用于运行时环境的创建和应用程序的部署过程。
    (7) 在基于云的环境中,软件设计模式和运维实践都会不断发生变化。
    (8)新系统依赖于一个支持持续交付、高度迭代的软件开发生命周期。
    (9)企业需要具备持续交付的能力,才能在当今的市场竞争中获胜。
    (10) 让整个系统具有更细的粒度是关键。更短的开发周期和规模更小的应用程序组件(微服务)可以显著提高开发的敏捷性和系统的弹性。
    (11)在一个一定会变化的系统中,实现最终一致性是最重要的。

    3.云原生软件平台

    (1) 云原生平台满足了现代软件的大量需求。
    (2)云原生平台可以用在整个软件开发生命周期中。
    (3) 与过去十年中以基础设施为中心的平台相比,云原生平台的抽象层次更高。
    (4)通过在平台中加入控制功能,不需要再对每个应用程序的每次部署都进行审批,进而可以大大提高部署的频率,而且更加安全。
    (5)应用程序团队和平台团队可以独立工作,各自管理产品的构建、部署和维护。
    (6)最终一致性是平台的核心,需要不断监控系统的实际状态,并与期望状态进行比较,并且在必要时进行调整。这既适用于在平台上运行的软件,也适用于平台本身的部署。
    (7) 随着软件变得更加模块化和分布式,还需要将组件组合成一个整体的服务。平台必须支持这些分布式系统。
    (8)对于构建和运维云原生软件的企业来说,云原生平台是绝对必要的。

    第二部分云原生模式

    4.事件驱动微服务:不只是请求/响应

    (1)请求/响应和事件驱动的方法,都可以用来连接组成云原生软件的各个组件。
    (2)一个微服务可以同时实现请求/响应和事件处理两种协议。
    (3) 在理想、稳定的环境下,其中一种方法的实现,可以产生与使用另一种方法实现完全相同的结果。
    (4) 但是在云环境中,解决方案是一个分布式系统,环境在不断变化,结果可能会有很大的不同。
    (5) 除了请求/响应和事件驱动风格以外,其他一些架构模式也同样适用于云原生软件。
    (6)但是其他模式会专门服务于其中某一种调用协议。
    (7)CQRS在事件驱动的系统中起着重要的作用。

    5.应用程序冗余:水平伸缩和无状态

    (1) 有状态的应用程序无法在云原生环境中很好地工作。
    (2) 与用户的一系列交互(逻辑上是在会话状态中捕获的)是在应用程序中引入状态的常见方式。
    (3)有状态服务是一种特殊类型的服务,它不得不面对分布式、云环境中数据弹性的重要问题。
    (4)大多数应用程序应该是无状态的,并且应该将状态的处理工作交给那些有状态的服务。
    (5) 使应用程序无状态很简单,并且一旦完成,就可以在云环境中具有显著的优势。

    6.应用程序配置:不只是环境变量

    (1)云原生软件架构需要重新评估配置应用程序的技术。一些现有的方法仍然存在,一些新的方法也是有用的。
    (2)云原生应用程序的配置并不像在环境变量中存储配置那么简单。
    (3) 属性文件仍然是正确处理软件配置的重要部分。
    (4)使用环境变量进行配置非常适合于系统配置数据。
    (5) 可以使用Kubernetes等云原生平台,将环境配置的值传递给应用程序。(6)应该像对待源代码一样对待应用程序的配置:在源代码仓库中管理配置、进行版本控制和访问控制。
    (7)配置服务器(例如,Spring Cloud Configuration Server)可以用来注入应用程序的配置值。
    (8)你现在必须考虑何时应用配置,它与云原生应用程序的生命周期息息相关。

    展开全文
  • 第二部分云原生模式 7.应用程序生命周期:考虑不断的变化 (1)在云原生环境中,必须考虑应用程序的生命周期,并将它看作单独的逻辑实体,即使每个应用程序实例都有自己独立的生命周期。 (2)还必须仔细关注某个应用...

    云原生模式书籍介绍:https://item.jd.com/12704245.html
    记录一些书中的总结

    第二部分云原生模式

    7.应用程序生命周期:考虑不断的变化

    (1)在云原生环境中,必须考虑应用程序的生命周期,并将它看作单独的逻辑实体,即使每个应用程序实例都有自己独立的生命周期。
    (2)还必须仔细关注某个应用程序的生命周期事件,看其会如何影响软件中其他的应用程序。
    (3)只有当一个应用程序的多个实例可以同时支持不同的配置时,才能使用滚动升级的部署方式。否则,必须使用蓝/绿升级的部署方式。两者都可以在零停机时间内完成。
    (4)一个精心设计的密码轮换模式,可以通过滚动升级的方式来实现。
    (5)如果人为替换应用程序的实例也可以实现这种模式,那么也可以这样做。让我们放下这种偏见。
    (6)应用程序日志应该被发送到stdout和stderr,大多数云原生平台都会在那里处理它们。
    (7)应用程序的状态必须是可用的,这样才能持续检查系统的健康情况,并且所依赖的应用程序才能够适应变化。
    (8)无服务器计算是云原生的一种极端形式,它使用了本书中介绍的大多数模式。

    8 如何访问应用程序:服务、路由和服务发现

    (1)可以用一个简单的抽象将客户端和依赖服务之间松耦合。
    (2)有两种主要的负载均衡方法—集中式(或者服务端)和客户端。每种方法都有各自的优点和缺点。
    (3)负载均衡器的配置必须是动态且高度自动化的,因为在云原生环境中,流量被路由到的实例比过去变化的频率大得多。
    (4)诸如DNS之类的名称服务是服务发现协议的核心,该协议允许客户端在不断变化的网络拓扑中找到相关服务。
    (5)在使用域名服务时,作为一名开发人员,你必须考虑到名称到IP地址的映射表是最终一致的,你必须考虑到映射记录可能已经过期的情况。
    (6)使用一种服务发现协议可以让软件部署变得更有弹性

    9 交互冗余:重试和其他控制循环

    请求重试的基本模式很简单:应用程序向远程服务发出请求,如果在合理的时间内没有接收到响应,将再次尝试

    (1)重试一个超时请求可以降低本来会通过系统传播的错误。
    (2)如果处理不当,即使修复了连接性的问题,排队中的重试请求也会使系统过载。
    (3)正确配置的重试既可以显著降低重试风暴的风险,又可以在不太严重的停机事故中提供巨大的好处。
    (4)只有在安全的情况下才使用重试,是一名开发人员应该承担的责任。
    (5)你不仅应该养成实现服务的核心逻辑的习惯,还应该养成在意外情况下实现回退逻辑的习惯。
    (6)重试只是一种控制循环模式的例子。
    (7)对于组成云原生软件的分布式系统,控制循环是一项必不可少的技术。

    10 前沿服务:断路器和API网关

    断路器
    在软件中,断路器的运行方式基本相同。当负载过高时,断路器会打开并阻止流量通过。但是它有两个不同之处。首先,用来检测何时应打开断路器的机制是基于实际的故障,而不是对可能的故障的预测(你肯定不希望电路在检测到小火苗后才会跳闸)。其次,软件中的断路器通常具有内置的自我修复机制(这与让人类在黑暗的房屋中找到配电板,并手动翻转断路器的方式不同)。
    api网关
    开源和商业API网关比微服务和基于云的架构兴起得还要早。例如,Apigee(自被Google收购)和Mashery(被Intel收购,然后出售给TIBCO)都是在20世纪00年代初期成立的公司,都专注于开发API网关。API网关在软件架构中扮演的角色始终如本章标题所述,始终位于实现的最前面,并且提供了大量的服务
    服务网格
    我们不必一步就实现服务网格(Service Mesh),所以让我一点一点地来介绍,从一个在服务网格中起核心作用的原语开始。然后,我将继续介绍服务网格及其在云原生软件架构中扮演的日益重要的角色。

    (1)在服务的前端设计了许多模式,用来控制与该服务的交互方式。
    (2)断路器是用来防止服务过载(包括重试风暴所产生的流量)的基本模式。
    (3)API网关早于云原生架构出现,如今已经发展得可以很好地适应高度分布式化、不断变化的软件部署环境。
    (4)应用于交互的客户端和服务端的模式,都可以封装并作为一个挎斗代理被部署。
    (5)服务网格为挎斗代理添加了一个管理平面,该管理平面允许运维人员控制安全性,提供可观察性,并允许配置组成云原生软件的服务/应用程序的集合。

    11 故障排除:如同大海捞针

    (1)必须主动将度量指标和日志从执行服务的运行时环境中取出,因为在服务遇到故障或者升级后,这些执行环境通常会变得不可用。服务的执行环境应被视为短暂的。
    (2)聚合来自多个服务实例的日志对于可观察性很重要。通常首选按时间顺序来处理不同服务的日志。
    (3)可观察性信息、日志、指标和跟踪数据的收集可以放在挎斗代理中实现,这使得应用程序可以专注于业务逻辑,并将运维需求集中到服务网格中。
    (4)完善的分布式跟踪技术及其实现,为深入了解分布式应用程序的运行状况和性能提供了宝贵的洞察能力。
    (5)本书前面介绍的许多模式都可以用来提供所需的可观察性。应用程序配置、应用程序生命周期、服务发现、网关和服务网格都有各自的作用。

    12 云原生数据:打破数据单体

    (1)当为微服务提供一个数据库来存储其所需的数据时,能显著提高自治性。这会让系统整体具有更好的弹性。
    (2)尽管在许多情况下有缓存总比没有好,但是使用缓存来填充本地数据库充满了挑战。缓存不适合用于数据频繁变更的场景。
    (3)通过事件主动将数据变更推送到本地的数据存储,是一种更好的方法。
    (4)尽管我们生产和消费的实体是事件而不是消息,但是该技术的基础仍然是我们熟悉的发布/订阅模式。
    (5)将事件日志作为数据的唯一真实来源,所有服务的本地数据库仅保留投射数据,这样可以让运行在高度分布式、不断变化的环境中的云原生软件,实现数据上的一致性。

    展开全文
  • 在6月4日我们邀请了CODING团队的余朋飞老师来到腾讯云大学作”云计算、云原生模式下的DevOps建设“的精彩分享,让我们一起来回顾一下。 首先会和大家分享我们当前对于整个应用生命周期的演变历程,然后讲解云计算...

    点击观看大咖分享

    在6月4日我们邀请了CODING团队的余朋飞老师来到腾讯云大学作”云计算、云原生模式下的DevOps建设“的精彩分享,让我们一起来回顾一下。

    首先会和大家分享我们当前对于整个应用生命周期的演变历程,然后讲解云计算模式下DevOps建设包含的过程、流程规范和标准,最后讲解云原生时代的到来会带来哪些改变,以及标准化的建设会有那些改变和突破。

    应用的演变历程

    企业数字化转型过程和云的迭代发展是相互作用的。在2007年之前主要用物理机来作为我们当前应用的载体。而在2007年,KVM诞生,它能让底层操作系统和一些虚拟的网络设备做一些虚拟化的输出。2007年-2010年是虚拟化发展较好的周期,VMware和openstack是当时的代表生态。到了2013年Docker开服,云计算迎来了蓬勃发展的周期。2014年,企业的部分业务开始逐步迁移云上。2017年后到今天为止,在云原生的模式下,开发人员或者整个it部门更聚焦在业务的发展上,所有我们不关心的部分可以全部由云来管理。云开发不必关系开发在哪里,云服务不关心调用到哪里,而云资源方面也不用关心运行到了哪里。这就是从基础设施上云到业务上云,再到当前的全栈云,这样的一条全企业数字化转型之路。

    在物理机阶段,使用的是单体架构,这样的架构系统封闭、无法复用,且高度耦合,内部交互复杂。而在第二阶段,采用了面向服务的SOA架构,这种架构通常需要ESB进行系统集成,进行应用模块解耦,需要统一部署。但是这种架构通常需要较大规模的团队,且可能存在职责割裂。第三阶段是当前使用得比较多的微服务架构,它能充分利用DevOps,完全解耦能充分利用云化资源自动弹性伸缩等特性,支持高可用,能升级、扩容但不中断业务。

    这张图片能较好的展示应用的生命周期管理,以应用为中心,在应用之上是基础资源管理层面,这个层面可以管理应用对应的资产、环境、资源、流水线、部署和监控,这是以基础资源为核心思想下DevOps的建设方向。随着越来越云化和微服务化,我们关注的视角从基础资源逐步转成服务思想。

     

    云计算模式下的DevOps

    在物理机时代,随着业务的发展,可能会出现基础设施增长,软件复杂度提升,流量冲击和更新频率变高这些问题。基础设施增长和软件复杂程度提升会给运维带来压力,流量冲击要求运维的测试要有多样的变化,更高的更新频率要求研发人员的快速反馈以及更灵活的需求变更。

    在这样的情况下,DevOps建设迫在眉睫,企业需要提升应用交付的效率和质量,需要越来越多样化的应用部署方式。DevOps建设要首先要做的是敏捷的建设,因此需要更灵活的需求管理工具,在整个应用交付阶段需要自动化构建和环境快速管理。然后在测试的阶段,我们需要做自动化测试,才能在流程中管控好质量,另外还需要有一个统一的制品管理。从软件开发到应用交付之间,需要有一套统一的制品库将所有的制品进行统一纳管,基于统一的制品可以进行智能化的验收测试。在这整个阶段,核心准则是版本控制一切,内建质量、自动化,过程度量。

    这个图片是端到端的DevOps能力图谱,建设的重点在图谱下方的持续交付工具链。我们需要采取统一的代码管理工具,帮助我们自动化的提升代码的质量。在安全方面,我们也会运用安全扫描工具集成到流程中,让它进行自动编译。另外,在持续部署阶段,要做好数据库的发布,对不同版本的接口做好管理,并结合一些好的自动化的工具做自动化测试。这些功能点需要一个交付部署流水线串连起来。

    我们可以看到,在端到端的能力中会有很多步骤,也需要非常多的工具去执行,如何将这些工具进行很好的串连呢?在企业生产过程中,核心目标有三项:效率、质量和成本,因此可以沿用制造业的流水线来帮助我们快速的生产软件。流水线中我们需要关注4项指标:发布频率、变更时长、服务恢复时长和变更失败率。

     

    云原生带来的改变

    云原生是一个复杂的东西,它包含开发过程、应用依赖、编排管理、流程管理、数据分析以及非常多的组件。在云计算的模式下,我们可以做到快速交付应用、成果快速发布,但是我们交付的产品是否能给业务带来增长,满足客户的需要呢?这就涉及到如何将应用交付转变为价值交付。通过可靠、可重复的流水线,快速进行软件生产,提升应用效率和软件交付效率,这就是应用交付。而价值交付是指能够快速地响应市场变化,在客户需求不确定的情况下,生产出客户满意的软件。

    如何实现价值交付?要基于可靠可重复的流水线,简历自动化的应用交付体系。将敏捷过程全面融入到DevOps体系中。架构全面微服务转型,基础设施云化,让开发专注于业务开发。将运营纳入到DevOps范畴,实现数字化运营。


    问卷

    为了给广大开发者提供最实用、最热门前沿、最干货的视频教程,请让我们听到你的需要,感谢您的时间!点击填写 问卷

     

    腾讯云大学是腾讯云旗下面向云生态用户的一站式学习成长平台。腾讯云大学大咖分享每周邀请内部技术大咖,为你提供免费、专业、行业最新技术动态分享。

     

    展开全文
  • 本文首先会和大家分享当前整个应用生命周期的演变历程,然后讲解云计算模式下 DevOps 建设包含的过程、流程规范和标准,最后讲解云原生时代到来会带来哪些改变,以及标准化的建设会有哪些改变和突破。 应用的演变...

    本文首先会和大家分享当前整个应用生命周期的演变历程,然后讲解云计算模式下 DevOps 建设包含的过程、流程规范和标准,最后讲解云原生时代到来会带来哪些改变,以及标准化的建设会有哪些改变和突破。

    应用的演变历程

    企业数字化转型过程和云的迭代发展是相互作用的。在 2007 年之前主要用物理机来作为我们当前应用的载体。而在 2007 年,KVM 诞生,它能让底层操作系统和一些虚拟的网络设备做一些虚拟化的输出。2007 年 - 2010 年是虚拟化发展较好的周期,VMware 和 openstack 是当时的代表生态。到了 2013 年 Docker 开服,云计算迎来了蓬勃发展的周期。2014 年,企业的部分业务开始逐步迁移云上。2017 年后到今天为止,在云原生的模式下,开发人员或者整个 it 部门更聚焦在业务的发展上,所有我们不关心的部分可以全部由云来管理。云开发不必关心开发在哪里,云服务不关心调用到哪里,而云资源方面也不用关心运行到了哪里。这就是从基础设施上云到业务上云,再到当前的全栈云,这样的一条全企业数字化转型之路。

    在物理机阶段,使用的是单体架构,这样的架构系统封闭、无法复用,且高度耦合,内部交互复杂。而在第二阶段,采用了面向服务的 SOA 架构,这种架构通常需要 ESB 进行系统集成,进行应用模块解耦,需要统一部署。但是这种架构通常需要较大规模的团队,且可能存在职责割裂。第三阶段是当前使用的比较多的微服务架构,它能充分利用 DevOps,完全解耦能充分利用云化资源自动弹性伸缩等特性,支持高可用,能升级、扩容但不中断业务。

    这张图片能较好的展示应用的生命周期管理,以应用为中心,在应用之上是基础资源管理层面,这个层面可以管理应用对应的资产、环境、资源、流水线、部署和监控,这是以基础资源为核心思想下 DevOps 的建设方向。随着越来越云化和微服务化,我们关注的视角从基础资源逐步转成服务思想。

    在这里插入图片描述

    云计算模式下的 DevOps

    在物理机时代,随着业务的发展,可能会出现基础设施增长,软件复杂度提升,流量冲击和更新频率变高这些问题。基础设施增长和软件复杂程度提升会给运维带来压力,流量冲击要求运维的测试要有多样的变化,更高的更新频率要求研发人员的快速反馈以及更灵活的需求变更。

    在这样的情况下,DevOps 建设迫在眉睫,企业需要提升应用交付的效率和质量,需要越来越多样化的应用部署方式。DevOps 建设要首先要做的是敏捷的建设,因此需要更灵活的需求管理工具,在整个应用交付阶段需要自动化构建和环境快速管理。然后在测试的阶段,我们需要做自动化测试,才能在流程中管控好质量,另外还需要有一个统一的制品管理。从软件开发到应用交付之间,需要有一套统一的制品库将所有的制品进行统一纳管,基于统一的制品可以进行智能化的验收测试。在这整个阶段,核心准则是版本控制一切,内建质量、自动化,过程度量。

    这个图片是端到端的 DevOps 能力图谱,建设的重点在图谱下方的持续交付工具链。我们需要采取统一的代码管理工具,帮助我们自动化的提升代码的质量。在安全方面,我们也会运用安全扫描工具集成到流程中,让它进行自动编译。另外,在持续部署阶段,要做好数据库的发布,对不同版本的接口做好管理,并结合一些好的自动化的工具做自动化测试。这些功能点需要一个交付部署流水线串连起来。

    在这里插入图片描述

    我们可以看到,在端到端的能力中会有很多步骤,也需要非常多的工具去执行,如何将这些工具进行很好的串连呢?在企业生产过程中,核心目标有三项:效率、质量和成本,因此可以沿用制造业的流水线来帮助我们快速的生产软件。流水线中我们需要关注 4 项指标:发布频率、变更时长、服务恢复时长和变更失败率。

    在这里插入图片描述

    云原生带来的改变

    云原生是一个复杂的东西,它包含开发过程、应用依赖、编排管理、流程管理、数据分析以及非常多的组件。在云计算的模式下,我们可以做到快速交付应用、成果快速发布,但是我们交付的产品是否能给业务带来增长,满足客户的需要呢?这就涉及到如何将应用交付转变为价值交付。通过可靠、可重复的流水线,快速进行软件生产,提升应用效率和软件交付效率,这就是应用交付。而价值交付是指能够快速地响应市场变化,在客户需求不确定的情况下,生产出客户满意的软件。

    如何实现价值交付?要基于可靠可重复的流水线,简历自动化的应用交付体系。将敏捷过程全面融入到 DevOps 体系中。架构全面微服务转型,基础设施云化,让开发专注于业务开发。将运营纳入到 DevOps 范畴,实现数字化运营。

    在这里插入图片描述
    点击观看课程完整视频。

    展开全文
  • 云原生架构模式 常见模式列举 服务化架构模式 服务化架构是云时代构建云原生应用的标准架构模式,要求以应用模块为颗粒度划分一个软件,以接口契约(例如 IDL)定义彼此业务关系,以标准协议(HTTP、gRPC 等)确保...
  • 云原生 设计模式 1.简介 (1. Introduction) With the growing number of new technologies coming into the market every year it becomes very difficult for engineers and their leadership to choose the right ...
  • 云原生

    2021-01-29 00:20:56
    云原生云原生简介 Ref. doc 云原生讲解 云原生参考文章1 CNCF官方定义 云原生landscape 云原生简介 CNCF,即Cloud Native Computing Foundation - 云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百...
  • 为什么说云原生重构了互联网产品开发模式云原生的概念云计算的前世今生阶段1:虚拟化技术阶段2:虚拟机的市场化应用阶段3:容器化和容器编排的兴起云原生到底是什么?云原生出现的背景云原生解决了哪些问题?不断...
  • 在云的时代,应用会更多的迁移到云端,基于云的架构设计和开发模式需要一套全新的理念去承载,于是云原生思想应运而生。 云原生是面向“云”而设计的应用,因此技术部分依赖于在传统云计算的3层概念(基础设施即服务...
  • “工具本身毫无价值,其价值...基于我对5G技术、IPv6了解,对终端模式的未来进行遐想,构建出一种云原生的终端模式,它将解决现如今终端模式的不足,对数据的私密化与便捷化问题提供一种解决方案。 当前终端设备的.
  • 云原生架构白皮书》中对于云原生架构的定义为“基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、...
  • 希望通过自己对于云原生的理解为开发者提供一篇观后感或者是能够参考的博文1 云原生与分布式系统架构的关系1.1 云原生架构的定义《云原生架构白皮书》中对于云原生架构的定义为“基于云原生技术的一组架构原则和设计...
  • 云原生这个大的时代背景下,企业又应如何落地相应研发模式来提高研发效率,提升企业竞争力呢。 容器是云原生变革的根本,其他的东西都是基于这个基础所引申和集成起来的。 云原生时代的软件研发要求:快、稳和省。 ...
  • 云原生架构概述

    2021-01-27 12:17:15
    在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。目前CNCF所托管的应用已达14个,...云原生包含了一组应用的模式
  • 开发云原生应用 从介绍全渠道集成以及与SaaS应用程序 集成的体系结构蓝图开始之后,我们将介绍云原生开发蓝图的结果。 什么是建筑蓝图,您要关注的重点是什么? 这是一个有趣的挑战,因为我们一直在基于常见的...
  • Kubernetes与云原生应用 过去两年,容器和容器镜像已经成为了开发云原生应用所必不可少的技术。Kubernetes平台的设计开发者以及Kubernetes社区的技术人员,在不断推进Kubernetes作为容器管理平台的快速发展的同时...
  • RIO(大众汽车公司的一个品牌)首席架构师Christian Deger最近在伦敦Continuous Lifecycle大会上分享了一系列实现云原生持续交付的模式和实践。Deger的演讲内容涵盖了用于独立部署管道的模式(得益于容器化)、拥有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 885
精华内容 354
关键字:

云原生模式