隔离

发表于 分类于 ， ， 阅读次数：

如同船舱隔离

对于系统的分离有两种方式，一种是以服务的种类来做分离，一种是以用户来做分离

  1. 以服务做隔离，多种业务从接入到应用到持久化层都做隔离，且做到物理上的隔离，如商品，评,论….。这也是现在微服务的常规做法，但这样有个问题，性能会降低，因为你查询可能涉及到多个服务的调用，在网络中转增多了，这里的性能指的是时延，而不是吞吐量，这种场景下吞吐量其实是会增加。对于这样的问题，一般来说，我们需要小心地设计用户交互，最好不要让用户在一个页面上获得所有的数据。对于目前的手机端上来说，因为手机屏幕尺寸比较小，所以，也不可能在一个屏幕页上展示太多的内容。
    以及还有跨业务板块请求链路中单点故障导致整条链路走不下去问题，跨板块交换复杂的问题（引入消息中间件，且该中间件可pub/sub，持久化）,分布式事务问题（在亚马逊中，使用的是 Plan – Reserve – Commit/Cancel 模式）
1
2
3
4
5
6
7
8
9
10
用户请求资源
       │
     Plan ──> 检查可用性
       │
     Reserve ──> 临时锁定资源
       │
   ┌───┴──────┐
Commit       Cancel
 │            │
资源最终占用  资源释放回滚

可见，隔离了的系统在具体的业务场景中还是有很多问题的，是需要我们小心和处理的。对此，我们不

可掉以轻心。根据我的经验，这样的系统通常会引入大量的异步处理模型。

  1. 用户隔离，即多租户

三种方式，但没有绝对，一般是这种。服务共享，数据独立，若比较重要的客户就做到完全独立

然而，在虚拟化技术非常成熟的今天，我们完全可以使用“完全独立”（完全隔离）的方案，通过底层

的虚拟化技术（Hypervisor 的技术，如 KVM，或是 Linux Container 的技术，如 Docker）来实现物

理资源的共享和成本的节约。

:::color4
ps：docker它是内核空间共享，但用户空间隔离，容器里安装的只是操作系统的一部分即用户空间，内核空间还是宿主机的

:::