常用开源熔断隔离组件：Hystrix，Resilience4j
可以从全局，IP，userID等多维度做限流。限流的两个主要目的：1，应对突发流量，避免系统被压垮（全局限流和IP限流）2，防刷，防止机器人脚本等频繁调用服务（userID限流和IP限流）
在核心链路上，服务可以冗余它依赖的服务的数据，依赖的服务故障时，服务尽量做到自保。比如订单服务依赖库存服务。我们可以在订单服务冗余库存数据（注意控制合理的安全库存，防超卖）。下单减库存时，如果库存服务挂了，我们可以直接从订单服务取库存。可以结合熔断一起使用，作为熔断的Fallback（后备）方案。
可能很多人都听过服务降级，但是又不知道降级是怎么回事。实际上，上面说的熔断，限流，数据冗余，都属于服务降级的范畴。还有手动降级的例子，比如大促期间我们会关掉第三方物流接口，页面上也关掉物流查询功能，避免拖垮自己的服务。这种降级的例子很多。不管什么降级方式，目的都是让系统可用性更高，容错能力更强，更稳定。关于服务降级详见本文后面的内容。
缓存穿透。对于数据库中根本不存在的值，请求缓存时要在缓存记录一个空值，避免每次请求都打到数据库
缓存雪崩。在某一时间缓存数据集中失效，导致大量请求穿透到数据库，将数据库压垮。可以在初始化数据时，差异化各个key的缓存失效时间，失效时间 = 一个较大的固定值 + 较小的随机值
缓存热点。有些热点数据访问量会特别大，单个缓存节点（例如Redis）无法支撑这么大的访问量。如果是读请求访问量大，可以考虑读写分离，一主多从的方案，用从节点分摊读流量；如果是写请求访问量大，可以采用集群分片方案，用分片分摊写流量。以秒杀扣减库存为例，假如秒杀库存是100，可以分成5片，每片存20个库存。
部署隔离：我们经常会遇到秒杀业务和日常业务依赖同一个服务，以及C端服务和内部运营系统依赖同一个服务的情况，比如说都依赖订单服务。而秒杀系统的瞬间访问量很高，可能会对服务带来巨大的压力，甚至压垮服务。内部运营系统也经常有批量数据导出的操作，同样会给服务带来一定的压力。这些都是不稳定因素。所以我们可以将这些共同依赖的服务分组部署，不同的分组服务于不同的业务，避免相互干扰。
数据隔离：极端情况下还需要缓存隔离，数据库隔离。以秒杀为例，库存和订单的缓存（Redis）和数据库需要单独部署！数据隔离后，秒杀订单和日常订单不在相同的数据库，之后的订单查询怎么展示？可以采用相应的数据同步策略。比如，在创建秒杀订单后发消息到消息队列，日常订单服务收到消息后将订单写入日常订单库。注意，要考虑数据的一致性，可以使用事务型消息。
业务隔离：还是以秒杀为例。从业务上把秒杀和日常的售卖区分开来，把秒杀做为营销活动，要参与秒杀的商品需要提前报名参加活动，这样我们就能提前知道哪些商家哪些商品要参与秒杀，可以根据提报的商品提前生成商品详情静态页面并上传到CDN预热，提报的商品库存也需要提前预热，可以将商品库存在活动开始前预热到Redis，避免秒杀开始后大量访问穿透到数据库。
CI测试，持续集成测试，在我们每次提交代码到发布分支前自动构建项目并执行所有测试用例，如果有测试用例执行失败，拒绝将代码合并到发布分支，本次集成失败。CI测试可以保证上线质量，适用于用例不会经常变化的稳定业务。
性能测试，为了保证上线性能，所有用户侧功能需要进行性能测试。上线前要保证性能测试通过。而且要定期做全链路压测，有性能问题可以及时发现。
2783670671
U869310561
