电商平台备战促销季的运维秘诀——高可用服务层

高可用设计是互联网系统架构的基础之一，以天猫双十二交易数据为例，支付宝峰值支付次数超过 8 万笔。你们设想一下，若是这个时候系统出现不可用的状况，那后果将不可想象。
而解决这个问题的根本就是服务层的高可用。

什么是服务层

众所周知，服务层主要用来处理网站业务逻辑的，是大型业务网站的核心。好比下面三个业务系统就是典型的服务层，提供基础服务功能的聚合

• 用户中心：主要负责用户注册、登陆、获取用户用户信息功能
• 交易中心：主要包括正向订单生成、逆向订单、查询、金额计算等功能
• 支付中心：主要包括订单支付、收银台、对帐等功能

总体架构

业务发展初期主要以业务为导向，通常采用 「ALL IN ONE」的架构方式来开发产品，这个阶段用一句话归纳就是 「糙猛快」。当发展起来以后就会遇到下面这些问题

• 文件大：一个代码文件出现超过 2000 行以上
• 耦合性严重：不相关业务都直接堆积在 Serivce 层中
• 维护代价高：人员离职后，根本没有人了解里面的业务逻辑
• 牵一发动全身：改动少许业务逻辑，须要从新把全部依赖包打包并发布

遇到这些问题，主要仍是经过「拆」来解决

具体拆的方式，主要根据业务领域划分单元，进行垂直拆分。拆分开来的好处很明显，主要有如下这些：

• 每一个业务一个独立的业务模块
• 业务间彻底解耦
• 业务间互不影响
• 业务模块独立
• 单独开发、上线、运维
• 效率高

无状态设计

对于业务逻辑服务层，通常会设计成无状态化的服务，无状态化也就是服务模块只处理业务逻辑，而无需关心业务请求的上下文信息。因此无状态化的服务器之间是相互平等且独立的。

只有服务变为无状态的时候，故障转移才会变的很轻松。一般故障转移就是在某一个应用服务器不能服务用户请求的时候，经过负责均衡的方式，转移用户请求到其余应用服务器上来进行业务逻辑处理

超时设置

通常网站服务都会有主调服务和被调服务之分。超时设置就是主调服务在调用被调服务的时候，设置一个超时等待时间 Timeout。主调服务发现超时后，就进入超时处理流程。

1. 主调服务 A 调用被调服务 B 时，设置超时等待时间为 3 秒，可能因为 B 服务宕机、网络状况很差或程序 BUG 之类，致使 B 服务不能及时响应 A 服务的调用。
2. 此时 A 服务在等待 3 秒后，将触发超时逻辑而再也不关心 B 服务的回复状况。
3. A 服务的超时逻辑能够依据状况而定，好比能够采起重试，对另外一个对等的 B 服务去请求，或直接放弃结束这个请求调用。

超时设置的好处在于当某个服务不可用时，不至于整个系统发生雪崩反应。

异步调用

通常请求调用分为同步与异步两种。同步请求就像打电话，须要实时响应，而异步请求就像发送邮件同样，不须要立刻回复。

这两种调用各有优劣，主要看面对哪一种业务场景。好比在面对并发性能要求比较高的场景，异步调用就比同步调用有比较大的优点，这就比如一我的不能同时打多个电话，可是能够发送不少邮件。

那咱们何时该采用异步调用？

其实主要看业务场景，若是业务容许延迟处理，那就采用异步的方式处理

那咱们该怎么实现异步调用呢？

一般采用队列的方式来实现业务上的延迟处理，好比像订单中心调用配送中心，这种场景下面，业务是能接受延迟处理的。

那消息队列主要有哪些功能呢？

• 异步处理 - 增长吞吐量
• 削峰填谷 - 提升系统稳定性
• 系统解耦 - 业务边界隔离
• 数据同步 - 最终一致性保证

那到底有多少种队列呢？其实主要看处理业务的范围大小

• 应用内部 - 采用线程池，好比 Java ThreadPool 中 BlockingQueue 来作任务级别的缓冲与处理
• 应用外部 - 好比 RabbitMQ 、ActiveMQ 就是作应用级别的队列，方便进行业务边界隔离与提升吞吐量

同时，技术上来说，消息队列通常分为两种模型：Pull VS Push

• Pull 模型：消费者主动请求消息队列，获取队列中的消息。
• Push 模型：消息队列主动推送消息到消费者

其中 Pull 模式能够控制消费速度，没必要担忧本身处理不了消息，只须要维护队列中偏移量 Offset。因此对于消费量有限而且推送到队列的生产者不均匀的状况下，采用 Pull 模式比较合适。

Push 比较适合实时性要求比较高的状况，只要生产者消息发送到消息队列中，队列就会主动 Push 消息到消费者，不过这种模式对消费者的能力要求就提升不少，若是出现队列给消费者推送一些不能处理的消息，消费者出现 Exception 状况下，就会再次入队列，形成消费堵塞的状况。

不过互联网业界比较成熟的队列主要以采用 Pull 模式为主，像 Kafka、RabbitMQ（两种方式都支持）、RocketMQ 等

幂等

