上篇已经介绍了业务及技术相关的痛点，针对这些痛点做了如下三点的重点工作。
业务上随着和手Q和微信的合作越来越深入，给到点评的流量也越来越大（这个干爹也是够意思，时不时就会给个上亿的push/资源位爆光）能否承接住这么大的流量是个最重要的课题。
1、业务隔离
2、活动营销系统领域划分
3、系统设计及稳定性保障
业务隔离
为什么要做业务隔离？
线上：非核心业务故障引发主流程完全不可用；
业务隔离是当时最紧迫的一项工作，最紧迫是因为发生一次严重故障，不但流量没有承接住，还影响到了下单主流程，对单量造成了影响，教训特别深刻，也对墨菲定律有了更深的理解（你认为可能会发生的问题，它一定会发生）。起因是这样：手Q突然给到运营2亿的push，运营乐呵呵的把我们在app上的活动链接丢给了手Q运营，就这样在技术不知情的情况下，告警四起，从数据库到MQ再到服务应用无不出现故障。具体故障分析另起文章说明。
线下：现一个项目导致系统膨胀，开发测试成本高企。
业务隔离主要目标
- 保证主要下单链路稳定
- 提高活动营销业务可用性
- 减少开发测试人力成本以及对环境的竞争
隔离主要任务
活动营销系统完全物理隔离，垂直切分，把对订单流程的影响降到0。
- 独立域名、web层、服务层、数据库以及缓存
-
接口拆分
将外卖首页整体请求做拆分，banner、金刚和瓷片请求收归到活动系统，商户列表保留在核心流程。这样即使banner、金刚和瓷片中任意一个服务挂了也不会影响到用户下单核心路径。
Paste_Image.png
-
服务依赖梳理
2015年携程大面积故障历历在目，网传是数据库被删，但是整个恢复过程却花了12个小时，正是因为服务之间的相互依赖无法梳理清楚，服务及服务之间相互依赖，结果导致一个服务都无法恢复。
服务依赖梳理分为水平划分和垂直划分，水平划分主要目的是服务收归，活动相关逻辑由活动系统系统提供服务。垂直划分主要是一个分层概念，什么服务是基础服务，什么服务是业务逻辑服务，什么服务是聚合服务，面向C端用户有服务层级一般是聚合服务->业务逻辑服务->基础服务。 -
非主流程业务降级&熔断
一般认为以促成用户下单为导向的业务，他的核心流程即为下单过程。在不影响用户下单的情况下，一切其他业务都可认为是非主流程业务。
例举在首屏的模块，banner位、瓷片位、广告商户、用户好友关系都是不太重要的展示，只有有商户列表还在，不太会影响用户下单行为。即使在部分核心服务出现故障时也要有能力提供有损的用户体验。就比如用券服务，如果券服务不可用，用户还可以原价下单。
所以很重要的一点是对这类非核心的服务能够做到平滑降级，banner故障、好友信息故障都可以不展示出来。
熔断是出于对系统的保护，在服务不可用的情况下避免对系统造成更大的压力。使用场景也很多，典型的是在支付场景，当微信支付故障率达到一定阈值后系统会自动熔断，在支付渠道上就会去掉微信支付，用户还可以使用银行卡或者支付宝。
网友评论