12.24 Day 9 - 弹力设计篇之“隔离设计”

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 9 天，也是我第 9 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《弹力设计篇之“隔离设计”》的文章。

关键词总结：隔离设计概念（Bulkheads/隔板）、服务种类间隔离（多板块数据获取、大数据平台、跨板块业务逻辑/流程步骤、跨板块交互、多板块分布式事务）、用户请求间隔离（服务/数据独立、服务共享/数据独立、服务/数据共享）、隔离设计关键点（隔离粒度定义、取舍评估、设计模式选用、自动化管控工具、监控系统）。

 

所学总结：

 

隔离设计概念

Bulkheads/隔板

隔板的概念源自于船舱，隔板的作用是当船的某个部位漏水时不会波及到由隔板隔开的其他船舱，让船不至于因为它的某一个舱漏水而沉没。
 

服务种类间隔离

每个服务对应自己的数据库，每个数据库只保存和其业务相关的数据和处理的状态，每个服务都对外提供业务调用接口。

多板块数据获取

响应时间会变长，但是相应的，吞吐量也会提高。考虑到用户体验，尽量避免一次性返回所有数据。

大数据平台

需要借助某种框架或中间件来收集数据到一个数据仓库。

跨板块业务逻辑/流程步骤

板块间在访问时出故障将会产生一个不完整的业务流程。需要保证板块间的业务按先后的顺序一步步的走，每走一步就保存当下进度，从头到尾都要走顺走通。保存每一步的快照是为了当出故障时不至于要从头再来一次。

跨板块交互

板块之间需要借助消息队列中间件来以发布/订阅的方式进行顺畅沟通，以降低板块之间在沟通时因为等待其他板块的响应而产生的阻塞问题。

多板块分布式事务

多个板块之间的事务没法共享，所以需要类似 2PC 这样的方案来确保数据的一致性。
 

用户请求间隔离

将用户的请求分组发送至相同服务的各个实例中可以保证当部分服务实例出现问题时只会影响到那部分实例上的用户的使用而不会出现所有用户都无法使用服务的情况。也即“多租户”布局，我们可以将客户进行分类，例如将申请大额资源服务的用户分配至独立的一个或多个服务实例中，将申请小额资源服务的用户分配至共享的一个或多个服务实例中。

服务/数据完全独立

被分配至该布局的租户将处在完全独立的服务实例和数据分区中。

服务共享/数据独立

被分配至该布局的租户将处在共享的服务实例和独立的数据分区中。

服务/数据完全共享

被分配至该布局的租户将处在完全共享的服务实例和数据分区中。
 

隔离设计关键点

做隔离设计的一些必要关注点。

隔离粒度定义

对业务需求和系统进行详细的分析，确保能定义出恰当的业务隔离粒度。

取舍评估

需要考虑复杂度、成本、性能、资源分配等的问题。要找到一个适合这些问题的方案，或一个折中的方案，以确定哪些事情对隔离设计来说是必须的，哪些是可以舍弃的。

设计模式选用

跟隔离设计可以配套使用的设计模式有：高可用、重试机制、异步机制、消息队列、流量管控、熔断。

自动化管控工具

为了降低分布式系统的运维复杂度，需要借助自动化运维工具来提高运维人员对系统指标及资源利用率方面的管理效率。

监控系统

运维团队还需要一套非常完备的监控系统，它需要看到每一项系统指标和资源使用现状。
 

末了

重新总结了一下文中提到的内容：船体水密舱的设计、分布式系统的隔离设计、常见的隔离种类。