高可用系统在点评的实践与经验--讲座思考

Posted 2020-06-29 绯浅yousa

SDCC 2016架构峰会纪要（三）

关键词：深度、干货、大牛、火爆、一线、图书

题目	主讲人	主讲人个人简介
支付宝红包稳定性实践与思考	王 俊	蚂蚁金服支付清算平台架构师
宅米网技术架构变迁与实践	李智慧	宅米CTO
携程下一代无线App架构设计	陈浩然	携程旅行网无线开发总监
新型架构实践与应用	孙子荀	腾讯手Q公众号后台负责人
从概率和用户感知出发实现高可用架构	史海峰	当当网架构部总监
高可用系统在点评的实践与经验	陈一方	大众点评交易平台技术团队负责人
微服务架构设计与实践	黄 勇	特赞CTO
大型电商网站中的通用精准化推荐平台的搭建	陈 兀	1号店担任推荐团队架构负责人
从0到1，手腕上的人工智能	范超霏	出门问问高级系统架构师

前面两篇主要是详细介绍具体业务场景的架构思路，现在介绍一下通用的互联网公司架构演进流程

高可用系统在点评的实践与经验–大众点评交易平台技术团队负责人陈一方

陈一方指出，高可用的架构很容易找到方案，但其中主要挑战是演进的节奏很难把握。以点评的交易系统的演进为主来描述如何做到高可用，并结合自己的经验作些分享。高可用性只是一个结果，要更多的关注迭代过程，关注业务发展。

他分别以大众点评交易平台幼儿时期、少年时期、青年时期、成年时期以及未来演进目标这五个不同时期为例，深度点评交易系统演进过程。

他主要从下面几个方面来分享

1. 可用性的理解：（什么是高可用？如何保障？）
2. 高可用秘诀一：频率要低（高可用性的设计，易运营&测试等）
3. 高可用秘诀二：时间要快（持续关注运行时，充分利用故障时）
4. 团队及个人经验教训

一、可用性理解

高可用他们这里强调的是3个9到5个9的目标，这里不作赘述

对于这种目标，他们拆分成如何实现该目标：

1.频率要低：减少出故障的次数

不出问题，一定是高可用的，但这是不可能的。系统越大、越复杂，只能尽量避免问题，通过系统设计，流程机制来减少这种问题概率。但如果经常出问题，后面的恢复再快也是没有用的。

2.时间要快：故障恢复时间要快

故障出现时，不是解决或者定位到具体问题，而是快速恢复是第一要务的，防止次生灾害，问题扩大。这里就要求要站在业务角度思考，而不仅是技术角度思考。

二、频率要低

高可用设计

0.整体设计（架构演进节奏）

整体上来说是需要结合业务场景需求以及自己相应业务流量规模来决定架构演进节奏，既不能太快（开发成本高、运维成本高、无法快速使用），也不能太慢（体验差，被淘汰）

譬如大众点评交易平台现在系统演进流程为：一个系统->模块化->垂直服务->服务平台化

下面通过大众点评交易平台演进过程来介绍这演进流程

1.幼儿时期

流量规模小，日万级订单

主要目标：能够在满足业务需求的前提下快速上线

满足业务要求是第一的，还没有机会遇到可用性等质量问题。考虑比较简单，要挂都挂了，量也比较小，出现问题，重启，扩容，回滚就解决问题了。

2.少年时期

上线之后，为了提升研发效率以及能够对故障进行隔离，开始对业务进行垂直拆分

业务流量，日十万级

将各个业务相互隔离，比如商品首页的展示，商品详情页的展示，订单、支付流程的稳定性要求不一样。前面可以缓存，可以做静态化来保证可用性，提供一些柔性体验；后面支付系统做异地容灾。基本该图就是所谓的服务垂直化，但业务数据没有完整隔离开，会导致不同服务会互相影响。

注：Deal是指商品系统、Order是指订单系统、Pay是指交易系统

3.青年时期

简单来说就是由于上一阶段不同业务直接数据会互相影响，故该阶段主要工作是做小服务、使之不共享数据，能够支持业务快速增加。大概日订单量可以达到百万级

