点击上方“服务端思维”,选择“设为星标”

回复”669“获取独家整理的精选资料集

回复”加群“加入全国服务端高端社群「后端圈」

作者 | 刘阎

出品 | 腾讯云中间件

导读

本文是腾讯云微服务平台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或网关进行负载均衡实现水平扩展。

异步解耦:各服务模块通过发布订阅、事件驱动方式进行异步解耦,单次请求调用通过异步回调方式快速响应,将通知事件与处理结果分离,避免异常雪崩。

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

故障隔离:单一进程、单一接口、单一服务通过熔断、降级机制实现故障隔离,避免系统关联异常,引发雪崩效应。

快速恢复:通过流量切分,版本管理、应用回滚机制实现应用快速回退至健康版本,快速恢复应用。

最终一致性:通过多数据源双写、数据稽核、数据修复实现数据跨可用区数据最终一致性。

术:高可用常用手段

分区容错:

异地容灾是高可用架构典型的应用场景,通过将不同地域的数据中心构建多套应用服务,当单一地域服务宕机时可快速通过流量切换灾备中心保障业务持续、稳定。异地容灾按保障级别不同分为,多可用区、同城冷备、同城双活、异地冷备、两地三中心五个级别,其保障级别、应用成本、恢复延迟都呈递增趋势。

异步解耦:

在微服务应用中通过引入消息中间件将上游组合服务对下游多个微服务的同步调用进行异步解耦,基于消息的可靠投递能力快速响应用户请求,能够大幅提升服务并发访问性能及用户体验,并通过数据补偿手段保障数据最终一致性。

服务限流:

由于 API 接口无法控制调用方的行为,因此当遇到瞬时请求量激增时,会导致接口占用过多服务器资源,使得其他请求响应速度降低或是超时,严重导致服务器宕机。服务限流主要是保护服务节点或者数据节点,防止瞬时流量过大造成服务和数据崩溃,导致服务不可用。

  • 局部限流:基于简单计数、令牌桶、漏斗算法在单个节点内的限流,仅能限制传入此节点的请求,无需引入中间件,通过局部限流达到全局限流的目的,同时避免实例级别单一接口访问量激增问题

  • 全局限流:基于简单计数、令牌桶算法,通过引入中间件如redis,针对整个集群流量进行全局控制。

服务熔断:

服务熔断是应对服务异常,实现服务容错,避免服务雪崩的有效手段。

从下图中可以看出,当网关入口服务请求下游多个服务接口,当服务C接口异常将导致入口服务流量的不可用,服务A、服务E请求则白白占用。

从下图中可以看出,当网关入口的服务请求下游的单一服务接口,当服务B接口异常将导致入口请求夯住,占用网关请求资源,导致整体业务异常。

针对以上两种异常场景,通过在服务调用时配置熔断策略能够快速失败,直接反馈上游业务异常结果,避免请求线程夯死及服务雪崩。

降级容错:

服务降级是在服务器压力陡增的情况下,利用有限资源,根据当前业务情况,关闭某些服务接口或者页面,以此释放服务器资源以保证核心服务的正常运行。

TSF高可用最佳实践

TSF微服务平台针对业务流量激增、服务异常容错等问题提供架构容灾、灰度发布、服务容错兜底、实例优雅启停、应用性能管理的一体化高可用服务架构。突出立体化自动化可视化的优势,提供端到端的应用性能监控,多维度可视化的运行监控数据聚合分析,实现故障自动感知,自动处理,快速恢复故障业务,保障系统的稳定高效运行。

单元化架构部署

单元化架构是一种高级的高可用架构设计模式,通过对核心业务数据分片,应用服务无状态设计将相同领域的业务服务划分为一个个独立的部署单元,单元内整体业务闭环。通过单元化部署架构能够有效满足弹性伸缩故障隔离异地容灾等高可用建设要求。此外基于单元化部署可以实现以部署单元为基准,构建灵活的发布策略。

单元化架构产品能力:

  • 网关业务单元路由标签

  • 支持跨单元横向调用

  • 单元内服务容错兜底

弹性伸缩

通过配置动态伸缩规则,TSF中控服务基于agent上报的监控数据实现实时统计,满足流量激增自动扩容或流量低峰自动缩容能力,有效保障服务高效稳定资源利用率提升

全链路灰度发布

灰度发布是将具有一定特征或者比例的流量分配到需要被验证的版本中,用来观察新的验证版本的线上运行状态。相比全量上线,灰度发布是更加谨慎的发布形式。当线上调用链路较为复杂时,全链路灰度发布可以将线上的各个服务隔离出一个单独的运行环境。

