写作目的

最近看到了河北王校长隔离的视频，结合自己在工作中的应用，分享常见的隔离落地方案。

隔离落地方案

服务环境隔离

因为我们的项目服务于整个国内的多条产品线，也服务于国外。为了低成本所以使用一套代码。在产品线之间隔离，包括服务（docker机器和DB）。一方面好排查问题，另一方面可以在大促等期间定向的对某些服务扩容，从而不浪费资源。

DB隔离

DB隔离包括MySQL和Redis。不同的环境使用不同的MySQL环境。

• 费用透明
  阿里公司再今年完成了拆分，之前不同不同部门之间是兄弟部门，公司拆分完毕后，不同的部门可能就是甲乙方的关系。以我所在的A部门为例，A部门给美国的某个部门提供服务，现在需要收费了，那收费的标准是什么呢？，我直接买云服务器，且这个数据库只有你们自己用，那么这个费用他们出的自然就甘心。
• 资源隔离
  国外应该是没有双十一购物节，如果在一个DB里，那么在双十一的日子里，就会因为淘宝天猫的流量扩大而导致国外的请求受到影响，所以需要隔离。
• 功能隔离（叫法不准确）
  项目是使用了大量的Redis。比较常用的两个场景是缓存和分布式锁。对于这两个功能，缓存Redis服务器因为缓存的数据多或者QPS大因此需要高性能大内存的服务器，且服务器出现宕机的概率大。而分布式锁Redis服务器QPS很少且存的KV也很小，所以可以使用一个高性能小内存的服务即可。

消息隔离

项目中有使用到和算法交互，本文通过用户做隔离，对于图片和文字来说，生成速度快，且可满足要求，给予高的权重去请求算法生成智能图文，而对于视频制作来说是锦上添花且非必须则权重低一些，从而保证高优的链路会更健壮一些。

读写隔（分）离

本文仅从MySQL的角度来说。理想中的情况是一主多从，主库负责写，从库负责读。

但是思考这个问题，场景是一主一从，如果一秒来了5个写请求和5个读请求，那么主库的QPS是5（写），而从库的QPS是10（写加读），其实从库的负担会大一些。如果从库的性能拉一些，可能会主从延迟大，导致的结果是你新加的数据查从库查询不出来。

因此建议：写主查主，备库仅仅是备份，能用充钱解决的事都是小问题。 至少我公司是这么搞的。

部分参考

口撕高可用架构第一弹，高可用架构之-隔离术