从2013年开始，deal－service （商品系统）偶尔会因为某一次大流量（大促，常规活动）会挂，每几个月总有那么一次。基本上可用性就在3个9徘徊，这里订单和支付系统很稳定的，因为流量在商品详情页到订单有一个转化率，流量大了详情页就挂了，订单也就没有流量了，后来做了详情的静态化做得比较好了，能减少恢复的速度，能降级，但是deal-service的各个系统依赖太深了，还是不能保证整体端到端的可用性。

所以2014年deal-service就做了很大的重构，大系统做小，把商品详情系统拆成了无数小服务，比如库存服务，价格服务，基础数据服务等等。这下商品详情页的问题解决了，所以从2014年低订单系统的压力就来了，前面好了，后面压力就来了。2014年10月起，订单系统，支付系统也启动了全面微服务化，经过大约1年的实践，订单系统、促销系统、支付系统这3个领域后面的服务总和都快上百个了，后面对应的数据库20多个，这样能支撑到每日订单量百万级。

业务的增长在应用服务层面是可以扩容的，但是最大的单点，数据库是集中式的，这个阶段我们主要是把应用的数据访问在读写上分离，数据库提供更多的从库解决读的问题，但是写入仍然式最大的瓶颈（mysql的读可以扩展，写入QPS 也就小2万）

该架构大约能支撑QPS 3000左右的订单量。

4.成年时期

为支撑大规模促销活动，目标是每秒几万的QPS，日千万级订单量。需要对架构进行继续改进，他们这里是拿大众点评9.17吃货节促销该活动来说明

第一个遇到的问题便是数据（库）单点问题

对订单系统进行了架构升级，水平拆分，核心就是解决数据单点，把订单表拆分成了1024张表，分布在32个数据库，每个库32张表。

虽然数据层的问题解决了，但是他们还是有些单点问题，譬如MQ，网络，机房等。这里他举了准备9.17促销所遇到的问题：

1. 服务的网卡有一个网卡坏了，没有被监测到，后来另外一个网卡也坏了，服务就挂掉。（服务器双网卡是标配）
2. 使用 cache的时候发现性能在高峰期非常低，后来发现这个cache缓存服务器跟公司监控系统日志服务器在一个机柜，高峰期的流量被占去很多，给业务的网络流量就非常少，就影响了cache缓存服务器业务。
3. 917大促的时候，对MQ这个依赖的通道能力评估出现了偏差，也没有备份方案，所以造成了一小部分的延迟。（由于低流量场景跟高流量场景不同部分压力不同）

Q:流量再涨10倍怎么办？

思路仍然是大系统做小，基础通道做大，流量分块。

易运营

这里的运营不是产品运营，而是指线上质量，譬如整个系统上线后，是否方便切换流量，是否方便开关，是否方便扩展。系统运营的几个基本要求：

1. 限流。1秒50kpps跟5秒10kpps难度不一样
2. 无状态。
3. 降级能力。这里主要围绕的是跟产品体验密切相关

这里降级能力他用支付来举例子。系统会结合产品对支付渠道成功率进行统计，如果成功率低于75%就会提示不稳定，如果成功率低于50%就会自动关闭该通道。

易测试

这里他主要强调了两点：

1. 高峰流量模型与正常流量模型可能会不一致
2. 测试很重要

重视发布

两把利器：灰度发布、快速回滚……

三、速度要快

这里听下来，感觉就是：一，系统监控、预警能力好，如果有问题，能够立即跟运维告警，让其解决；二、运维要好，熟悉解决场景；三、系统容错能力强，小bug能够自己行解决

几点经验

1. 珍惜每次真实高峰流量，建立高峰期流量模型。
2. 珍惜每次线上故障复盘，上一层楼看问题，下一楼解决问题。
3. 可用性不只是技术问题 。系统初期是：以开发为主；系统中期是：开发＋DBA＋运维为主；系统后期是：技术＋产品＋运维＋DBA ；
4. 单点和发布是可用性最大的敌人