左耳大神 - 隔离设计

设计理念

隔离的因为单词为Bulkheads， 在英文中指船的空气仓，有这样的空气仓，船在部分漏水的时候就不至于整个船沉没。

常用的设计方式

按照服务种类

上图中，我们将系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库，做到从接入层到应用层再到数据层三层完全隔离。这样一来，在物理上来说，一个板块的故障就不会影响到另一板块。

缺点

调用多个服务的响应时间降低

增加了数据合并的复杂度

一个板块的故障也会导致整个流程走不下去

跨板块间的通信变得复杂

事务的提交变为了二阶提交

按照用户分类

在这个图中，可以看到，我们将用户分成不同的组，并把后端的同一个服务根据这些不同的组分成不同的实例。让同一个服务对于不同的用户进行冗余和隔离，这样一来，当服务实例挂掉时，只会影响其中一部分用户，而不会导致所有的用户无法访问。

三种常见的实践方法

• 完全独立的设计。每个租户有自己完全独立的服务和数据
• 独立的数据分区，共享的服务。多租户的服务是共享的，但数据是分开隔离的。
• 共享的服务，共享的数据分区。每个租户的数据和服务都是共享的

在虚拟化技术非常成熟的今天，我们完全可以使用“完全独立”（完全隔离）的方案，通过底层的虚拟化技术（Hypervisor 的技术，如 KVM，或是 Linux Container 的技术，如 Docker）来实现物理资源的共享和成本的节约。

实践建议

• 设计时候要隔离号业务的大小和粒度，过大和过小都不好。
• 考虑系统的复杂度，成本，性能，资源使用的问题
• 需要配置一些高可用，重试，异步，消息中间件，控流，熔断等设计模式的方法配套使用
• 运维的复杂度提升
• 看得见所有服务的监控系统

思考一下之前系统的方案

某基因系统

• 按服务来区分的
• 一个板块的故障也会导致整个流程走不下去
• 没有回退机制，只有重试
• 隔离的服务，共享的数据

如果改进一下的话

• 有回退机制，每个小步骤成功不了就立马回退，不要取消掉之前的结果
• 系统会变得很复杂，因为数据是共享的，所以一旦数据除了问题就是大问题，对于整个数据池的维护需要全部人一起维护。

某广告后台系统

• 没有隔离系统
• 一个板块的鼓掌会导致整个网页访问失败
• 没有回退，只有重试

如果改进一下的话

• 使用按服务来区分
• 需要复杂的rollback机制