全链路灰度产品能力:

  • 基于业务级别的全链路灰度发布能力

  • 支持按照业务级别请求参数对流量进行划拨

  • 泳道间流量隔离

优雅启停

在应用滚动发布过程中,可以通过调整部署组滚动发布更新策略达到服务优雅下线,降低发布过程中业务中断影响。

这里简单介绍优雅下线的简单流程

  1. 下线实例在注册中心进行反注册,注销该实例注册信息;

  2. 注册中心节点订阅更新周期为15s,调用方在感知注册中心实例变更后,更新本地缓存服务地址,不再将流量路由到下线实例,期间保障业务无中断;

  3. 下线实例等待30s(2个心跳周期)后进行实际下线操作;

优雅启停产品能力:

  • 支持容器、虚机部署方式

  • 实例反注册下线事件详情

  • 实例启动就绪检测

服务限流

TSF 限流基于监控服务流量的 QPS 指标,当达到指定的阈值时进行流量控制,避免被瞬时高峰流量冲垮,从而确保服务的高可用。支持在网关配置全局限流策略保障入口服务流量稳定支持针对单一服务配置局部限流策略保障当前服务流量稳定,同时提供灵活的限流规则配置及动态生效,提供可视化的限流操作及监控数据展示。

服务熔断

TSF服务熔断能力支持服务、实例、API多维度的熔断隔离级别,提供控制台可视化配置及熔断事件展示,满足熔断配置热生效需求。

熔断器状态转换:

  • 熔断器开始处于closed状态,一旦检测到错误(或慢响应)达到一定阈值,便转为open状态,此时不再调用下游目标服务。

  • 一段时间后转化为half open状态,尝试放行一部分请求到下游服务。

  • 一旦检测到响应成功,回归到closed状态,也即恢复服务;否则回到open状态。

健康检查与注册中心联动流程

健康检查分为存活检查就绪检查;存活检查主要作用是确定进程存活状态,判断是否需要进行实例重启。就绪检查主要作用是确定服务实例能否支持对外服务,将健康检查结果与注册中心状态联动避免流量接入异常节点。

健康检查与注册中心联动流程

1.就绪检查,检查实例状态是否ready

2.如果就绪检查ready则更新实例注册状态为passing,反之则检查状态为cirtical

3.监听注册中心服务提供方实例状态变更

4.存在状态变更更新缓存及本地文件

5.发起服务调用

健康检查产品能力:

  • 存活检查

  • 就绪检查

  • 多种探测方式:http,tcp,执行命令

  • 支持虚机&容器部署

应用性能管理能力

最后我们从一个问题排查流程全局展示tsf应用性能管理能力:

  1. 用户收到监控平台发送的告警信息,确定异常基本信息。

  2. 通过服务依赖拓扑确定异常服务的上下游依赖关系,进行全局视图分析。

  3. 接下来可以服务接口调用情况确定是全局接口异常或是单一接口异常。

  4. 如果是全局接口异常说明服务提供方服务实例存在异常问题,找到对应的异常实例通过日志检索或JVM监控分析排查具体问题;如果是单一接口异常说明提供方接口逻辑处理,通过日志检索可排查具体问题。

  5. 当然也可以在全局视图分析后通过对直接服务进行调用链分析排查单笔请求的调用链路,通过调用链与日志联动排查具体异常。

以上是本次TSF高可用结构设计及核心技术原理的全部分享。

— 本文结束 —

● 漫谈设计模式在 Spring 框架中的良好实践

● 颠覆微服务认知:深入思考微服务的七个主流观点

● 人人都是 API 设计者

● 一文讲透微服务下如何保证事务的一致性

● 要黑盒测试微服务内部服务间调用,我该如何实现?

关注我,回复 「加群」 加入各种主题讨论群。

对「服务端思维」有期待,请在文末点个在看

喜欢这篇文章,欢迎转发、分享朋友圈

在看点这里

