返回顶部
首页 > 资讯 > 精选 >怎么做web高可用的架构设计
  • 266
分享到

怎么做web高可用的架构设计

2023-06-05 04:06:54 266人浏览 独家记忆
摘要

本篇内容介绍了“怎么做WEB高可用的架构设计”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!定义目标既然我们的目标是做到高可用,那么我们就有必

本篇内容介绍了“怎么做WEB高可用架构设计”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

定义目标

既然我们的目标是做到高可用,那么我们就有必要先明确清楚高可用的含义,并通过拆解目标,让目标可以被量化。按照我的理解,可以将目标按照以下三条进行拆解:

保持业务高稳定性

系统稳定性是高可用的根本目的,通俗的说,系统能持续可用,不会无故宕机,在高压下仍然能正常工作。

支持快速定位故障

从实际工程的角度看,不出故障的服务是不存在的,所以出了故障要能够快速发现和定位,在外部用户发现前,通过报警机制,能准确定位故障原因,帮助工程师尽快处理问题,防止进一步影响业务。

支持快速恢复业务

这一点需要多说两句,有关“恢复业务”和“解决问题”之间的区别,这两个词也正好说明了线上出现故障后,我们解决问题的两种不同思路。简单的说,“恢复业务”的意思是线上故障是什么原因可以先暂时放在一边,我们先找到快速的临时方案,让业务跑起来。很多同学在处理生产故障的时候有一个思维惯性:先努力找到问题的起因,然后改代码解决问题,测试,发布上线,最后业务功能才能正常工作。实际上,一个流程走下来,时间成本是很高的,业务因为本次故障受到较大的影响。比如说某台机器上的服务响应很慢,导致请求超时,可能的原因有:网络带宽出现问题、机器磁盘有问题、机器的CPU或者Memory不够用了、应用程序有死循环、JVM垃圾回收时间变长......要在短短几分钟内排查这么多可能的原因是很难的,但我们不知道真正的原因也可以恢复业务,比如说最简单的方法就是直接把这台机器立刻下线,让流量分配到其它的机器或者新添加的机器上。

现在我们有了这三条分拆后的目标,那么接下来的架构方案就会围绕着这三个目标来执行。

服务分级 + 服务降级

服务分级:根据业务的需求,将服务进行分类,划分核心服务和普通服务,核心服务与普通服务不会相互影响,服务背后的资源,缓存数据库MQ相互分离。服务分级,对应于我们的子目标1。

这里有两个关键点:

抽取核心服务,例如我们互金业务中,用户,订单,支付这三个服务是核心业务,消息推送、营销券积分等是普通服务,核心服务的稳定与否也关乎业务的KPI。核心服务是客户必须要使用的,核心服务一旦有问题,客户就不能购买产品了;而普通服务即使有问题,暂时也不会对交易产生影响。从另外一个角度看,普通服务的代码在我们日常的工作中反而变动频繁。因此,优先保证核心服务正常使用,是我们首要目标。

不同级别的服务资源分离,包括服务器, 缓存,MQ, DB等建议都分离出来,因为只要不同服务共享资源,就有可能因为普通服务影响核心服务。举个最简单的例子,如果服务间共用一套redis,那么如果大量的消息请求占用了Redis的连接数,那么核心服务的质量就会因此受到很大的影响。

服务降级:当出现故障的时候,可以将普通服务直接降级,保护核心服务不受影响。服务降级,对应于我们的子目标3。

拆分为核心服务和普通服务后,在很多业务场景下,服务间是相互调用的,这就存在服务之间可能是相互影响的。例如,我们在推送消息(普通服务)之前,需要查询用户的信息(核心服务),大量消息下发,就会给核心业务系统产生较大的压力。这种情况下我们可以通过将非核心服务停掉,以保证核心服务不受影响。

另外,在做服务降级的时候,最佳的方式,是通过修改动态配置来执行。而不是靠手工到线上修改静态配置或者发布新版本的方式来完成,因为容易出错,而且效率还不高。所以,这里我比较推荐类似阿里diamond的服务, 接入diamond后,通过diamond后台,修改配置后,groovy脚本直接就将最新的配置同步到服务中,甚至都不要重启服务就完成了降级操作。

建立分层监控

建立监控分层的目的对应于我们的子目标2,就是将故障分析和定位时涉及的所有的相关信息都要监控起来,共分为5层,具体各层和含义如下:

网络层

分析网络出入的情况,比方说有大量的外部请求,导致外网网卡的带宽被占满,需要立刻分析是否是正常流量,如果是活动带来高频访问,那么需要做带宽升级,如果是外部攻击,那么需要考虑做流量清洗等防护操作。

接口层

收集对外暴露的接口的访问情况,包括接口执行时间、返回状态码、调用次数等,我们需要时刻关注我们访问次数最多的api接口,根据接口的访问情况,决定了是否需要服务扩容,并判断是否有外部的不正常访问,机刷等。如果存在某些接口有大量的错误码返回,我们需要第一时间查明这些接口访问失败的原因。

业务层

收集和分析核心业务和普通服务的运行情况和相互调用情况,比方说,如果某个服务产生了大量的Exceptions或者dubbo服务调用超时。

中间件

中间件层指服务依赖的各类中间件,例如容器、缓存、消息队列。不同的中间件关注不一样的信息,例如数据库Redis监控指标包括连接数、请求数, rdb&aof的执行情况, IO的频率等,缓存命中率等。

系统层

系统层指操作系统状态、收集的信息包括cpu使用率、内存使用率、网卡流量、连接数等。

“怎么做web高可用的架构设计”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程网网站,小编将为大家输出更多高质量的实用文章!

--结束END--

本文标题: 怎么做web高可用的架构设计

本文链接: https://lsjlt.com/news/241300.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作