容量预估/规划及故障演练

  古人云：“知己知彼，百战百殆”

容量预估

  对于电商大促场景通常都须要进行容量规划及故障演练。容量规划，就是经过对复杂业务场景的分析，应用必定的技术手段，如压力测试、来实现对资源合理扩容、有效规划的过程。

  对于电商而言，通常的核心链路就是交易链路，简易描述就是用户可以成功登录、而后能经过浏览商品详情页进行下单订购，或者先将意向商品先加入购物车，以后经过购物车进行订购结算，在这期间会进行各类优惠的价格处理、库存判断等，最后还要可以支付成功，这样一个交易支付流程才算完成。

 固然，当大促的峰值时刻时，场景又有可能不一样，由于绝大部分用户早已将意向商品加入购物车，且各类优惠券也已经申领成功，就等着那个时刻下单了。

以前进行传统的预测方式通常是在测试环境下，针对场景进行数据模拟，须要开发、测试、运维等人员根据线上的场景，评估可能出现的状况，这种方式更依赖于人的经验。经常使用的工具包括Apache Benchmark、LoadRunner（收费）、Jmeter等，这种作法很是不许确，很难模拟出接近prod环境的场景和数据。

    如今中大型的互联网公司广泛采用全链路压测的方式，如京东的ForceBot、阿里巴巴的全链路压测平台（其对应的云产品PTS，价格仍是蛮贵的）。通常全链路压测平台在接入层的请求入口进行真实流量复制（如网易开源的TCPCopy），这样开源简化模拟数据带来的成本，将复制的请求引入压测环境，对压测环境的服务进行施压。另外若要加大压力，开源经过调节TCPCopy的参数，将流量先蓄积（如经过MQ工具）。在DB一侧经过影子库及影子表进行隔离，影子表和生产表创建相同的表结构，经过打tag进行区分，便于隔离删除。

  通常全链路压测须要注意什么呢？

  1.找到核心流程。作全链路压测仍是须要巨大的成本，不可能作全，遵循80/20原则，这是压测的目标

  2.选择隔离方式。一种是进行环境的独立隔离，但资源成本高，另外一种是和prod混合，这种方式真实性更高，节省资源，但隔离性很差

  3.缩小依赖服务范围

故障演练

 提及故障，运维们都想起了背锅侠，开发及运维同窗都惧怕故障，有的公司虽然制定了应对策略，可是这些策略在没有测试的状况下谁也不敢轻易启动，惧怕引发更严重的故障。

  XX互联网公司由于网络缘由致使大规模故障，中断几个小时，是由于没有灾备吗？可能不太可能。虽然他们作了灾备，可是由于很长时间没有测试过了，因此不敢切换。故障演练正式为了解决“不敢切换”的问题。

  另外不是有了故障演练就敢切换，并且还要结合应急预案及应急指挥中心。

  Netflix开源了Chaos Monkey，Chaos Monkey是一个在生产环境随机选择并关闭服务的工具。随后，阿里巴巴也开始进行了故障演练，阿里也有一个故障演练工具，叫：MonkeyKing，为每一年的双11 活动作准备，不过如今都基本不维护了，另外阿里也衍生出了ChaosBlade工具,最后集成到阿里云云产品AHAS中，MonkeyKing能够模拟硬件故障、API故障、分布式故障、数据库故障等

   固然故障演练不只开源检验业务应用处理失败的能力，也能够用户处理失败的能力，也能够用于当故障发生时，如何快速有效地发现并定位故障，通知相应运维人员进行处理，更重要的是，完善咱们的应急预案，避免有相似状况发生。

最后，容量规划及故障演练是一件很是重要的事宜，不是一我的承担，有时须要整个开发团队、运维团队、DBA、测试、甚至还有运营团队/客服/公关等一块儿参与讨论，同时制定应急预案，成立应急指挥中心（例如阿里的全球运行指挥中心GOC）