您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    效劳器又崩了?深度解析高可用架构的应战和实际
    时间:2021-08-05 12:15 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    效劳器又崩了?深度解析高可用架构的应战和实际

    大家好,我是腾讯微效劳平台TSF 产品经理刘阎,目前主要担任TSF高可用才能树立及演进规划任务,本次分享我会结合本人对微效劳架构的了解以及TSF在高可用才能树立上的最佳实际与大家共同讨论如何构建高可用的微效劳架构。

    微效劳架构应战

    软件架构的演进历程

    首先我们先来看下软件架构的演进历程:

    效劳器又崩了?深度解析高可用架构的应战和实际

    单体架构:没有复杂逻辑分层,前后代码耦合,单个运用能够与多个数据库关联

    适用于:迭代频率低,并发量小,业务逻辑复杂的运用场景,目前单体架构在政府、金融、工业范围仍有普遍运用。

    SOA架构:按业务逻辑停止效劳拆分,效劳间经过效劳总线停止效劳管理及流量转发

    其主要成绩在于:效劳总线成为系统新的瓶颈,难以伴随业务的不断开展满足线性扩容的要求。

    微效劳架构:效劳架构经过效劳注册中心完成效劳注册发现,效劳启动时将效劳虚例注册到注册中心,调用方在发起调用时经过注册中心停止效劳寻址,直接与提供方停止通讯。实际上效劳可以伴随业务开展完成线性扩展,不同效劳之间可独自迭代,完成矫捷开发。

    效劳网格:版本云原生k8s及容器技术开展,效劳网格技术已趋于成熟,相较于传统的微效劳架构,效劳网格经过sidercar形式停止流量代理和效劳注册发现,无需业务感知,轻松完成跨言语效劳管理,协助业务快速迁移,使业务运用愈加专注本身业务逻辑完成。

    每种软件架构没有严厉意义上的好坏之分,用户需求依据本身的业务特点停止架构选型。

    微效劳运用常见成绩

    微效劳架构在满足高并发、矫捷迭代的同时,业务模块数量成几何数增长,给运用运维带来了严峻应战,微效劳架构相较于传统单体架构,具有流量洪峰激增、模块依赖复杂、缺点定位难度大、缺点恢复耗时长的特点。

    流量激增:单体运用拆分为微效劳运用后,原有的单一央求逻辑拆分为多个微效劳运用的组合业务逻辑,接口调用量成1:N的增长关系,面对流量洪峰,接口调用量激增。

    模块依赖复杂:原有的单体运用仅存在单一进程内的业务逻辑组合,微效劳运用拆分为多个进程,各模块间的效劳上下游依赖关系复杂,单个微效劳或单个接口异常通常引发链式反响,形成效劳雪崩。

    缺点定位难度大:单次央求异常需求依据各模块的依赖关系剖析整个调用链路定位缺点缘由,由于横跨多个微效劳运用进程的不同业务逻辑,缺点定位难度陡增。

    缺点恢复耗时长:由于各微效劳模块依赖关系复杂,需求依据调用链准确定位缺点成绩本源并停止逐级恢复,缺点恢复及恢复后验证评价结果耗时长。

    如何度量系统可用性目的

    管理学巨匠彼得德鲁克曾说“你假设无法度量它,就无法管理它”(“It you can’t measure it, you can’t manage it”)。要想有效管理,就难以绕开度量的成绩。

    那如何度量散布式系统的可用性目的呢,这里有一个复杂公式,可用性=平均缺点距离时间/平均缺点距离时间与平均缺点恢复时间之和。

    效劳器又崩了?深度解析高可用架构的应战和实际

    所谓平均缺点距离时间是指相邻两次缺点之间的平均任务时间,也称为平均缺点距离。平均修复时间是从出现缺点到修复中间的这段时间。MTTR 越短表示易恢复性越好。

    MTBF:即平均缺点距离时间,英文全称是“Mean Time Between Failure”。是权衡一个产品(尤其是电器产品)的牢靠性目的。单位为“小时”。

    MTTR:全称是 Mean Time To Repair,即平均修复时间。是指可修复产品的平均修复时间,就是从出现缺点到修复中间的这段时间。MTTR 越短表示易恢复性越好。

    高可用架构设计的道、法、术

    那如何设计高可用的微效劳架构呢?接上去我将辨别从道、法、术三个层面讲高可用微效劳架构设计的基本原理、架构设计准绳、以及高可用架构常用的处置办法。

    道:从CAP到BASE

    CAP 实际:在一个散布式系统中, 分歧性(C:Consistency)、可用性(A:Availability) 和 分区容忍性(P:Partition Tolerance),最多只能同时满足其中两项。其中分区容忍性(P:Partition Tolerance)是复杂网络环境下的必需要素,因此散布式系统的架构设计需求在分歧性和可用性之间停止取舍。就降生了诸如:Paxos 算法 和 Raft 算法强分歧性共识算法,以及2阶段提交,3阶段提交的最终分歧性算法。

    BASE 实际:BASE是对 CAP 中分歧性和可用性权衡的结果,它的实际的中心思想是:即使无法做到强分歧性,但每个运用都可以依据本身业务特点,采用适当的方式来使系统到达最终分歧性。

    法:微效劳高可用架构设计准绳

    结合我对微效劳高可用架构的了解,总结出以下6点高可用架构设计的准绳,辨别是效劳有形状、异步解耦、分区容错、缺点隔离、快速恢复、最终分歧性:

    效劳有形状:效劳运用停止有形状设计,将效劳运用的形状数据经过缓存、数据库停止集中存储,经过nginx或网关停止负载平衡完成水平扩展。

    异步解耦:各效劳模块经过发布订阅、事情驱动方式停止异步解耦,单次央求调用经过异步回调方式快速照应,将通知事情与处置结果别离,避免异常雪崩。

    分区容错:基于指定的业务规则完成业务分流路由,将流量分发至少个可用区,不同可用区经过数据同步、多备份机制保障数据分歧性。

    缺点隔离:单一进程、单一接口、单一效劳经过熔断、升级机制完成缺点隔离,避免系统关联异常,引发雪崩效应。

    快速恢复:经过流量切分,版本管理、运用回滚机制完成运用快速回退至安康版本,快速恢复运用。

    最终分歧性:经过少数据源双写、数据稽核、数据修复完成数据跨可用区数据最终分歧性。

    术:高可用常用手腕

    分区容错:

    (责任编辑:admin)