什么是幂等设计呢？

其实很简单，就是一次请求和多个请求的做用是同样的。用数学上的术语，便是 f(x) = f(f(x))。

那咱们为何要作幂等性的设计呢？主要是由于如今的系统都是采用分布式的方式设计系统，在分布式系统中调用通常分为 3 个状态：成功、失败、超时。

若是调用是成功或者失败都没关系，由于状态是明确和清晰，可是若是出现超时的状况，就不知道请求是成功仍是失败的。

若是出现这种状况，咱们该怎么办呢？通常采起重试的操做，从新请求对应接口。若是请求接口是 Get 操做的话，那到还好，由于请求屡次的效果是同样的。可是若是是 Post 、Put 操做的话，就会形成数据不一致，甚至数据覆盖等问题。

举个例子：在支付收银台页面进行支付的时候，由于网络超时的问题致使支付失败，这个时候咱们都会再进行一次支付操做，可是当支付成功后，发现你的帐户余额被减了 2 次，这个时候内心确定很不爽，内心都要开始骂娘了...

形成这个问题的关键是：网络超时后，不知道支付是什么状态？成功仍是失败呢？因此说幂等性设计是必须的，尤为在电商、金融、银行等对数据要求比较高的行业中。

通常在这种场景下咱们该怎么解决呢？

1. 请求方通常会生产一个惟一性 ID 标识，这个标识能够具备业务同样，好比订单号或者支付流水号，在发起请求时候带上惟一性 ID。
2. 接收者在收到请求后，第一步经过获取惟一性 ID 来查询接收端是否有对应的记录，若是有的话，就直接将上次请求的结果返回，若是没有的话，就进行操做，并在操做完成后记录到对应的表里

服务降级

服务降级主要解决资源不足和访问量过大的问题，好比电商平台在双11、618 等高峰时候采用部分服务不提供访问，减小对系统的影响。

那降级的方式有哪些呢？

• 延迟服务：好比春晚，微信发红包就出现抢到红包，可是帐号余额并无增长，要过几天才能加上去。其实这是微信内部采用延迟服务的方式来保证服务的稳定，经过队列实现记录流水帐单
• 功能降级：中止不重要的功能是很是有用的方式，把相对不重要的功能暂停掉，让系统释放更多的资源。好比关闭相关文章的推荐、用户的评论功能等等，等高峰过去以后，在把服务恢复回来。
• 下降数据一致性：在大促的时候，咱们发现页面上不显示真实库存的数据，只显示到底有仍是没有库存这两种状态。

刚刚说了降级的方式，那咱们操做降级的时候有哪些注意点呢？

1. 清晰定义降级级别： 好比出现吞吐量超过 X，单位时间内响应时间超过 Y 秒、失败次数超过 Z 次等，这些阈值须要在准备的时候，经过压测的方式来肯定。
2. 梳理业务级别：降级以前，首先须要肯定哪些业务是必须有，哪些业务是能够有的，哪些业务是无关紧要的。
3. 降级开关：能够经过接入配置中心（好比携程 Apollo、百度 Disconf ）的方式直接后台降级。可是若是公司没有配置中心的话，能够封装一个 API 接口来切分，不过该 API 接口要作成幂等的方式，同时须要作一些简单的签名，来保证其必定的安全性。

总结

总结一下今天分享的主要内容

• 总体架构：根据业务属性进行垂直拆分，减小项目依赖，单独开发、上线、运维
• 无状态设计：应用服务中不能保存用户状态数据，若是有状态就会出现难以扩容、单点等问题
• 超时设置：当某个服务不可用时，不至于整个系统发生连锁反应
• 异步调用：同步调用改为异步调用，解决远程调用故障或调用超时对系统的影响
• 服务降级：牺牲非核心业务，保证核心业务的高可用

全部好的架构设计首要的原则并非追求先进，而是合理性，要与公司的业务规模和发展趋势相匹配，任何一个公司，哪怕是如今看来规模很是大的公司，好比 BAT 之类，在一开始，其系统架构也应简单和清晰的。

但随着业务范围不断扩充，业务规模不断扩大，系统渐进复杂和庞大，让全部系统都遇到高可用的问题。那咱们该如何避免相似的问题，构建高可用系统呢？

为此我特地写了一个专栏《带你玩转高可用》，将多年来在百度和沪江的架构设计实战经验，集结成这个专栏。

本专栏总共包含 15 篇文章，分红三大模块详细解释高可用架构的相关知识：

• 概念篇：介绍高可用架构理论与演进，这块比较偏理论。不过对于咱们理解整套体系仍是有必须的。
• 工程篇：介绍常见互联网分层中每一层高可用是怎么作的，包含 DNS、服务层、缓存层、数据层等
• 问题篇：介绍怎么排查线上经常使用的故障，包括机器、应用层等维度故障定位

专栏每周都会更新，持续 64 天。在这将近 2 个月内，我会带着你们去全面了解高可用架构的方方面面，同时会将遇到的这些问题和对应的解决方案抛出来，但愿你们不要重复我遇到过的坑。同时也期待你们提出有意思的问题。

专栏地址：带你玩转高可用