关键词总结：隔离设计概念（Bulkheads/隔板）、按服务种类隔离、按用户请求隔离
隔离设计概念
隔离设计对应的单词是 Bulkheads，中文翻译为隔板。这个术语是用在造船上的，也就是船舱里防漏水的隔板。软件设计也存在“漏水”，为了不让“故障”蔓延开来，需要使用“隔板”技术，来将架构分隔成多个“船舱”来隔离故障。
一般来说，对于系统的分离有两种方式，一种是以服务的种类来做分离，一种是以用户来做分离。
按服务种类隔离
每个服务对应自己的数据库，每个数据库只保存和其业务相关的数据和处理的状态，每个服务都对外提供业务调用接口。微服务所推荐的架构方式。这种架构在系统隔离上做得比较好，但是也存在一些问题。
- 如果多板块数据获取与多个服务调用
由于按服务种类隔离，同时获得多个板块的数据和调用多个服务，响应时间增长性能降低。 - 如果有大数据平台
每个服务对应自己的数据库，如果有大数据平台，就需要把这些数据都抽取到一个数据仓库中进行计算，增加了数据合并的复杂度。需要借助某种框架或中间件来收集数据到一个数据仓库。 - 如果业务逻辑或是业务流程需要跨板块
一个板块的故障会导致整个流程走不下去，导致整体业务故障。需要保障业务流程中各个子系统的高可用性，并且在业务流程上做成 Step-by-Step 的方式 - 如果跨板块交互
板块之间需要借助消息队列中间件来以发布/订阅的方式进行顺畅沟通，以降低板块之间在沟通时因为等待其他板块的响应而产生的阻塞问题。 - 多个板块中分布式事务的问题
需要类似“二阶段提交” 这样的方案来确保数据的一致性。
按用户请求隔离
将用户分成不同的组，在后端把同一个服务根据这些不同的组分成不同的实例。让同一个服务对于不同的用户进行冗余和隔离，当服务实例挂掉时，只会影响其中一部分用户，而不会导致所有的用户无法访问。即“多租户”模式，我们可以将客户进行分类，例如将申请大额资源服务的用户分配至独立的一个或多个服务实例中，将申请小额资源服务的用户分配至共享的一个或多个服务实例中。
多租户通常的三种做法：
- 完全独立的设计。每个租户有自己完全独立的服务和数据。
- 数据分区独立，服务共享。多租户的服务是共享的，但数据是分开隔离的。
- 服务共享，数据分区共享。每个租户的数据和服务都是共享的。
三种方案各有优缺点，如图所示
隔离设计关键点
- 隔离粒度
对业务需求和系统进行详细的分析，确保能定义出恰当的业务隔离粒度，过大和过小都不好。 - 取舍评估
无论是按服务种类隔离还是按用户请求隔离，需要考虑复杂度、成本、性能、资源分配等的问题。要找到一个适合这些问题的方案，或一个折中的方案，以确定哪些事情对隔离设计来说是必须的，哪些是可以舍弃的。 - 设计模式选用
隔离模式需要与一些设计模式（高可用、重试、异步、消息中间件，流控、熔断等）的方式配套使用。 - 自动化运维与管控工具
为了降低分布式系统的运维复杂度，需要借助自动化运维工具来提高运维人员对系统指标及资源利用率方面的管理效率。 - 监控系统
需要一个非常完整的监控系统，能对所有服务进行监控
参考资料：
左耳听风（极客时间）链接：
http://gk.link/a/10f5D
GitHub链接：
https://github.com/lichangke/LeetCode
CSDN首页：
https://me.csdn.net/leacock1991
欢迎大家来一起交流学习