精华内容
下载资源
问答
  • 原生架构的 5 条原则——它是什么以及如何掌握它
    千次阅读
    2022-03-24 18:23:44

    在 Google Cloud,我们经常将“云原生架构”这个术语作为您在Google Cloud Platform (GCP) 上迁移或构建的应用程序的理想最终目标。但是,我们所说的云原生到底是什么意思?更重要的是,您如何设计这样的系统?

    在高层次上,云原生架构意味着适应云提供的许多新可能性——但架构约束集非常不同——与传统的本地基础设施相比。考虑一下我们作为软件架构师受过培训要考虑的高级元素:

    • 系统的功能要求(它应该做什么,例如’以这种格式处理订单…’)
    • 非功能性需求(它应该如何执行,例如“每分钟处理至少 200 个订单”)
    • 约束(超出范围的更改,例如“必须在我们现有的大型机系统上更新订单”)。

    虽然功能方面没有太大变化,但云提供了,有时需要非常不同的方式来满足非功能性需求,并施加了非常不同的架构约束。如果架构师未能使他们的方法适应这些不同的约束条件,他们所构建的系统通常会变得脆弱、昂贵且难以维护。另一方面,架构良好的云原生系统应该在很大程度上是自我修复的、具有成本效益的,并且可以通过持续集成/持续交付 (CI/CD) 轻松更新和维护。

    好消息是,云是由构成传统基础设施的相同结构的服务器、磁盘和网络组成的。这意味着几乎所有优秀架构设计的原则仍然适用于云原生架构。但是,当您在云中时,有关该结构如何执行的一些基本假设会发生变化。例如,在传统环境中配置替换服务器可能需要数周时间,而在云中则需要几秒钟——您的应用程序架构需要考虑到这一点。

    在这篇文章中,我们列出了云原生架构的五项原则,这将有助于确保您的设计充分利用云,同时避免将旧方法套入新平台的陷阱。

    云原生架构的原则

    云架构的原则,又称云原生架构,侧重于如何针对云的独特功能优化系统架构。传统架构倾向于针对固定的、高成本的基础架构进行优化,这需要大量的人工修改。因此,传统架构侧重于相对较少的固定数量的组件的弹性和性能。然而,在云中,这样一个固定的基础设施意义不大,因为云是根据使用量收费的(所以当你可以减少你的足迹时你可以省钱)而且它也更容易自动化(所以自动扩展和缩减更容易)。因此,云原生架构侧重于通过水平扩展、分布式处理、并自动更换故障组件。让我们来看看。

    原则 1:自动化设计

    自动化一直是软件系统的最佳实践,但云使基础架构以及位于其之上的组件的自动化比以往任何时候都更加容易。尽管前期投资通常更高,但从中期来看,偏爱自动化解决方案几乎总能在工作量以及系统的弹性和性能方面获得回报。自动化流程可以比人们更快地修复、扩展和部署您的系统。正如我们稍后讨论的那样,云中的架构不是一次性的交易,自动化也不例外——因为您会找到系统需要采取行动的新方法,因此您会发现新的东西需要自动化。
    自动化云原生系统的一些常见领域是:

    • 基础架构:使用Google Cloud Deployment ManagerTerraform等工具自动创建基础架构及其更新
    • 持续集成/持续交付:使用Google Cloud BuildJenkinsSpinnaker等工具自动构建、测试和部署构成系统的包。您不仅应该自动化部署,还应该努力实现金丝雀测试和回滚等流程的自动化。
    • 放大和缩小:除非您的系统负载几乎从不改变,否则您应该自动扩大系统以响应负载的增加,并缩小以响应负载的持续下降。通过扩大规模,您可以确保您的服务保持可用,通过缩小规模,您可以降低成本。这对于大型应用程序(如公共网站)以及负载不规则的小型应用程序(例如在某些时间段非常繁忙但在其他时间段几乎不使用的内部应用程序)来说显然是有意义的。对于有时几乎没有流量的应用程序,并且您可以容忍一些初始延迟,您甚至应该考虑将其缩放到零(删除所有正在运行的实例,并在下次需要时重新启动应用程序)。
    • 监控和自动恢复:您应该从一开始就将监控和登录到您的云原生系统。记录和监控数据流自然可以用于监控系统的健康状况,但除此之外还有很多用途。例如,他们可以对系统使用和用户行为(有多少人在使用系统,他们正在使用哪些部件,他们的平均延迟是多少等)提供有价值的见解。其次,它们可以综合使用来衡量整个系统的健康状况(例如,磁盘几乎再次满了,但它是否比平时更快地填充?磁盘使用和服务吸收之间的关系是什么?等等)。最后,它们是连接自动化的理想点.现在,当该磁盘填满时,您不仅可以记录错误,还可以自动调整磁盘大小以允许系统继续运行。

    原则 2:聪明地对待状态

    存储“状态”,是用户数据(例如,用户购物车中的商品,或他们的员工编号)或系统状态(例如,正在运行的作业实例数量,生产中运行的代码版本) ,是构建分布式云原生架构最困难的方面。因此,您应该在构建系统时有意识地考虑何时以及如何存储状态,并尽可能将组件设计为无状态
    无状态组件很容易:

    • 规模:要扩大规模,只需添加更多副本。要缩小规模,请指示实例在完成当前任务后终止。
    • 修复:要“修复”组件的失败实例,只需尽可能优雅地终止它并启动替换。
    • 回滚:如果部署不好,无状态组件更容易回滚,因为您可以终止它们并启动旧版本的实例。
    • 跨负载平衡:当组件是无状态的时,负载平衡要简单得多,因为任何实例都可以处理任何请求。有状态组件之间的负载平衡要困难得多,因为用户会话的状态通常驻留在实例上,迫使该实例处理来自给定用户的所有请求。

    原则 3:支持托管服务

    云不仅仅是基础设施。大多数云提供商都提供一组丰富的托管服务,提供各种功能,让您摆脱管理后端软件或基础设施的麻烦。但是,许多组织对利用这些服务持谨慎态度,因为他们担心被“锁定”给特定的提供商。这是一个值得关注的问题,但托管服务通常可以极大地节省组织的时间和运营开销。
    从广义上讲,是否采用托管服务的决定归结为可移植性与运营开销,无论是在资金方面,还是在技能方面。粗略地说,您今天可能考虑的托管服务分为三大类:

    托管开源或开源兼容服务:托管开源(例如 Cloud SQL)或提供开源兼容接口(例如 Cloud Bigtable)的服务。这应该是一个简单的选择,因为使用托管服务有很多好处,而且风险很小。
    可节省大量运营成本的托管服务:一些服务不能立即与开源兼容,或者没有直接的开源替代方案,但比替代方案更容易使用,因此值得冒险。例如,BigQuery经常被组织采用,因为它非常易于操作。
    其他一切:还有一些困难的情况,即没有简单的服务迁移路径,并且它提供了不太明显的运营优势。您需要逐个检查这些,考虑诸如服务的战略意义、自己运行它的运营开销以及迁移所需的工作量等。
    然而,实践经验表明,大多数云原生架构偏爱托管服务;必须迁移出它们的潜在风险很少超过让云提供商代表您大规模管理服务所节省的大量时间、精力和运营风险。

    在这里插入图片描述

    原则4:深度练习防守

    传统架构非常信任外围安全,粗略地说是一个强化的网络外围,里面有“受信任的东西”,外面有“不可信的东西”。不幸的是,这种方法一直很容易受到内部攻击,以及鱼叉式网络钓鱼等外部威胁。此外,提供灵活和移动工作的压力越来越大,进一步削弱了网络边界。
    云原生架构起源于面向互联网的服务,因此一直需要应对外部攻击。因此,他们通过在每个组件之间应用身份验证,并通过最小化这些组件之间的信任(即使它们是“内部的”)来采用深度防御方法。结果,没有 ‘inside’ 和 ‘outside’

    云原生架构应该将这个想法扩展到身份验证之外,包括速率限制和脚本注入等内容。设计中的每个组件都应设法保护自己免受其他组件的影响。这不仅使架构非常有弹性,而且还使生成的服务更容易部署在云环境中,在云环境中,服务与其用户之间可能没有受信任的网络。

    原则 5:始终是架构师

    云原生系统的核心特征之一是它始终在发展,架构同样如此。作为云原生架构师,随着组织需求的变化、IT 系统环境的变化以及云提供商自身能力的变化,您应该始终寻求改进、简化和改进系统架构。虽然这无疑需要不断的投资,但过去的教训是显而易见的:为了发展、成长和响应,IT 系统需要生存、呼吸和改变。死气沉沉、僵化的 IT 系统迅速使组织陷入停顿,无法应对新的威胁和机遇。

    唯一不变的就是变化

    在动物王国中,生存偏爱那些适应环境的个体。这不是从“坏”到“最好”或从“原始”到“进化”的线性旅程,而是一切都在不断变化。随着环境的变化,物种面临进化和适应的压力。同样,云原生架构并没有取代传统架构,而是更好地适应了非常不同的云环境。云越来越成为我们大多数人发现自己工作的环境,正如许多物种可以证明的那样,未能进化和适应并不是一个长期的选择。
    上述原则并不是创建云原生架构的神奇公式,但希望为如何充分利用云提供强有力的指导。作为一个额外的好处,移动和调整云架构让您有机会以其他方式改进和调整它们,并使它们能够更好地适应下一次环境转变。改变可能很难,但正如数十亿年的进化所表明的那样,你不必成为最好的生存者——你只需要能够适应。

    如果您想了解有关本文中主题的更多信息,请查看以下资源:

    要详细了解 Google 如何在生产环境中运行系统,请查看站点可靠性工程页面上的资源
    详细了解容器以及持续集成和持续部署,它们是在云上构建的核心技术
    几乎所有云架构都基于微服务架构,请查看将单体应用程序迁移到 Google Kubernetes Engine上的微服务,以获得对微服务的全面了解,以及有关迁移现有应用程序的实用建议
    任何组织都很难改变,在谷歌 re:work 网站上改变谷歌的改变规则对谷歌如何处理改变有一些有趣的见解

    更多相关内容
  • 阿里云原生技术+云原生架构+云原生实践等资料合集,13份。 2021阿里巴巴DevOps实践手册 2021云原生开发者洞察白皮书 阿里巴巴-云原生大规模应用落地指南 阿里巴巴经济体-云原生实践 阿里巴巴云原生架构白皮书 阿里...
  • 从容器化部署、微服务应用模式、研发运营一体化等 云原生特有的技术架构和应用模式出发,全面剖析云原生系统面临的 安全威胁,针对性提出云原生安全边界、原则和防护模型,系统阐述 涵盖基础设施安全、云原生计算...
  • 阿里云-云原生架构白皮书
  • 原生架构白皮书.pdf

    2020-07-21 16:48:44
    目大量涌现,云原生领域进入“火箭式”发展 阶段。通过树立技术标准与构建开发者生态, 开源将云计算实施逐渐标准化,大幅降低了开 发者对于云平台的学习成本与接入成本。这都 让开发者更加聚焦于业务本身并借助云...
  • 本章内容从问题开始,循序渐进,带领读者逐步深入微服务架构的各个角落。2005年,PeterRodgers博士在云端运算博览会上提出的微Web服务(Micro-Web-Service),将程序设计成细粒度的服务(GranularServices),以作为...
  • 今天云原生的定义有众多版本,云原生架构的理解也不尽相同,阿里将根据自身的云原生技术、产品和上云实践,给出自己的理解。
  • 阿里云云原生架构白皮书
  • 原生架构白皮书.zip

    2021-03-04 18:30:01
    讲解为什么需要云原生架构,云原生架构的定义,主要云原生技术,阿里巴巴云原生架构设计,阿里巴巴云原生产品介绍,云原生架构实践案例,云原生架构未来发展趋势等
  • 原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再...
  • 《云原生架构白皮书》
  • 【阿里云·云原生架构·白皮书】 对白皮书的一些总结和解读。

    在这里插入图片描述

    🔎这里是【阿里云·云原生架构·白皮书】,关注我学习云原生不迷路
    👍如果对你有帮助,给博主一个免费的点赞以示鼓励
    欢迎各位🔎点赞👍评论收藏⭐️

    👀专栏介绍

    【阿里云·云原生架构·白皮书】 主要更新一些在学习云原生架构时的一些总结,以及对白皮书内容的解读。

    👀本期介绍

    主要介绍云原生架构定义

    👀云原生架构定义

    从技术的角度,云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。

    云原生架构在这两年逐渐成为应用部署的主流方式。概括来讲云原生是在云计算时代一种构建和运行应用程序的方法,充分利用和发挥云平台的弹性自动化优势,在云上以最佳方式运行。
    在这里插入图片描述
    在这里插入图片描述
    云原生架构与传统架构的对比:

    上图展示了在代码中通常包括三部分:业务代码、三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码;“三方软件”是业务代码中依赖的所有三方库,包括业务库和基础库;“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。

    三部分中只有业务代码是核心,是对业务真正带来价值的,另外两个部分都只算附属物,但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强,使得今天的软件构建变得越来越复杂,对开发人员的技能要求也越来越高。云原生架构相比较传统架构进了一大步,从业务代码中剥离了大量非功能性特性(不会是所有,比如易用性还不能剥离)到laaS和PaaS中,从而减少业务代码开发人员的技术关注范围,通过云厂商的专业性提升应用的非功能性能力。

    此外,具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力,进一步加快软件开发:

    🪂代码结构发生巨大变化

    云原生架构产生的最大影响就是让开发人员的编程模型发生了巨大变化。今天大部分的编程语言中,都有文件、网络、线程等元素,这些元素为充分利用单机资源带来好处的同时,也提升了分布式编程的复杂性;因此大量框架、产品涌现,来解决分布式环境中的网络调用问题、高可用问题、CPU争用问题、分布式存储问题……

    在云的环境中,比如“如何获取存储”变成了若干服务,包括对象存储服务、块存储服务和没有随机访问的文件存储服务。云不仅改变了开发人员获得这些存储能力的界面,还在于云产品在这些OpenAPl或者开源SDK背后把分布式场景中的高可用挑战、自动扩缩容挑战、安全挑战、运维升级挑战等都处理了,应用的开发人员就不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端的问题,也不用处理当业务峰值到来时如何对存储节点进行扩容的问题,而应用的运维人员不用在发现.zero day安全问题时紧急对三方存储软件进行升级……

    云把三方软硬件的能力升级成了服务,开发人员的开发复杂度和运维人员的运维工作量都得到极大降低。显然,如果这样的云服务用得越多,那么开发和运维人员的负担就越少,企业在非核心业务实现上从必须的负担变成了可控支出。在一些开发能力强的公司中,对这些三方软硬件能力的处理往往是交给应用框架(或者说公司内自己的中间件)来做的;在云的时代云厂商提供了更具 SLA的服务,使得所有软件公司都可以由此获益。

    这些使得业务代码的开发人员技能栈中,不再需要掌握文件及其分布式处理技术,不再需要掌握各种复杂的网络技术……简化让业务开发变得更敏捷、更快速!

    🪂非功能性特性的大量委托

    任何应用都提供两类特性,功能性特性和非功能性特性。功能性特性是真正为业务带来价值的代码,比如如何建立客户资料、如何处理订单、如何支付等等;即使是一些通用的业务功能特性,比如组织管理、业务字典管理、搜索等等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值,但通常又是必不可少的特性,比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等等。

    不能说云计算解决了所有非功能性问题,但确实大量非功能性特性,特别是分布式环境下复杂非功能性问题,被云产品处理掉了。以大家最头疼的高可用为例,云产品在多个层面为应用提供了解决方案:

    • 虚机: 当虚机检测到底层硬件异常时,自动帮助应用做热迁移,迁移后的应用不需重新启动而仍然具备对外服务的能力,应用对整个迁移过程都不会有任何感知;
    • 容器: 有时应用所在的物理机是正常的,只是应用自身的问题(比如 bug、资源耗尽等)而无法正常对外提供服务。容器通过监控检查探测到进程状态异常,从而实施异常节点的下线、新节点上线和生产流量的切换等操作,整个过程自动完成而无需运维人员干预;
    • 云服务: 如果应用把“有状态”部分都交给了云服务(如缓存、数据库、对象存储等),加上全局对象的持有小型化或具备从磁盘快速重建能力,由于云服务本身是具备极强的高可用能力,那么应用本身会变成更薄的“无状态”应用,因为高可用故障带来的业务中断会降至分钟级;如果应用是N-M的对等架构架构模式,那么结合Load
      Balancer产品可获得几乎无损的高可用能力!

    🪂高度自动化的软件交付

    软件一旦开发完成,需要在公司内外部各类环境中部署和交付,以将软件价值交给最终客户。软件交付的困难在于开发环境到生产环境的差异(公司环境到客户环境之间的差异)以及软件交付和运维人员的技能差异,填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件打包,容器及相关技术则帮助屏蔽不同环境之间的差异,进而基于容器做标准化的软件交付。

    对自动化交付而言,还需要一种能够描述不同环境的工具,让软件能够“理解”目标环境、交付内容、配置清单并通过代码去识别目标环境的差异,根据交付内容以“面向终态”的方式完成软件的安装、配置、运行和变更。

    基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例,应用微服务化以后,往往被部署到成千上万个节点上,如果系统不具备高度的自动化能力,任何一次新业务的上线,都会带来极大的工作量挑战,严重时还会导致业务变更超过上线窗口而不可用。

    👀总结

    🪂云原生架构的特点

    容器化封装。 容器化封装是指以容器为基础,应用程序封装在容器之中,在容器里运行,实现资源的相对隔离与容器镜像的重复使用。
    面向微服务。 面向微服务是指把一个大的功能应用拆分成一个个功能单一、相对独立、相互解耦的微应用,微应用之间通过接口进行通讯。
    动态管理。 动态管理指通过一个统一的编排工具,比如K8S,来动态的管理和调度这些微服务。

    🪂云原生架构的优势

    快速。 天下武功,无坚不摧,唯快不破!云原生架构使用敏捷开发和DevOps,不但可以让企业快速的开发产品,自动化部署产品,同时还能持续的更新产品,让产品跟得上需求,甚至是引导需求,让企业立于不败之地。
    弹性扩展。 云原生架构天生具有云计算的特点。它的资源是可以按照实际情况进行伸缩,这样不但提高资源的利用率,也大大降低了企业成本。
    安全与强壮。 云原生架构依托于容器编排工具(K8S)与微服务的组合,应用就拥有了自动恢复能力、容错能力、故障隔离能力,让应用时刻处于可用的状态。
    屏蔽底层差异。 因为使用了容器化技术,应用运行于容器之中,应用就不需要考虑底层硬件的差异,只要是能运行容器镜像的硬件都可以运行程序,大大简化了开发工作量。同时对运维人员也非常友好,不需要再为环境问题而苦恼。
    在这里插入图片描述

    展开全文
  • 主要介绍云原生架构原则

    在这里插入图片描述

    🔎这里是【阿里云·云原生架构·白皮书】,关注我学习云原生不迷路
    👍如果对你有帮助,给博主一个免费的点赞以示鼓励
    欢迎各位🔎点赞👍评论收藏⭐️

    👀专栏介绍

    【阿里云·云原生架构·白皮书】 主要更新一些在学习云原生架构时的一些总结,以及对白皮书内容的解读。

    👀本期介绍

    主要介绍云原生架构原则

    云原生架构原则

    云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。

    服务化原则

    当代码规模超出小团队的合作范围时,就有必要进行服务化拆分了,包括拆分为微服务架构、小服务( Mini Service)架构,通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代,避免迭代频繁模块被慢速模块拖慢,从而加快整体的进度和稳定性。同时服务化架构以面向接口编程,服务内部的功能高度内聚,模块间通过公共功能模块的提取增加软件的复用程度。

    分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等,本质上都是基于服务流量(而非网络流量)的控制策略,所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系,标准化服务流量的传输,从而帮助业务模块进行基于服务流量的策略控制和治理,不管这些服务是基于什么语言开发的。

    弹性原则

    大部分系统部署上线需要根据业务量的估算,准备一定规模的机器,从提出采购申请,到供应商洽谈、机器部署上电、软件部署、性能压测,往往需要好几个月甚至一年的周期;而这期间如果业务发生变化了,重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自动伸缩,无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间,让企业不用操心额外软硬件资源的成本支出(闲置成本),降低了企业的IT成本,更关键的是当业务规模面临海量突发性扩张的时候,不再因为平时软硬件资源储备不足而“说不”,保障了企业收益。

    可观测原则

    今天大部分企业的软件规模都在不断增长,原来单机可以对应用做完所有调试,但在分布式环境下需要对多个主机上的信息做关联,才可能回答清楚服务为什么宕机、哪些服务违反了其定义的SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等,这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM等系统提供的能力不同,前者是在云这样的分布式系统中,主动通过日志、链路跟踪和度量等手段,让一次APP点击背后的多次服务调用的耗时、返回值和参数都清晰可见,甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等,这样的能力可以使运维、开发和业务人员实时掌握软件运行情况,并结合多个维度的数据指标,获得前所未有的关联分析能力,不断对业务健康度和用户体验进行数字化衡量和持续优化。

    韧性原则

    当业务上线后,最不能接受的就是业务不可用,让用户无法正常使用软件,影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现各种异常时,软件表现出来的抵御能力,这些异常通常包括硬件故障、硬件资源瓶颈(如CPU/网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件 bug、黑客攻击等对业务不可用带来致命影响的因素。

    韧性从多个维度诠释了软件持续提供业务服务的能力,核心目标是提升软件的MTBF ( Mean TimeBetween Failure,平均无故障时间)。从架构设计上,韧性包括服务异步化能力、重试/限流/降级/熔断Ⅰ反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾等。

    所有过程自动化原则

    技术往往是把“双刃剑”,容器、微服务、DevOps、大量第三方组件的使用,在降低分布式复杂性和提升迭代速度的同时,因为整体增大了软件技术栈的复杂度和组件规模,所以不可避免地带来了软件交付的复杂性,如果这里控制不当,应用就无法体会到云原生技术的优势。通过 laC ( lnfrastructure asCode ) . GitOps、OAM (Open Application Model ) . Kubernetes operator和大量自动化交付工具在CIICD流水线中的实践,一方面标准化企业内部的软件交付过程,另一方面在标准化的基础上进行自动化,通过配置数据自描述和面向终态的交付过程,让自动化工具理解交付目标和环境差异,实现整个软件交付和运维的自动化。

    零信任原则

    零信任安全针对传统边界安全架构思想进行了重新评估和审视,并对安全架构思路给出了新建议。其核心思想是,默认情况下不应该信任网络内部和外部的任何人/设备/系统,需要基于认证和授权重构访问控制的信任基础,诸如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆,引导安全体系架构从“网络中心化”走向“身份中心化”,其本质诉求是以身份为中心进行访问控制。

    零信任第一个核心问题就是ldentity,赋予不同的Entity 不同的 Identity,解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维微服务场景下,ldentity 及其相关策略不仅是安全的基础,更是众多(资源,服务,环境)隔离机制的基础;在员工访问企业内部应用的场景下,ldentity 及其相关策略提供了灵活的机制来提供随时随地的接入服务。

    架构持续演进原则

    今天技术和业务的演进速度非常快,很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用,相反往往还需要对架构进行一定范围内的重构,因此云原生架构本身也应该和必须是一个具备持续演进能力的架构,而不是一个封闭式架构。除了增量迭代、目标选取等因素外,还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制,特别是在业务高速迭代情况下的架构、业务、实现平衡

    关系。云原生架构对于新建应用而言的架构控制策略相对容易选择(通常是选择弹性、敏捷、成本的维度),但对于存量应用向云原生架构迁移,则需要从架构上考虑遗留应用的迁出成本/风险和到云上的迁入成本/风险,以及技术上通过微服务Ⅰ应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用和流量进行细颗粒度控制。

    唯一不变的是变化

    在动物王国,生存有利于那些适应环境的个体。这不是一个从“坏”到“最好”或从“原始”到“进化”的线性过程,而是一切都在不断变化。随着环境的变化,压力被施加到物种的进化和适应上。类似地,云原生架构不会取代传统架构,但它们可以更好地适应非常不同的云环境。云越来越成为我们大多数人工作的环境,许多物种可以证明,不能进化和适应不是一个长期的选择。

    上面描述的原则并不是创建云原生架构的神奇公式,但希望能为如何最大限度地利用云提供强有力的指导。作为一个额外的好处,移动和调整云架构为您提供了以其他方式改进和调整它们的机会,并使它们能够更好地适应下一个环境变化。改变可能很难,但正如数十亿年来进化所显示的那样,你不一定要成为最好的生存者,你只需要能够适应。
    在这里插入图片描述

    展开全文
  • 原生架构白皮书(70页).pdf
  • 点击上方“程序猿技术大咖”,关注并选择“设为星标”回复“加群”获取入群讨论资格!云原生架构是什么回顾过去十年,数字化转型驱动着技术创新和商业元素的不断融合和重构,可以说,现在已经不是由商业...

    点击上方“程序猿技术大咖”,关注并选择“设为星标”

    回复“加群”获取入群讨论资格!

    云原生架构是什么


    回顾过去十年,数字化转型驱动着技术创新和商业元素的不断融合和重构,可以说,现在已经不是由商业模式决定采用何种技术架构,而是由技术架构决定企业的商业模式。所以无论是行业巨头还是中小微企业都面临着数字化转型带来的未知机遇和挑战。机遇是商业模式的创新,挑战来自对整体技术架构的变革。

    新一代的技术架构是什么?如何变革?是多互联网企业面临的问题。而云原生架构则是这个问题最好的答案,因为云原生架构对云计算服务方式与互联网架构进行整体性升级,深刻改变着整个商业世界的 IT 根基

    虽然云原生的概念由来已久,很多人并不理解什么是云原生。从技术的角度来讲,云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、 可观测性、灰度等),使业务不再受非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。简单的说,就是帮助企业的业务功能迭代更快、系统能承受住各种量级的流量冲击的同时,构建系统的成本更低。

    传统架构与云原生架构的区别

    上图展示了在代码中通常包括的三部分内容,即业务代码、第三方软件、处理非功能特性的代码。其中“业务代码”指实现业务逻辑的代码。“三方软件”是业务代码中依赖的所有三方库,包括业务库和基础库。“处理非功能性的代码”指实现高可用、安全、可观测性等非功能性能力的代码。

    这三部分中只有业务代码是对业务真正带来价值的,另外两个部分都只算附属物,但随着软件规模的增大、业务模块规模变大、部署环境增多、分布式复杂性增强,使得今天的软件构建变得越来越复杂,对开发人员的技能要求也越来越高。云原生架构相比较传统架构前进了一大步,即从业务代码中剥离了大量非功能性特性到 IaaS 和 PaaS 中,从而减少业务代码开发人员的技术关注范围,通过云服务的专业性提升应用的非功能性能力。

    这便是云原生架构的核心思路。

    为什么需要云原生架构


    解释完什么是云原生架构后,大家可能会有进一步的思考,即当今互联网企业为什么需要云原生架构。分析下 SaaS 的市场规模可以发现,2019 年 SaaS 市场规模为 360 亿元,2020 年仍保持可观上涨趋势,2022 年 SaaS 市场规模预计破千亿。

    纵观中国企业级 SaaS 行业发展历程,大体分为四个阶段:2015 年之前,中国市场和绝大多数中国企业对“什么是 SaaS”缺乏基本认知,基于私有部署的传统软件形式仍为主流,企业级 SaaS 市场方兴未艾。到了 2015 年,随着云计算技术的进一步成熟,中国企业级 SaaS 行业进入快速成长阶段,这个慢赛道逐渐为公众所知。

    时至今日,在疫情、经济、社会环境的大背景下。互联网企业开始寻求新的商业模式,一些抓住机会的 SaaS 企业实现了快速响应,结果是其业务呈现成倍增长,比如:

    • 餐饮 SaaS 厂商帮助线下餐饮门店开发小程序点餐系统,实现无接触点餐。

    • 电商零售领域的 ERP 厂商帮助企业建立会员管理系统。

    • 营销 SaaS 厂商通过流量平台帮助企业在线营销,远程触达客户。

    所以,在“如何活下去”成为热门议题的背景下,快速响应能力成为企业之间的核心竞争优势,SaaS 企业需要及时满足市场的新需求。而这正是前几年中国 SaaS 企业为了快速占领市场、盲目跟风、一味借鉴国外产品所产生的天生缺陷。为弥补这些缺陷,SaaS 厂商需要根据市场的需求快速调整产品服务方向,业务功能要多元化,业务体系需要新的枝杈,在技术上也有更大的挑战。

    除了市场带来的压力,SaaS 企业自身也有诸多痛点:

    • 大多 SaaS 产品只做所谓的通用能力,或者只是一味模仿国外产品,一旦深入到行业属性比较重的场景时便无法满足需求,所以被贴上了“半成品”的标签,导致市场接受程度不如预期。

    • 产品模块单一、功能相似的 SaaS 产品很容易陷入价格竞争,最后只能以亏损获得网络效应,但会终食恶果。

    • 市场对 SaaS 产品的定制化需求过多,使得 SaaS 企业缺乏对产品打磨的精力,把一个 SaaS 型公司做成了项目型公司。

    SaaS 企业解决以上的外忧内患的核心就是专注在业务。要做好一款 SaaS 产品,对于业务渠道、竞争格局、用户体验等诸多方面都有更加严苛的要求,甚至从市场运营、产品经理到研发、运维都要专注在业务,所有这些角色的本职工作都应该为行业业务服务,行业的深度分析,快速响应市场,稳定的产品质量这些是必须要具备的。

    但这就要求技术具备更快的迭代速度,业务推出速度从按周提升到按小时,每月上线业务量从“几十 / 月”提升到“几百 / 天”,并且不可接受业务中断。

    另一个互联网企业需要云原生转型的原因是中国的刘易斯拐点已经到来。刘易斯拐点,即劳动力过剩向短缺的转折点,是指在工业化进程中,随着农村富余劳动力向非农产业的逐步转移,农村富余劳动力逐渐减少,最终达到瓶颈状态。用大白话说就是中国的人口红利已经逐渐消退,企业劳动力成本不断增加,加上 2020 年疫情的影响,成本因素越来越成为企业的重要考量。

    而 SaaS 产品订阅制付费、通用性强、低部署成本的特点,便成了企业降本增效的新选择。这是 SaaS 企业在市场中的机会,而且对于 SaaS 企业本身来说,同样有降本增效的需求,而且内部降本增效做得越好,SaaS 产品在市场上的竞争力会更加明显。

    以上这些现状的解法和云原生架构和核心能力不谋而合:

    • 云原生将三方软件和非功能性能力的完全兜底,可以极大程度解放企业研发、运维人员的精力,并使其可以专注在业务上。

    • 系统的横向扩展性、高可用性、健壮性、SLA 由云原生架构兜底,解决了 SaaS 产品最忌讳的稳定性问题。

    • 将一些自建的组件迁移至云原生架构中,对传统的部署方式和资源进行云原生化,GitOps 的落地,在资源成本和人力成本方面都有进一步的优化。

    如何落地云原生架构


    在聊如何落地云原生架构之前,我们先来看一看云原生架构成熟度模型(SESORA):

    云原生架构成熟度模型

    云原生架构成熟度模型有六个评判维度,可以将成熟度划分为 4 个级别。我会从自动化能力、无服务化能力、弹性能力、可观测性、韧性能力这五个维度,贯穿说明如何落地云原生架构。

    传统架构

    上图展示的是一个较传统的 Java+SpringCloud 架构应用服务侧的部署架构。除了 SLB,基本上所有的组件都部署在 ECS 上。下面我们来一起看看如何将这个架构转型为云原生架构。

    无服务化(Serverless)

    Serverless 的概念是什么在这篇文章不再赘述,可以参阅这篇文章进行了解。使用 ECS 集群部署服务的架构有两个显著的短板:

    • 运维成本高:ECS 的各项状态、高可用都需要运维同学维护。

    • 弹性能力不足:每次有大促活动时,都需要提前购买 ECS,扩展服务的节点数,然后再释放,并且这种情况只适用于定时定点的活动,如果是不定时的流量脉冲则无法应对。

    所以首先我们要将服务的部署方式 Serverless 化,我们可以选择 Serverless App Engine(SAE)作为服务应用的发布、部署平台。SAE 是面向应用的 Serverless PaaS 平台,能够帮助用户免运维 IaaS、按需使用、按量计费,做到低门槛服务应用云原生化,并且支持多种语言和高弹性能力。

    1、命名空间

    打开 SAE 控制台,我们首先创建命名空间,SAE 的命名空间可以将其下的应用进行网络和资源的逻辑隔离,通常我们可使用命名空间来区分开发环境、测试环境、预发环境、生产环境。

    2、创建应用

    创建好命名空间后,我们进入应用列表,即可选择不同的命名空间,看到其下的应用或者创建应用:

    选择对应的命名空间,然后创建应用:

    • 应用名称:服务名称,用户自行输入。

    • 专有网络配置:

      • 自动配置:自动帮用户配置 VPC、Vswitch、安全组。这些组件都会新创建。

      • 自定义配置:用户选择命名空间,VPC,VSwitch 以及安全组。一般选择自定义配置,因为咱们的服务所属的VPC肯定要和其他云资源的 VPC 是相同的,这样才能保证网络畅通。这里需要注意的一点是,当在新的命名空间下第一次创建好应用后,该命名空间就会和所选的 VPC 进行绑定,之后再创建应用时,该命名空间对应的 VPC 不可更改。如果需要更改,可以进入命名空间详情进行更改。

    • 应用实例数:应用(服务)节点数量,这里的节点数量按需设置,而且不是最终设定,因为后续可以手动或者自动的扩缩节点数。

    • VCPU/ 内存:该应用在运行过程中需要的CPU和内存的规格。这里的规格是单个实例数的规格。既如果选择了 2C4G,那么有 2 个实例的话,就是 4C8G。

    配置完基本信息后,下一步进入应用部署配置:

    • 技术栈语言:Java 语言支持镜像、War 包、Jar 包三种部署方式,其他语言支持镜像部署方式。以 Java Jar 包方式为例:

      • 应用运行环境:默认标准 Java 应用运行环境即可。

      • Java 环境:目前支持 JDK7 和 JDK8。

      • 文件上传方式:支持手动上传 Jar 包或者配置可以下载 Jar 包的地址。

    • 版本:支持时间戳和手动输入。

    • 启动命令设置:配置 JVM 参数。

    • 环境变量设置:设置容器环境中的一些变量,便于应用部署后灵活的变更容器配置。

    • Host 绑定设置:设置 Host 绑定,便于通过域名访问应用。

    • 应用健康检查设置:用于判断容器和用户业务是否正常运行。

    • 应用生命周期管理设置:容器侧的生命周期脚本定义,管理应用在容器在运行前和关闭前的一些动作,比如环境准备、优雅下线等。

    • 日志收集服务:和 SLS 日志服务集成,统一管理日志。

    • 持久化存储:绑定 NAS。

    • 配置管理:通过挂载配置文件的方式向容器中注入配置信息。

    我使用 Jar 包的方式部署完应用后,在对应命名空间下就可以看到刚刚创建的应用了:

    点击应用名称可以查看应用详情:

    3、绑定 SLB

    因为 ServiceA 在架构中是对外提供接口的服务,所以需要对该服务绑定公网 SLB 暴露 IP 和做负载均衡,在 SAE 中,绑定 SLB 非常简单,在详情页中,即可看到应用访问设置:

    添加 SLB 时可以选择新建也可以选择已经创建好的 SLB:

    4、服务/配置中心

    对于微服务架构,服务中心和配置中心是必不可少的,大家常用到一般是 Nacos、Eureka、ZooKeeper 三种。对于云原生架构来讲,根据不同的场景,服务/配置中心可以有以下几种选择:

    对于现状就是使用 Nacos 的客户而言,转型云原生架构,服务/配置中心如上面表格所示有两种选择:

    • 需要快速转型,对服务/配置中心高可用要求不是特别极致的情况下,建议直接使用 SAE 自带的 Nacos 即可,代码不需要做改动,直接在 SAE 中创建应用即可。SAE 控制台提供的配置管理在界面操作和功能上和开源 Nacos 的控制台基本一致。

    • 对服务/配置中心高可用要求比较高的情况下,建议使用 MSE Nacos,它的优势是独享集群,并且节点规格和节点数量可以根据实际情况动态的进行调整。唯一不足的一点就是需要修改 Nacos 的接入点,算是有一点代码侵入。

    对于现状是使用 Eureka 和 ZooKeeper 的客户而言,建议直接使用 MSE Eureka 和 MSE ZooKeeper。

    这里我简单介绍一下 MSE。微服务引擎 MSE(Microservice Engine)是一个面向业界主流开源微服务框架 Spring Cloud 和 Dubbo 一站式微服务平台,提供治理中心、托管的注册中心和托管的配置中心。这里我们用到的是 MSE 的托管注册中心和托管配置中心。

    MSE 有三块核心的功能点:

    • 支持三大主流服务中心,节点规格和数量灵活搭配,可在运行时动态调整节点规格/数量。

    • 通过命名空间逻辑隔离不同环境。

    • 配置变更实时推送并且可追踪。


    弹性能力(Elasticity)


    云原生架构成熟度模型中的弹性能力同样依托于 SAE 来实现,因为 Serverless 的底层实现原理,所以在 SAE 中的应用实例数(节点数)扩缩速度非常快,可达到秒级。

    进入应用详情页的实例部署信息,可以看到应用的具体实例:

    SAE 提供了两种扩缩应用实例数的方式,手动方式和自动方式。


    1、手动扩缩

    在控制台右上方有手动扩缩操作按钮,然后选择要扩缩到的实例数即可:

    当进行扩缩时,我们可以看到具体实例的变更状态:

    2、自动扩缩

    在控制台右上角有自动扩缩操作按钮,然后可以看到创建扩缩规则的界面。SAE 自动扩缩提供时间策略和指标策略两种。

    上图是时间策略,即设置好具体的时间节点,在这个时间节点要将应用的实例数扩到几个或者缩到几个。这种策略适合流量高峰期有相对明确时间节点的场景,比如在线教育的客户,通常流量高峰在晚上 8 点开始,11 点逐渐结束,这种情况下,通过定时策略在 7 点半左右把应用的实例数扩起来,然后 11 点之后逐渐把应用实例数缩回正常。

    上图是指标策略,目前提供 CPU 使用率、内存使用率、应用的 QPS 阈值、应用接口平均响应时间(RT)阈值四种指标,这四种指标可以配合使用。当这四种指标其中有一种达到阈值后就会触发扩容,会对应用实例进行逐渐扩容。当指标小于阈值后触发缩容。这种策略适合流量高峰时间不固定的场景,比如市场营销,游戏运营。

    3、成本优化

    对于弹性能力,大家可能更多的是关注它能让系统快速支撑流量脉冲,增加系统横向扩展的能力。其实因为SAE有极致的弹性能力,再加上按分钟、按量计费的模式,对整体的资源成本是有一定优化的。

    可观测性(Observability)

    应用侧的可观测性分两个维度,一是纵向的 Metrics 指标,比如主机的 CPU、内存、磁盘各项指标,Pod 的 CPU、内存各项指标,JVM 的 Full GC、堆内存、非堆内存各项指标。另一个维度是横向的请求调用链路监测,上游服务到下游服务的调用、上游接口到下游接口的调用。

    在监控微服务架构时,通常需要从三个角度来看:

    • 应用的整体健康状况。

    • 应用每个实例的健康状况。

    • 应用每个接口的健康状况。

    而SAE对应用的监控也都覆盖了上述这两个维度和三个角度。

    1、应用整体健康状况

    进入应用详情页,点击左侧菜单中的应用监控/应用总览,便可以看到应用的整体状况:

    • 总请求量:可以一目了然的看到请求量是否明显的异常,比如骤降或者陡升。

    • 平均响应时间:应用整体接口的平均响应时间,这个指标直接反映最真实的应用健康状况。

    • Full GC:JVM 里比较重要的指标,也是会直接影响系统性能的因素。

    • 慢 SQL:智能抓取执行时间大于 500ms 的 SQL。

    • 一些曲线视图:帮助我们掌握不同时段的应用情况。

    2、应用实例节点健康状况

    进入应用详情页,点击左侧菜单中的应用监控/应用详情,便可以看到应用每个节点的信息:

    从上图可以看到,左侧会列出当前应用的所有实例节点,包括该节点的平均响应时间、请求次数、错误数、异常数。如果我们按照影响时间降序排序,比较靠上的节点就是响应时间较慢的节点,然后我们就需要分析是什么原因导致这些节点的响应时间较慢。所以,右侧会提供了一些检查维度来帮助我们分析排查问题。

    比如查看 JVM 指标:

    3、应用接口健康状况

    进入应用详情页,点击左侧菜单中的应用监控/接口调用,便可以看到应用每个接口的信息:

    接口监控和应用实例节点监控的思路一致,左侧会列出所有请求过的接口,同样显示了响应时间、请求数、错误数,右侧同样提供了一些检查维度来帮助我们分析接口 RT 高的原因。

    比如查看 SQL 调用分析:


    4、纵向 Metrics 指标

    在上述三个角度中,其实已经涵盖了绝大多数 Metrics 指标,比如有应用健康状态的指标、JVM 的指标、SQL 指标、NoSQL 指标等。


    5、横向调用链路

    在很多时候,我们单纯的看 Metrics 指标是无法确定问题的根本原因的,因为会涉及到不同服务之间的调用,不同接口之间的调用,所以需要查看服务和服务之间、接口和接口之间的调用关系以及具体的代码信息。在这个维度上,SAE 集成的 ARMS 的监控能力便可以实现。我们在应用监控/接口调用/接口快照中可以看到有请求的接口快照,通过 TraceID 便可以查看该接口的整体调用链路:

    从上面这个图我们可以看出很多信息:

    • 该接口在服务级别的完整请求链路,比如 ikf(前端)-> ikf-web(java 服务)-> ikf-blog(java 服务)-> ikf-blog(java 服务)。

    • 每个服务的状态情况,比如状态一列是红点,说明在这个环节是有异常出现的。

    • 在每个服务中请求的接口名称。

    • 每个服务的请求耗时。

    除了上述这些显性的信息以外,还有一些隐性的信息:

    • 上游服务 ikf-web 的总耗时是 2008ms,但下游服务 ikf-blog 的总耗时是 5052ms,而且耗时起点是一样的,说明 ikf-web 到 ikf-blog 是一个异步调用。

    • 既然 ikf-web 到 ikf-blog 是异步调用,然而 ikf-web 的耗时有 2s 之多,说明 ikf-web 服务中的接口也有问题。

    • 在 ikf-blog 服务中,又有内部接口被调用,因为从调用链上出现了两个 ikf-blog,并且这个内部调用是同步调用,而且问题出现在最后一个接口调用上。

    从以上这些信息可以帮我们缩小和圈定问题根因出现在哪个环节的范围,然后我们可以点击方法栈一列的放大镜,查看具体的方法栈代码信息:

    从方法栈这里我们又可以得到很多显性信息:

    • 具体的方法。

    • 每个方法的耗时。

    • 方法产生的具体异常信息。

    • 数据库操作的具体 SQL 语句,甚至 SQL 上的 Binding Value。

    当然除了显性信息外,还有一个比较重要的隐性信息,比如我们可以看到BlogController.findBlogByIsSelection(int isSelection)这个方法的耗时是 5s,但是该方法内部的数据库操作的耗时很少,只有 1ms,说明耗时是属于业务代码的,毕竟业务代码我们是抓不到也不会去抓取信息的。这时我们可以有两种方式去定位具体问题:

    • 从方法栈信息中已经知道了具体的服务和具体的方法,那么直接打开 IDE 查看、分析代码。

    • 查看方法栈页签旁边的线程剖析,也基本可以确定问题所在。比如上图这个情况,我们查看线程剖析后会发现他的耗时是因为java.lang.Thread.sleep( ):-2 [3000ms]


    韧性能力(Resilience)

    对于云原生架构的韧性能力,我会从优雅上下线、多AZ部署、限流降级三个方面来聊一聊。

    1、优雅上下线

    一个好的产品,要能快速应对用户对产品功能、能力具有普适性的反馈和意见,能快速响应市场需求的变化。那么产品的功能就需要快速的做迭代和优化,从 IT 层面来看,就是要有快速、高效、高质量的发布变更流程,能够随时进行生产环境的服务发布。

    但是这会带来一个核心问题,即频繁的服务发布,并且不能影响用户体验,用户的请求不能断流。所以这就要求我们的系统部署架构中有优雅上下线的能力。

    以微服务架构来说明,虽然开源的产品有能力和方案做到近似优雅上下线,但也是近似做到,当发布服务节点较多的情况下依然会有断流的情况。所以开源方案有诸多问题:

    • 注册中心不可靠、通知不及时。

    • 客户端轮训不实时、客户端缓存。

    • 自定义镜像非1号进程,Sigterm 信号无法传递。

    • 无默认优雅下线方案,需要添加 actuator 组建。

    在无服务化/服务配置中心章节中,我阐述了 SAE 自带的服务中心和 MSE 的服务中心,无论使用那种方案,我们都对优雅上下线做了进一步的优化。

    从上图可以看到,部署在 SAE 的应用具有主动通知服务中心和服务消费者的能力,再结合 Liveness 应用实例探活和 Readiness 应用业务探活的机制,能让我们的服务在进行部署和因为其他原因挂掉时不会影响用户的正常访问。


    2、多 AZ 部署

    本着鸡蛋不能放在一个篮子里的原则,一个应用的多个节点,应该分布在不同的可用区,这样整体应用的高可用和健壮性才是足够好的。SAE 支持设置多个交换机(VSwitch),每个交换机可以在不同的可用区,这样在部署、扩容应用的节点时会随机从可选的可用区拉起实例:

    这就避免了当某个可用区出现问题挂掉时,整体系统因为在一个可用区而挂掉,这也是最基本的同城多活的实践。


    3、限流降级

    限流降级是系统断臂求生的能力,在遇到突发的流量脉冲时,可以及时限制流量,避免整个系统被击穿,或者当流量超出预期时,及时切断非核心业务,释放资源来支撑核心业务。

    目前对于 Java 应用,SAE 也支持限流降级的能力,首先对应用的所有接口的请求指标进行抓取和监控:

    然后我们可以针对每一个接口设置流控、隔离、熔断的规则,比如我对 /checkHealth 接口设置一条流控规则:

    当该接口的 QPS 达到 50 后,单个机器超过 50 的请求将快速失败。比如我们对一个有 6 个节点的应用进行压测时,可以看到每个节点的 QPS 情况:

    当开启流控规则后,可以立即看到限流的效果:

    可以看到 QPS 被精准的控制到 50,超过 50 的请求直接返回失败。

    自动化能力(Automation)

    在自动化能力方面,我主要从 CICD 流程这个维度来聊一聊。大家从上面章节的截图可以看到,有很多是 SAE 控制台的截图,在实际应用中肯定不会通过控制台来一个一个发布应用,必然都是通过 CICD 流程来做自动化的应用打包和发布流程。

    SAE 在这个方面提供两种实现自动化运维的方式。


    1、基于 Gitlab 和 Jenkins

    目前很多企业的 CICD 流程都是基于 Gitlab 和 Jenkins 来做的,那么 SAE 也支持将发布的操作集成到这种方案里。这个方案的核心是 SAE 会提供一个 Maven 插件,同时对应有三个配置文件,Maven 插件通过这三个配置文件中的信息将打包好的 Jar/War 或者镜像发布到对应的 SAE 应用中。

    • toolkit_profile.yaml:配置 RegionID、AccessKey ID、AccessKey Secret。

    • toolkit_package.yaml:配置比如应用部署包类型、部署包地址、镜像地址。

    • toolkit_deploy.yaml:配置比如 SAE 应用的 ID、应用所属命名空间 ID、应用名称、发布方式等。

    更详细的配置信息可以参阅该文档。

    然后在 Jenkins 的任务中,对 Maven 设置如下的命令即可:

    clean package toolkit:deploy -Dtoolkit_profile=toolkit_profile.yaml -Dtoolkit_package=toolkit_package.yaml -Dtoolkit_deploy=toolkit_deploy.yaml 
    
    
    

    这样就可以很容易的将 SAE 的部署流程集成到基于 Gitlab 和 Jenkins 的 CICD 方案里了。

    2、基于 Open API

    还有一些企业会自己研发运维平台,运维赋能研发,由研发同学在运维平台上进行运维操作。面对这种场景,SAE 提供了丰富的 Open API,可以将 SAE 控制台上 90% 的能力通过 Open API 集成到客户自己的运维平台中。详细的 OpenAPI 说明可以参与该文档。

    总结


    基于 SAE 武装过系统后,整体的部署架构会变成这样:

    云原生架构成熟度模型(SESORA)在我阐述的这五个维度一共是 15 分,基于 SAE 的云原生架构在这五个维度会达到 12 分:

    • 无服务化:3分

    • 弹性能力:3分

    • 可观测性:2分

    • 韧性能力:2分

    • 自动化能力:2分

    对于上手、实践、落地快捷简单,又能达到比较好的云原生架构成熟度的 SAE 方案,大家还在等什么呢?一起实践起来吧。


    感谢您的阅读,也欢迎您发表关于这篇文章的任何建议,关注我,技术不迷茫!

    喜欢就点个"在看"呗,留言、转发朋友圈

    展开全文
  • 原生架构白皮书(阿里云)
  • 原生架构概述

    2021-02-24 08:05:11
    在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。目前CNCF所托管的应用已达14个,下图为其公布的...
  • 通过剖析和展示一个端到端的简化微服务应用案例MovieApp,帮助学员学习理解现代微服务应用和云原生架构实践,内容包括: 微服务应用架构前后分离应用架构基于Spring Security + JWT的微服务安全架构Spring Boot...
  • 最近断断续续花了差不多2到3周的时间阅读完由电子工业出版社出版的《金融级IT架构:数字银行的云原生架构解密》的这本书,作者是作者是网商银行技术编委会。 本书契合了当前银行业分布式架构转型趋势,内容是经过...
  • 原生架构重要组成部分之微服务

    千次阅读 2022-02-15 22:11:15
    各大厂商公司都运用了该技术架构,随着技术与理念的升级迭代,云原生概念应世而起,现在火的一塌糊涂。做为新时代的程序员,我们要抓住云原生的浪潮。 这篇文章呢大致分为四部分,第一部分简单谈一下什么是云...
  • 2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征 符合12因素应用(12 Factors Application) 面向微服务架构(Microservices) 自服务敏捷集成设施(Self Service Agile ...
  • 论云原生架构及其应用

    千次阅读 2020-12-19 00:04:28
      本文以该系统为例,主要论述了云原生架构在项目中的具体应用。系统以Spring Cloud微服务框架开发,分为前端Web服务、平台保障服务、业务服务三部分。前端Web服务由负载均衡与服务器集群结合,实现高并发的前台...
  • 分享课程——基于云原生架构构建亿级多语言电商平台设计到落地实现第一阶段,课程一共3个阶段,当前课程是第一阶段,其余2个阶段暂时没有录制完成。 本阶段内容:会基于云原生实现电商系统的大部分核心服务,包括:...
  • 符合云原生架构的应用程序应该是:采用开源堆栈(K8S+Docker)进行容器化,基于微服务架构提高灵活性和可维护性,借助敏捷方法、DevOps(开发运维)支持持续迭代和运维自动化,利用云平台设施实现弹性伸缩、动态调度...
  • 原生架构下的软件生产力体系演进 业务架构微服务化阶段必须通过全链路应用监控快速找 到故障根因,提前发现故障隐患 依赖微服务框架治理业务局部隔 离,才能确保业务可用自愈 需要通过分布式事务框架来保证 业务...
  • 原生技术架构与实践

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 159,686
精华内容 63,874
关键字:

原生架构

友情链接: 14A42.zip