讲个‘理论型’高可用架构的故事给你听

怎么访问不了了？

我看看……主节点挂了，我重启下

咦？没切换吗？不是 M/S 的吗？

我查查……没切过去，不应该啊！有可能是网络不稳定吧

咦？你们之前没测过吗？

我想想……测过啊，之前的性能测试报告你不也参与评审了吗？

我说的是系统分布式架构高可用场景测试……

以上对话，摘录自某次 P1 级事故现场，开发同学与运维同学之间的谈话，始作俑者是我们自研的分布是缓存服务，采用的技术方案是官方推荐的“Redis 1M/2S + Sentinel”（具体方案可参考「路遥知马力，聊聊好买财富的分布式缓存中间件」），当 M 挂了的时候能够实现 S 切换，最终达到高可用的效果

perfect！无论……那为什么……好吧，既然是讲故事，那咱还的从头说起

为什么会有“理论型”高可用架构这么一说？

何为 “理论型” ？纸上谈兵，没有数据信息与经验支持。

无论是应用系统还是中间件，在上线之前多少都做过测试，为什么还会跟 “理论型” 扯上关系呢？

通常在收集数据信息与经验累计的过程中，会产生如下误区：

• 误区 1：非功能性测试 = 性能测试

• 误区 2：官方方案 = 靠谱方案

• 误区 3：高可用场景跑通了 = 满足高可用了（如 M/S，网线拔掉 或 关掉服务器，切换了，OK 啦）

当然，以上这 3 点都有较多的客观因素所参杂，比如环境、时间、成本、时间及测试场景覆盖等，但从事实导向的视角来看，“理论型”高可用架构是实际存在的

为什么 ‘IOE’ 时代发生类似事件较少？

众所周知，从事金融行业的小伙伴都了解 “金色两点半” 一说，在这半小时内一旦系统闹腾起来，最有力的解释要数 “RP 值不够” 。

这里借用下这个词，我的 RP 值过了及格线，以下内容也是从及格线视角出发陈述的：

• 节奏较慢

• 这里说的节奏，应该被理解为业务发展时代导致的技术发展节奏较慢，连项目管理都是大瀑布式，还能快到哪去？

• 环境稳定

• 环境：指的是基础架构环境，无论是 UNIX 还是 Oracle，某些时候都成了甲方风 险转移的代名词

稳定：这个词有点夸大其词，不过总体上讲，IOE 时代的各种产品（或中间件）还是相当稳定的，不像现在的开源中间件，今天一个补丁，明天一个扩展，后天又一个第三方版本

• 标准规范

• Oracle 也好，WebLogic 也罢，由于是产品化产物，使用流程与规范都是产品设计预期就确定好的，无论你是新手还是老司机，只需照做

• 服务支持

• 还是拿 Oracle 举例，出现任何问题，你可以通过购买原厂或第三方服务解决问题，好像没听说过当你 Redis 出现问题后能找原厂解决问题的

• 方案固化

• 大部分的架构方案厂商早已固化，比如集群、高可用、读写分离等，照做就行，不用多想

站在当下回头展望，不得不承认，IOE 时代虽然也有不尽如人意的诸多不便，但当你心里没底时，可以通过许许多多的 ‘正规途径’ 获得支援，以至于我信奉这么一句话「别慌，正在解决，肯定能搞定」

过去的就过去吧，当下该怎么办？

既然不能达到高可用的目的，那还放那么多台机器干嘛？

怎么不高可用了……你拔个网线他就能撑住

是吗？我拔啦？

拔吧……

我真拔啦？！

你……拔……吧……

在《2016ArchSummit - 深圳》上，来自饿了么的石佳宁向大家分享了《高速发展的饿了么订单系统架构演进》，其中有 “随机故障测试系统”的实践经验，但由于时间有限，听完分享之后并未及时与佳宁进行现场的互动与交流，内心充满了疑问和困惑，如是自主研发的吗？怎么实现的呢？面向生产环境吗？开源了吗？……

时间飞逝，在 16 年剩余的时间里，并未就这一话题进行深一步探索，直到 17 年中期，随着好买财富平台化的推进，越来越多的中间件拔地而起，高可用的话题被几次 P1 级事故推到了风口浪尖……

好吧，翻腾一下吧，厚着脸皮与雪峰（张雪峰 - 饿了么 CTO）取得了联系，开启了一次饿了么学习之行

<…在这里省略 1000 行关于 “饿了么 - 随机故障测试系统” 的介绍与截图…>

学习归来，结合自家场景与实际情况，复盘总结如下：

「为什么我们要做这件事（目的）？做成什么样（目标）？能够获得什么收益（展望）？」

「打算采取哪些攻击类型？」

面向节点资源 - Resources

1.CPU 可使用率；

2.内存使用量；

3.磁盘读取比特速率；

4.磁盘写入比特速率；

5.磁盘读取次数速率；

6.磁盘写入次数速率；

7.面向基础网络 - Network

8.网络延时；

9.网络丢包率；

10.面向应用接口 - Service

暂不实现

「怎么落地呢？打算做个超牛 X 的随机故障测试系统吗？」

既然是初尝，那咱们还是采取 “短、平、快” 的落地方式，不做 Web 界面，不做二次封装，直接裸用 Linux 工具

在这里介绍下部分工具用途，如有兴趣或有用，请自己百度：

「TC」

模拟延迟传输

带有波动性的延迟值

模拟网络丢包

模拟包重复

模拟数据包乱序

……

「FIO」

随机读

顺序读

随机写

顺序写

混合随机读写

……

「什么时候做完？对未来展望？」

今年 - 完成各中间件的攻击方案制定与评审，部分中间件至少完成 1 次执行

未来 - 提炼成 Web 系统，并在应用系统中试点

先说到这里，未完待续

对于当下的好买中间件及应用系统来说，在过去的一年里经历了业务持续增长，平台化演进等历程，在此期间，无论是技术架构还是业务逻辑实现，都有着或多或少的不足，因此，如果由于 “理论型” 高可用架构而导致服务有损，想必这也在情理之中吧

就像在「魔兽世界」中，每次新副本都会经历战术制定、开荒累积经验、最终通关庆贺等一系列经历，因此有时缺乏了 “理论” 到 “实践” 的过程，反而会让人觉得不够完美，您说是吗？

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/_k18m_IQYkizGOHHKSkPKQ