【云原生架构】阿里云 —— 主要架构模式

2022年05月15日 阅读数:2
这篇文章主要向大家介绍【云原生架构】阿里云 —— 主要架构模式,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

在这里插入图片描述

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

👀专栏介绍

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

👀本期介绍

主要介绍主要架构模式
后端

主要架构模式

云原生架构有很是多的架构模式,这里选取一些对应用收益更大的主要架构模式进行讨论。缓存

服务化架构模式

服务化架构是云时代构建云原生应用的标准架构模式,要求以应用模块为颗粒度划分一个软件,以接口契约(例如IDL)定义彼此业务关系,以标准协议(HTTP、gRPC等)确保彼此的互联互通,结合DDD(领域模型驱动)、TDD(测试驱动开发)、容器化部署提高每一个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务(Mini Service)模式,其中小服务能够看作是一组关系很是密切的服务的组合,这组服务会共享数据,小服务模式一般适用于很是大型的软件系统,避免接口的颗粒度太细而致使过多的调用损耗(特别是服务间调用和数据一致性处理)和治理复杂度。安全

经过服务化架构,把代码模块关系和部署关系进行分离,每一个接口能够部署不一样数量的实例,单独扩缩容,从而使得总体的部署更经济。此外,因为在进程级实现了模块的分离,每一个接口均可以单独升级,从而提高了总体的迭代效率。但也须要注意,服务拆分致使要维护的模块数量增多,若是缺少服务的自动化能力和治理能力,会让模块管理和组织技能不匹配,反而致使开发和运维效率的下降。服务器

SBA网络架构具有三大特征:
一、松耦合的微服务
二、轻量高效的服务调用接口
三、自动化、智能化的服务管理框架网络

Mesh 化架构模式

Mesh 化架构是把中间件框架(好比RPC、缓存、异步消息等)从业务进程中分离,让中间件SDK与业务代码进一步解耦,从而使得中间件升级对业务进程没有影响,甚至迁移到另一个平台的中间件也对业务透明。分离后在业务进程中只保留很“薄”的Client部分,Client一般不多变化,只负责与Mesh进程通信,原来须要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。整个架构以下图所示。session

在这里插入图片描述
在这里插入图片描述

实施Mesh 化架构后,大量分布式架构模式(熔断、限流、降级、重试、反压、隔仓……)都由Mesh进程完成,即便在业务代码的制品中并无使用这些三方软件包;同时得到更好的安全性(好比零信任架构能力)、按流量进行动态环境隔离、基于流量作冒烟/回归测试等。架构

Mesh网络有其自身的特色:并发

一、平衡负载,Mesh网络能够提供更大的冗余度以利负载平衡。在比较繁忙的网络,例若有两台设备进行大数据量的通信,每台设备附近都有许多节点可供选择,建立多条路径来平衡负载。而单跳网络则没有动态调整的能力。

二、健壮性,由于Mesh网络不像单跳网络,仅仅依靠一个节点,一旦某个节点出现故障或者有冲突发生,Mesh网络能够继续工做,数据也可选择替代路径继续传递。

三、空间的复用性,Mesh网络能够充分地利用带宽。在一个单跳环境中,全部设备不得不共享一个节点,若是多台设备同时要求接入网络,那么必然致使速度变慢;而Mesh网络,多设备能够同时接入网络,却经过不一样的节点。

Serverless模式

和大部分计算模式不一样,Serverless 将“部署”这个动做从运维中“收走”,使开发者不用关心应用在哪里运行,更不用关心装什么OS、怎么配置网络、须要多少CPU……从架构抽象上看,当业务流量到来/业务事件发生时,云会启动或调度一个已启动的业务进程进行处理,处理完成后云自动会关闭/调度业务进程,等待下一次触发,也就是把应用的整个运行时都委托给云。

今天Serverless 尚未达到任何类型的应用都适用的地步,所以架构决策者须要关心应用类型是否适合于Serverless运算。若是应用是有状态的,云在进行调度时可能致使上下文丢失,毕竟Serverless 的调度不会帮助应用作状态同步;若是应用是长时间后台运行的密集型计算任务,会得不到太多Serverless的优点;若是应用涉及到频繁的外部VO(网络或者存储,以及服务间调用),也由于繁重的IO负担、时延大而不适合。Serverless很是适合于事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。

Serverless 架构的 Traits 特质:

入门门槛低(Low barrier-to-entry)
无主机(Hostless)
无状态(Stateless)
弹性(Elasticity)
分布式(Distributed)
事件驱动(Event-driven)

存储计算分离模式

分布式环境中的CAP困难主要是针对有状态应用,由于无状态应用不存在C(一致性)这个维度,所以能够得到很好的A(可用性)和P(分区容错性),于是得到更好的弹性。在云环境中,推荐把各种暂态数据(如session )、结构化和非结构化持久数据都采用云服务来保存,从而实现存储计算分离。但仍然有一些状态若是保存到远端缓存,会形成交易性能的明显降低,好比交易会话数据太大、须要不断根据上下文从新获取等,则能够考虑经过采用Event Log +快照(或 Check Point)的方式,实现重启后快速增量恢复服务,减小不可用对业务的影响时长。

分离架构有如下优点:

  1. 对于不一样类型的集群,能够针对性地部署更加合适的服务器;

  2. 计算和存储能够分别按需进行扩展,而不是一块儿扩展;

  3. 不一样集群能够有不一样的升级周期;

  4. 划分了运维职责,更加便于管理;

  5. 提升了资源利用率,下降了能耗开销。

分布式事务模式

微服务模式提倡每一个服务使用私有的数据源,而不是像单体这样共享数据源,但每每大颗粒度的业务须要访问多个微服务,必然带来分布式事务问题,不然数据就会出现不一致。架构师须要根据不一样的场景选择合适的分布式事务模式。

  • 传统采用XA模式,虽然具有很强的一致性,可是性能差;
  • 基于消息的最终一致性(BASE)一般有很高的性能,可是通用性有限,且消息端只能成功而不能触发消息生产端的事务回滚;
  • TCC模式彻底由应用层来控制事务,事务隔离性可控,也能够作到比较高效;可是对业务的侵入性很是强,设计开发维护等成本很高;
  • SAGA模式与TCC模式的优缺点相似但没有try这个阶段,而是每一个正向事务都对应一个补偿事务,也是开发维护成本高;
  • 开源项目SEATA的AT模式很是高性能且无代码开发工做量,且能够自动执行回滚操做,同时也存在一些使用场景限制。

可观测架构

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

架构决策者须要选择合适的、支持可观测的开源框架(好比OpenTracing、OpenTelemetry ) ,并规范上下文的可观测数据规范(例如方法名、用户信息、地理位置、请求参数等),规划这些可观测数据在哪些服务和技术组件中传播,利用日志和tracing 信息中的span id/trace id,确保进行分布式链路分析时有足够的信息进行快速关联分析。

因为创建可观测性的主要目标是对服务SLO ( Service Level Objective)进行度量,从而优化SLA,所以架构设计上须要为各个组件定义清晰的SLO,包括并发度、耗时、可用时长、容量等。

事件驱动架构

事件驱动架构(EDA,Event Driven Architecture)本质上是一种应用/组件间的集成架构模式,典型的事件驱动架构以下图:在这里插入图片描述
在这里插入图片描述
事件和传统的消息不一样,事件具备schema,因此能够校验event的有效性,同时EDA具有QoS保障机制,也可以对事件处理失败进行响应。事件驱动架构不只用于(微)服务解耦,还可应用于下面的场景中:

  • 加强服务韧性:因为服务间是异步集成的,也就是下游的任何处理失败甚至宕机都不会被上游感知,天然也就不会对上游带来影响;
  • cQRs(Command Query Responsibility Segregation):把对服务状态有影响的命令用事件来发起,而对服务状态没有影响的查询才使用同步调用的API接口;结合EDA中的Event Sourcing能够用于维护数据变动的一致性,当须要从新构建服务状态时,把 EDA中的事件从新“播放”一遍便可;
  • 数据变化通知:在服务架构下,每每一个服务中的数据发生变化,另外的服务会感兴趣,好比用户订单完成后,积分服务、信用服务等都须要获得事件通知并更新用户积分和信用等级;
  • 构建开放式接口:在 EDA下,事件的提供者并不用关心有哪些订阅者,不像服务调用的场景―一数据的产生者须要知道数据的消费者在哪里并调用它,所以保持了接口的开放性;
  • 事件流处理:应用于大量事件流(而非离散事件)的数据分析场景,典型应用是基于Kafka的日志处理;·基于事件触发的响应:在loT时代大量传感器产生的数据,不会像人机交互同样须要等待处理结果的返回,自然适合用EDA来构建数据处理应用。

在这里插入图片描述