概要：系统的分离有两种方式，以服务、以用户来做分离；隔离设计的重点：
一、按服务的种类来做分离
系统分成了用户、商品、社区三个版块。使用不同的域名、服务器和数据库，从接入层到应用层再到数据层三层完全隔离。每个服务都有自己的一个数据库，保存相关业务的数据和相应的处理状态。每个服务对外暴露。微服务所推荐的架构方式。
隔离存在以下一些问题：
1.调用多个服务(同时获得多个板块数据)，会降低性能。性能指的是响应时间，而不是吞吐量（这种架构下，吞吐量可以得到提高）。所以不要在一个页面上获得所有的数据，好在手机页面小。
2.增加了数据合并的复杂度。需要一个框架、间件来对数据进行相应的抽取。
3.导致整体业务故障，如果业务流程跨版块的话，所以业务流程Step-by-Step 的方式，交互的每一步都可以保存，以便故障恢复后继续执行，而不是从头执行。
4.跨版块复杂。高可用并持久化的消息中间件(类似Pub/Sub),打通各个版块的数据和信息交换。
5.多版块分布式事务问题。采用“二阶段提交”方案。亚马逊使用的是 Plan – Reserve – Commit/Cancel 模式。也就是说，先做一个 plan 的 API 调用，各个子系统 reserve 住相应的资源，成功Commit；一个失败体 Cancel。很像阿里的 TCC – try confirm/cancel。引入大量的异步处理模型。
二·、按用户的请求来做分离
这样系统挂掉时，只影响一部分。
“多租户”模式：大客户，设置专门独立服务实例，或是服务集群与其他客户隔离开来，小用户，共享一个服务实例。
“多租户”架构来引入复杂度。完全隔离，资源浪费，共享，程序设计复杂。
多租户的做法有三种：
(1)完全独立的设计。每个租户有自己完全独立的服务和数据。
(2)独立的数据分区，共享的服务。多租户的服务是共享的，但数据是分开隔离的。
(3)共享的服务，共享的数据分区。每个租户的数据和服务都是共享的。
这三种方案各有优缺点，如图所示。
在虚拟化技术非常成熟的今天，我们完全可以使用“完全独立”（完全隔离）的方案，通过底层的虚拟化技术（Hypervisor 的技术，如 KVM，或是 Linux Container 的技术，如Docker）来实现物理资源的共享和成本的节约。
三、隔离设计的重点：
定义好隔离业务的大小和粒度，不过大过小。业务上的需求和系统分析。
考虑系统的复杂度、成本、性能、资源使用的问题，无论是做系统版块还是多租户的隔离，定义好要什么和不要什么，一个合适的均衡方案/分布实施的方案尤其重要，。
配置高可用、重试、异步、消息中间件，流控、熔断等配套使用。
自动化运维的工具：使用像容器或是虚拟机更方便地管理
看到所有服务的监控系统。
评论：
我们目前系统中采用隔离的点包括：
1、服务集群隔离，我们可以配置不同的请求访问不同的服务集群，我们通过服务别名来区分
2、数据存储隔离，包括数据库隔离、缓存集群隔离。数据库隔离一般通过分库分表，读写分离
3、线程池隔离，在同一个应用中，不同的任务处理通过线程池隔离
4、网络带宽隔离
隔离的本质是当系统出尽现故障时，将影响范围降到最低。
