怎么访问不了了？
我看看……主节点挂了，我重启下
咦？没切换吗？不是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

创作场景

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