左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家
180928 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 119 讲
左耳听风
15
15
1.0x
00:00/00:00
登录|注册

42 | 弹力设计:隔离设计

系统设计复杂度
资源利用和成本的折中
选择合适的方案
共享的服务,共享的数据分区
独立的数据分区,共享的服务
完全独立设计
分布式事务问题
跨板块交互复杂
跨板块业务流程导致整体故障
大数据平台数据抽取复杂度增加
多个板块数据获取降低性能
问题:
多租户模式
故障只影响部分用户
同一服务根据用户分成不同实例
用户分组
问题:
物理上隔离故障
系统分隔成多个船舱
按用户的请求来做分离
按服务的种类来做分离
异步通讯设计
隔离设计
后续文章
弹力设计篇
分布式系统设计模式

该思维导图由 AI 生成,仅供参考

你好,我是陈皓,网名左耳朵耗子。
隔离设计对应的单词是 Bulkheads,中文翻译为隔板。但其实,这个术语是用在造船上的,也就是船舱里防漏水的隔板。一般的船无论大小都会有这个东西,大一点的船都会把船舱隔成若干个空间。这样,如果船舱漏水,只会进到一个小空间里,不会让整个船舱都进水而导致整艘船都沉了,如下图所示。
我们的软件设计当然也“漏水”,所以为了不让“故障”蔓延开来,需要使用“隔板”技术,来将架构分隔成多个“船舱”来隔离故障。
多扯一句,著名的泰坦尼克号也有 Bulkheads 设计,然而其设计上有个缺陷。如下图所示,当其撞上冰山漏水时,因为船体倾斜,导致水漫过了隔板,从而下沉了。
在分布式软件架构中,我们同样需要使用类似的技术来让我们的故障得到隔离。这就需要我们对系统进行分离。一般来说,对于系统的分离有两种方式,一种是以服务的种类来做分离,一种是以用户来做分离。下面具体说明一下这两种方式。

按服务的种类来做分离