服务器又崩了?深度解析高可用架构的挑战和实践相关推荐

  1. 面向业务的立体化高可用架构设计

    通常情况下我们在谈论高可用架构设计的时候,主要关注的是系统结构的高可用,例如主备架构.集群架构.多中心架构.我们做架构设计的时候,也主要是从系统结构本身出发,例如我们把单机改为双机.双机改为集群.单机 ...

  2. 聚焦上海:千锤百炼出神器,高可用架构实战案例

    随着移动互联网.云计算和大数据的高速发展,科技创新企业的扩张速度也呈指数级增长,越来越多产品和服务从 idea 到落地,只需要几个月甚至几天的时间.但伴随服务化的深入,数据量急剧增加,高并发高扩展高性 ...

  3. Memcached主从复制+keepalived高可用架构

    实现主从复制和高可用的方式 Memcached主从复制是指在主Mencached服务器上修改数据都会被同步到其他服务器上,MemcachedAPI客户端是无法判断连接到那一台Memcached服务器, ...

  4. VIPKID 的高可用架构设计及 TiDB 应用实践

    原文来源: https://tidb.net/blog/6171efe3 作者:郝海民,许超.本文系 2019 年 11 月北京 TUG 线下活动" 高可用架构设计与实践 "分享实 ...

  5. 网站停服、秒杀大促…解析高可用网站架构云化

    摘要:高可用架构的主要手段,是数据和服务的冗余备份及失效转移. 本文分享自华为云社区<高可用网站架构云化解决方案解析>,作者:琴棋书画-Linda. 一.背景 早期互联网产品用户量少,并发 ...

  6. ES+Redis+MySQL,高可用架构设计太牛了!(至尊典藏版)

    目录 前言 一.ES 高可用方案 1.1.ES 双中心主备集群架构 1.2.ES 流量隔离三集群架构 1.3.ES 集群深度优化提升 二.会员 Redis 缓存方案 2.1. ES 近一秒延时导致的 ...

  7. 高并发、高性能下的 会员系统[同程艺龙] — 高可用架构设计实践

    目录 会员系统[同程艺龙] - 高可用架构设计实践 ES高可用方案 ES双中心主备集群架构 ES流量隔离三集群架构 ES集群深度优化提升 会员Redis缓存方案 Redis双中心多集群架构 高可用会员 ...

  8. 可用性高达5个9!支付系统高可用架构设计实战

    可用性高达5个9!支付系统高可用架构设计实战 一.背景 对于互联网应用和企业大型应用而言,多数都尽可能地要求做到7*24小时不间断运行,而要做到完全不间断运行可以说"难于上青天". ...

  9. 《MySQL性能优化和高可用架构实践》简介与推荐序

    #好书推荐##好书奇遇季#<MySQL性能优化和高可用架构实践>,京东当当天猫都有发售.腾讯云架构师宋立桓倾情奉献,定价59元,网店打折销售其实没多少钱. 互联网公司里面几乎很少有公司不用 ...

最新文章

  1. 关于Java 垃圾收集器你应该知道这些
  2. 磁盘调度算法java代码
  3. centOS安装java
  4. vue学习- 列表渲染v-for
  5. 如何使用Nikto漏洞扫描工具检测网站安全
  6. 程序猿误区:程序员只负责编码
  7. 禁用安全模式(2k,2k3,xp)
  8. 主流的分布式事务解决框架
  9. 解决zookeeper启动失败Could not find or load main class org.apache.zookeeper.server.quorum.QuorumPeerMain报错
  10. 怎么在html使用百度商桥,电脑版网站如何添加爱番番(原:百度商桥)
  11. 删除排除链表中的重复元素
  12. Java 8 中的 Map 骚操作,学习下
  13. 软件项目管理知识点总结
  14. 2811路由器系统导入到服务器,配置CISCO2811路由器的E1连接
  15. convertTo的用法
  16. html页面乱码解决
  17. 其实 Gradle Transform 就是个纸老虎 —— Gradle 系列(4)
  18. CSS学习笔记 01、CSS3基础知识学习
  19. 我的世界服务器修改武器伤害,我的世界:8张特性图,武器伤害没上限,物品全靠刷,老mc秒懂!...
  20. 如何写出一篇好的技术方案?

热门文章

  1. 腾讯云服务器 有mysql吗_腾讯云服务器、数据库购买攻略
  2. 米扑科技:草根连续创业的前赴后继者
  3. 【干货】微信私域运营打法和案例拆解(附78页pdf下载链接)
  4. 导航栏加载时可能出现闪的原因以及解决办法
  5. android vivo手机 更换应用图标后没生效
  6. 前沿聚焦:2022最受关注的六大技术热词,你都知道吗?
  7. 资深工程师 VSCode C/C++ 必备开发插件
  8. 锂电池正常分容测试温度的软件,实现节能环保,锂电池化成分容测试方案不可少...
  9. 诺基亚x6升级android9体验,诺基亚X6迎来安卓9 Pie测试版更新:这几个功能值得体验...
  10. 成功解决git clone提示fatal: repository ‘xxx.git/‘ not found