左耳听风_043_42_弹力设计篇之隔离设计
你好，我是陈浩网名左耳朵house隔力设计对应的单词是orcts,中文翻译为隔板。
但其实呢，这个术语是用在造船上的，也就是在船舱里防漏水的隔板。
那一般的船无论是大小都会有这个东西，大一点的船呢都会把船舱隔成几个空间。
那这样呢如果船舱漏水只会进到一个小空间里，不会让整个船舱都进水，而导致整艘船都沉了。
就像文中这两张图一样，我们的软件设计啊当然也漏水。
所以呢为了不让故障蔓延开啊，也需要使用隔板技术来将架构啊分割成多个船舱来隔离故障。
那这里呢我多扯一句，著名的泰坦尼克号也有八cs s设计。
但是他在设计上有个缺陷，你来看文中这张图可以看到，当他撞上冰山漏水的时候，因为船体倾斜了，导致水漫过了隔板，从而下沉了。
在分布式软件架构中呢，我们同样需要使用类似的技术来让我们的故障得到隔离。
那这个呢就需要我们对系统进行分离。
那一般来说呢对于系统的分离啊有两种方式，一种呢是以服务的种类来做分离。
那另一种呢是以用户来做分离。
接下来啊我具体说明一下这两种方式。
首项是按照服务的种类来做分离，我在文中用了一张图给你展示了，按照服务种类来做分离的情况。
在图中呢，我们将系统分成了用户、商品和社区三个板块。
这三个板块分别使用不同的域名、服务器和数据库，做到从接入层到应用层，再到数据层、三层啊完全隔离。
那这样一来呢，在物理上来说啊，一个板块的故障就不会影响到另一板块了。
在亚马逊呢，每个服务啊都有自己的一个数据库。
每个数据库中呢都保存着和这个业务相关的数据和相应的处理状态。
而每个服务从一开始啊就准备好了对外暴露。
那同时呢这也是微服务所推荐的架构方式，但任何架构呢都有它好和不好的地方。
那上面这种架构啊，虽然在系统隔离上做的比较好，但是也存在一些问题。
那首先呢如果我们需要同时获得多个板块的数据，那么呢就需要调用多个服务。
那这样呢就会降低性能，要注意这里性能降低啊，指的是响应时间而不是吞吐量。
那对于目前的问题啊，一般来说啊，我们需要小心的设计用户交互，最好不要让用户在一个页面上获得所有的数据。
那对于目前的手机端来说啊，因为手机屏幕尺寸比较小，所以呢也不可能在一个屏幕页上展示太多的内容。
那第二个问题呢，如果有大数据平台啊，就需要把这些数据都抽取到一个数据仓库中进行计算。
那这样呢也增加了数据合并的复杂度。
那对于这个问题啊，我们需要一个框架啊或者一个中间件来对数据啊进行相应的抽取。
那另外呢，如果我们的业务逻辑或者业务流程需要跨板块的话，那么一个板块的故障也会导致整个流程走不下去，同样会导致整体的业务故障。
那对于这个问题呢，一方面我们需要保证这个业务流程中各个子系统的高可用性，并且在业务流程上做成step by step的方式。
那这样用户交互的每一步啊都可以保存，以便在故障恢复之后啊可以继续执行，而不是从头执行。
那还有呢如果需要有跨板块的交互，也会变得有点复杂。
对此呢我们就需要有一个类似于pop sub的高可用啊，并且可以持久化的消息订阅通知中间线，来打通各个板块之间的数据和信息交换。
那最后呢还会有多个板块中分布式事务的问题。
那对于这个问题呢，我们需要二阶段提交这样的方案。
在亚马逊中呢使用的是plan reserve commit cancel模式。
也就是说呢我先做一个plan AAI调调，呃，然后各个子系统呢reserve住相应的资源。
如果成功了，the commit,那如果有一个失败，the整体cancel,那其实这个呢很像阿里的TCC啊，也就是try confirm cancel.由此可见啊，格离的系统在具体的业务场景中啊，还是会有很多的问题啊，是需要我们小心处理的。
对此呢我们不可掉以轻心。
那根据我的经验，这样的系统通常会引入大量的异步处理模型。
那以上呢就是按服务的种类来做分离。
那接下来呢我们再谈一谈第二种方式啊，也就是按照用户的请求来做分离。
先来看文中这个按照用户请求来做分离的图示。
那在这个图中呢，我们可以看到我们将用户啊分成不同的组，并且把后端的同一个服务啊，根据这些不同的组分成不同的实例，让同一个服务呢对于不同的用户进行冗余和隔离。
那这样一来呢，当服务实例挂掉的时候啊，只会影响其中一部分用户，而不会导致所有的用户无法访问。
那这种分离啊和商品按照功能的分离可以融合。
那说白了这就是所谓的多租户模式。
对于一些比较大的客户，我们可以为他们设置专门独立的服务实力，或者让服务集权啊和其他客户隔离开来。
那对于一些比较小的用户来说呢，可以让他们啊共享一个服务实例。
那这样呢也可以节省相关的资源。
那对于多租户的架构来说啊，会引入一些系统设计的复杂度。
那一方面呢如果完全隔离资源使用上会比较浪费。
但是如果共享呢又会导致程序设计的一些复杂度。
那通常来说呢多租户的做法有三种。
那第一呢是完全独立的设计，每个租户啊有自己完全独立的服务和数据。
那第二呢是独立的数据分区，共享的服务就是多租户的服务是共享的。
但是数据呢是分开隔离的那第三呢是共享的服务，共享的数据分区啊，就是每个租户的数据和服务都是共享的这三种方案啊，各有优缺点。
那文中呢有一张图。
通过这张图呢，我们可以看到，如果使用完全独立的方案啊，在开发实现上和资源隔离度方面会非常好。
但成本呢会比较高，计算资源啊也会有一定的浪费。
而如果使用完全共享的方案呢，在资源利用和成本上会非常好，但是开发难度非常大，而且数据和资源隔离啊非常不好。
所以一般来说呢技术方案会使用折装的方案啊，也就是中间方案，服务是共享的啊，数据通过分区来隔离。
而对于一些比较重要的租户呢，则使用完全独立的方式。
呃，但是呢在虚拟化技术非常成熟的今天啊，我们完全可以使用完全独立的方案。
通过底层的虚拟化技术来实现物理资源的共享和成本的节约。
要做好隔离设计，我们需要有以下一些设计上的考量。
那首先呢我们需要定义好隔离业务的大小和力度。
过大和过小都不好，这就需要认真的做业务上的需求和系统分析。
那其次呢，无论是做系统板块，还是多租户的隔离，你都需要考虑系统的复杂度、成本性能，还有资源使用的问题。
找到一个合适的均衡方案，或者分步实施的方案非常重要。
这其中呢需要你定义好，你要什么不要什么。
因为我们啊不可能做出一个什么都能满足的系统，而且呢隔离模式啊还需要配置一些，比如高可用啊、重试啊、异步消息中间件、流控，还有熔断等设计模式的方式配套使用。
另外呢不要忘记了分布式系统中的运维复杂度的提升。
要想驾驭的好呢，还需要很多自动化运维的工具啊，尤其是使用像容器或者虚拟机这样的虚拟化技术，可以帮助我们更方便的管理和对资源更好的利用，否则做出来了也管理不好。
那最后呢你需要一个非常完整的能够看得到所有服务的监控系统。
那这一点呢非常重要。
好了，我们来总结一下今天分享的主要内容。
首先呢我从船体水密舱的设计引出了分布式系统设计中的隔离设计。
然后我介绍了两种常见的隔离方式，一种呢是按照服务种类来隔离。
那另一种呢是按用户隔离。
那在下一节课呢，我们讲述异务通讯设计啊，希望能对你有所帮助。
那欢迎你分享一下你是如何给分布式系统做隔离设计的那文末呢给出了分布式系统设计模式系列文章的目录啊，希望你能在这个列表里啊找到自己感兴趣的内容。