(2)弹力设计篇之“隔离设计”

概要：系统的分离有两种方式，以服务、以用户来做分离；隔离设计的重点：

一、按服务的种类来做分离

系统分成了用户、商品、社区三个版块。使用不同的域名、服务器和数据库，从接入层到应用层再到数据层三层完全隔离。每个服务都有自己的一个数据库，保存相关业务的数据和相应的处理状态。每个服务对外暴露。微服务所推荐的架构方式。

隔离存在以下一些问题：

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）来实现物理资源的共享和成本的节约。

三、隔离设计的重点：

定义好隔离业务的大小和粒度，不过大过小。业务上的需求和系统分析。

考虑系统的复杂度、成本、性能、资源使用的问题，无论是做系统版块还是多租户的隔离，定义好要什么和不要什么，一个合适的均衡方案/分布实施的方案尤其重要，。

配置高可用、重试、异步、消息中间件，流控、熔断等配套使用。

自动化运维的工具：使用像容器或是虚拟机更方便地管理

看到所有服务的监控系统。