下面这个图中,说明了按服务种类来做分离的情况。
上图中,我们将系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库,做到从接入层到应用层再到数据层三层完全隔离。这样一来,在物理上来说,一个板块的故障就不会影响到另一板块。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式系统设计模式中的弹性设计篇之“隔离设计”一文介绍了在分布式软件架构中如何利用隔离设计来隔离故障,确保系统的稳定性和可靠性。作者以船体水密舱的设计为例,引出了隔离设计的概念,分别从按服务种类隔离和按用户隔离(多租户)两个方面进行了详细阐述。 在按服务种类隔离方面,文章提到了将系统分成不同板块,使用不同的域名、服务器和数据库进行隔离,以及可能出现的问题和解决方案。而按用户隔离方面,介绍了将用户分成不同组,根据不同组分配不同的服务实例,实现多租户模式的设计。 此外,文章还强调了隔离设计的重点,包括定义隔离业务的大小和粒度、考虑系统的复杂度、成本、性能、资源使用等问题,配置高可用、重试、异步、消息中间件等设计模式,以及运维的复杂度提升和监控系统的重要性。 总的来说,本文通过生动的船体隔离设计比喻,深入浅出地介绍了分布式系统中隔离设计的重要性和实际应用。读者可以从中了解到隔离设计的两种方式、相关的优缺点以及设计时需要考虑的重点,对分布式系统设计具有一定的指导意义。 文章内容丰富,结合实际案例,对读者进行了深入浅出的技术介绍,适合对分布式系统设计感兴趣的读者阅读学习。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《左耳听风》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(24)

  • 最新
  • 精选
  • shufang
    多租户的实例是指请求层服务层数据层的完全隔离吗?

    作者回复: 多租户的隔离有三种方案,我在文中说了,请仔细阅读。

    2018-03-02
  • 我们目前系统中采用隔离的点包括: 1、服务集群隔离,我们可以配置不同的请求访问不同的服务集群,我们通过服务别名来区分 2、数据存储隔离,包括数据库隔离、缓存集群隔离。数据库隔离一般通过分库分表,读写分离 3、线程池隔离,在同一个应用中,不同的任务处理通过线程池隔离 4、网络带宽隔离 暂时想到这么多,我理解隔离的本质是当系统出尽现故障时,尽可能的将故障影响范围降到最低。
    2018-05-20
    1
    30
  • 几度嘟嘟
    不是很能理解多组户做法中的第三种”共享服务和数据分区“。文章前半部分讲到用户分离的时候,我理解这里指的是物理隔离,但是阅读到”共享的服务,共享的数据分区。每个租户的数据和服务都是共享的“时,我有些疑问这不是又回到隔断设计前的问题吗?一旦服务挂了之后,不是依旧会导致所有用户不可用吗? 如果是我理解上的问题,那么”共享的服务和数据分区“隔离的又是什么呢?
    2020-05-29
    9
    3
  • 罗杰.菲の樂
    现在云服务厂商提供的服务大多数都是multi-tenant的,一般会有resource governance(RG)的专门的模块去防止 noisy neighbor,这里也体现出了隔离的思想。 如果用database as a service,即使创建了3个数据库服务,它们还是有一定的可能会被映射到同一个物理主机上。所以这里RG就显得更为重要了。
    2020-07-13
    2
  • 常清静
    目前,所采用的隔离,只是服务级别的隔离,用户级别的隔离,更多的像是基于区域而进行的异地多活,通过不同的地域,隔离不同的用户,这样,从地区网络,以及资源调控上,更具备优势,但是这个的话,也只有到了一定体量之后,才是合理高效的架构
    2020-03-29
    2
  • 北极点
    隔离设计感觉是一个随着系统逐步进化,业务逐渐成熟的前提情况下诞生出来的模式。特别是多租户的设计!我之前的工作当中要是早了解或者思考下这种设计可能就会在维护现有的系统时考虑设计了,或者也会给技术管理层领导提建议了!读这篇文章很有感触。
    2018-03-22
    2
  • escray
    Bulkhead n. a wall that divides the structure of a ship or aircraft into separate parts. 对于普通租户,服务共享,数据隔离;对于重要租户,完全独立资源。 利用虚拟化技术实现物理资源共享和成本节约。 对于云盘存储来说,一旦发现不同用户存储了相同文件,那么就可以采用数据共享的方式,特别适合存储视频文件。 感觉一般会采用服务种类和用户双重分离的方式,先按照服务种类分,对于核心服务提供更多的资源,在极端情况下也保证运行;然后再按照用户分,可以按用户等级或地域,保障重点用户。 但是这样一来,似乎就更复杂了。 如果底层的 IaaS 或者 PaaS 平台做的好的话,是否可以减少隔离的考虑? 完整的服务监控系统,我觉的应该找机会去做云平台监控相关工作。 突然发现这个专栏的订阅数和留言的比例悬殊比较大,是因为留言的人少,还是作者放出来的少?
    2023-03-14归属地:北京
    1
  • InfoQ_6fb64a94dbb7
    船仓 隔板/泰坦尼克号这些内容简直和《反应式设计模式》书中一毛一样
    2021-05-02
    1
  • Geek_7b1383
    隔离设计的重点 1)定义好隔离业务的大小和粒度,过大和过小都不好。这需要认真地做业务上的需求和系统分析。 2)系统的复杂度、成本、性能、资源使用的问题的合适的均衡方案,或是分布实施的方案 3)隔离模式需要配置一些高可用、重试、异步、消息中间件,流控、熔断等设计模式的方式配套使用。 4)自动化运维的工具,尤其是使用像容器或是虚拟机这样的虚拟化技术可以帮助我们更方便地管理,和对比资源更好地利用 5)非常完整的能够看得到所有服务的监控系统
    2020-04-27
    1
  • FeiFei
    是啊。 监控系统太重要了,怕的不是出故障。故障在分布式系统里面是不可避免的,需要解决的是围绕着故障发生所做的一系列事情。 事前的监控 发生时候的故障处理 解决完问题的故障反思,避免下次再出现同一个错误。
    2020-01-16
    1
收起评论
显示
设置
留言
24
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部