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

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：空间域名、网站空间、营销软件、网站建设、天山网站维护、网站推广。

定义目标

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

1. 保持业务高稳定性

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

2. 支持快速定位故障

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

3. 支持快速恢复业务

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

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

服务分级 + 服务降级

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

这里有两个关键点：

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

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

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

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

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

建立分层监控

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

网络层

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

接口层

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

业务层

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

中间件层

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

系统层

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

“怎么做web高可用的架构设计”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联-成都网站建设公司网站，小编将为大家输出更多高质量的实用文章！

当前题目：怎么做web高可用的架构设计-创新互联
当前链接：http://ybzwz.com/article/cssjhd.html