【系统架构设计师】二十、云原生架构设计理论与实践①

目录

一、云原生架构内涵

二、云原生的原则

三、主要架构模式

四、典型的云原生架构反模式

相关推荐


一、云原生架构内涵

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

        云原生的代码通常包括三部分:业务代码、三方软件、处理非功能特性的代码

        具备云原生架构的应用可以最大程度利用云服务和提升软件交付能力,进一步加快软件开发。基于云原生架构的应用特点包括:
        (1)代码结构发生巨大变化:不再需要掌握文件及其分布式处理技术,不再需要掌握各种复杂的网络技术,简化让业务开发变得更敏捷、更快速。
        (2)非功能性特性大量委托给云原生架构来解决:比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。
        (3)高度自动化的软件交付:基于云原生的自动化软件交付可以把应用自动部署到成千上万的节点上。

二、云原生的原则

        云原生架构本身作为一种架构,也有若干架构原则作为应用架构的核心架构控制面,通过遵从这些架构原则可以让技术主管和架构师在做技术选择时不会出现大的偏差。云原生具有以下原则:
        (1)服务化原则:通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代。
        (2)弹性原则:弹性是指系统的部署规模可以随着业务量的变化而自动伸缩。
        (3)可观测原则:通过日志、链路跟踪和度量等手段,使得多次服务调用的耗时、返回值和参数都清晰可见。
        (4)韧性原则:软件所依赖的软硬件组件出现各种异常时,软件表现出来的抵御能力。
        (5)所有过程自动化原则:让自动化工具理解交付目标和环境差异,实现整个软件交付和运维的自动化。
        (6)零信任原则:不应该信任网络内部和外部的任何人/设备/系统,需要基于认证和授权重构访问控制的信任基础。
        (7)架构持续演进原则:架构具备持续演进能力。

三、主要架构模式

        云原生涉及的主要架构模式有:

        (1)服务化架构模式:典型模式是微服务和小服务模式。通过服务化架构,把代码模块关系和部署关系进行分离,每个接口可以部署不同数量的实例,单独扩缩容,从而使得整体的部署更经济。

        (2)Mesh 化架构模式:Mesh 化架构是把中间件框架(如 RPC、缓存、异步消息等)从业务进程中分离,让中间件 SDK 与业务代码进一步解耦,从而使得中间件升级对业务进程没有影响,甚至迁移到另外一个平台的中间件也对业务透明。

        (3)Serverless 模式:将“部署”这个动作从运维中“收走”,使开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等,也就是把应用的整个运行都委托给云。事件驱动架构图如图14-2所示。 Serverless非常适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。

        (4)存储计算分离模式:在云环境中,推荐把各类暂态数据(如session)、结构化和非结构化持久数据都采用云服务来保存,从而实现存储计算分离

        (5)分布式事务模式:大颗粒度的业务需要访问多个微服务,必然带来分布式事务问题,否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。

        (6)可观测架构:可观测架构包括Logging、Tracing、Metrics三个方面,其中Logging提供多个级别 (verbose/debug/warning/error/fatal)的详细信息跟踪,由应用开发者主动提供; Tracing提供一个请求从前端到后端的完整调用链路跟踪,对于分布式场景尤其有用;Metrics则提供对系统量化的多维度度量。

        (7)事件驱动架构:本质上是一种应用/组件间的集成架构模式。可用于服务解耦、增强服务韧性、数据变化通知等场景中。

四、典型的云原生架构反模式

        架构设计有时候需要根据不同的业务场景选择不同的方式,常见的云原生反模式有:

        (1)庞大的单体应用:缺乏依赖隔离,代码耦合,责任和模块边界不清晰,模块间接口缺乏治理,变更影响扩散,不同模块间的开发进度和发布时间要求难以协调,一个子模块不稳定导致整个应用都变慢,扩容时只能整体扩容而不能对达到瓶颈的模块单独扩容等。

        (2)单体应用“硬拆”为微服务:强行把耦合度高、代码量少的模块进行服务化拆分;拆分后服务的数据是紧密耦合的;拆分后成为分布式调用,严重影响性能。

        (3)缺乏自动化能力的微服务:人均负责模块数上升,人均工作量增大,也增加了软件开发成本。

相关推荐

【系统架构设计师】十九、层次式架构设计理论与实践①-CSDN博客文章浏览阅读594次,点赞24次,收藏5次。层次式体系结构设计是一种常见的架构设计方法,也称为 N 层架构设计,它将系统组成为一个层次结构,每一层为上层服务,并作为下层客户。在一些层次系统中,除了一些精心挑选的输出函数外,内部的层接口只对相邻的层可见。层次式体系结构的每一层最多只影响两层,同时只要给相邻层提供相同的接口,也允许每层用不同的方法实现,这种方式也为软件重用提供了强大的支持。大部分的应用会分成表现层(或称为展示层)、中间层(或称为业务层)、访问层(或称为持久层)和数据层。https://shuaici.blog.csdn.net/article/details/140684710【系统架构设计师】十八、信息系统架构设计理论与实践①-CSDN博客文章浏览阅读728次,点赞40次,收藏20次。信息系统架构(ISA)是指对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处理的活动。目前关于信息系统架构较为权威的定义有:(1)信息系统架构是系统的结构,由软件元素、元素外部可见属性和元素间关系组成。(2)信息系统架构是软件系统结构、行为和属性的高级抽象,由系统元素描述、元素间相互作用、元素集成模式及模式约束组成。(3)信息系统架构是系统的基础组织,体现为构件、构件间关系、构件和环境间关系、构件设计和演进的原则。https://shuaici.blog.csdn.net/article/details/140641460【系统架构设计师】九、软件工程(项目管理|进度管理|软件配置管理|软件质量管理|软件风险管理 )-CSDN博客文章浏览阅读1.5k次,点赞40次,收藏10次。面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。为使软件项目开发获得成功,关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的任务、经历的里程碑、花费工作量(成本)、进度安排等进行预先计划和执行。:识别出项目中已知和可预测的风险,确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险,形成一个风险列表。https://shuaici.blog.csdn.net/article/details/140344001【系统架构设计师】一、计算机系统基础知识(指令系统|存储系统|输入输出技术|总线结构)_龙架构中st.w指令内存有效地址是按照哪种寻址方式计算获得的-CSDN博客文章浏览阅读1.3k次,点赞20次,收藏32次。一、指令系统1.1 计算机指令,操作码决定要完成的操作,操作数指参加运算的数据及其所在的单元地址。在计算机中,操作要求和操作数地址都由二进制数码表示,分别称作操作码和地址码,整条指令以二进制编码的形式存放在存储器中。取指令-一分析指令--执行指令首先将程序计数器PC中的指令地址取出,送入地址总线,CPU依据指令地址去内存中取出指令内容存入指令寄存器IR;而后由指令译码器进行分析,分析指令操作码;最后执行指令,取出指令执行所需的源操作数。1.2 指令寻址方式。_龙架构中st.w指令内存有效地址是按照哪种寻址方式计算获得的https://shuaici.blog.csdn.net/article/details/139685161

  • 17
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

帅次

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值