【弹力设计篇】聊聊隔离设计

为什么需要隔离设计

隔离其实就是Bulkheads，隔板。在生活中隔板的应用主要在船舱中进行设计，目的是为了避免因一处漏水导致整个船都沉下去。可以将故障减少在一定的范围内，而不是整个船体。

从架构演变来说的话，大多数系统都是从一个系统进行拆分出多个子系统，每个子系统之间通过异步通信、HTTP、RPC等方式去完成请求。当系统较多的时候，本身就可以利用这种隔离机制去避免因一个功能导致整个系统的不可用，避免出现多米诺骨牌效应。
具体的方式，一是通过按照服务的种类来分离，二是通过用户类别分离。

按服务的种类来做分离

类比一个互联网金融平台来说，就可以划分成用户、订单、支付、三方系统、风控系统、大数据平台等。

而每个系统基本都会做服务冗余，一般的话都是至少3台服务，这样才可以做成高可用系统。这种从服务到数据库层面就可以完全隔离开。接入层，应用层，存储层。也禁止直接访问其他上下游系统的数据库进行数据的读取。最好是通过API的方式提供相关的数据。

虽然好处可以直接隔离开来，但是如果想要获取多个数据的话，需要访问多个系统进行获取，响应时间会增加，但是整体的吞吐量会提升。
并且多个系统之间的通讯不一定完全都是HTTP请求，可能HTTP、RPC、MQ多种方式进行通信。所以梳理起来比较杂乱。

我实际的经验就是每个公司的落地方案都是不一样的，基本都受限于早起的架构设计，然后在此基础上进行迭代。

大多数公司都是基于这种服务种类进行隔离

按用户请求来做分离

对于付费类型APP，比如视频网站，电商网站 可以根据不同的用户进行提供服务，比如VIP，普通用户。VIP专属于特别通道，而普通用户则直接进行共享同一套系统服务，即使出现网站不可用，也不会导致全部用户服务不可用。这种其实就是多租户模式。
对于多租户架构来说，会引入一些系统设计的复杂度，完全隔离，资源比较浪费，如果共享，程序设计上会比较复杂。
实现方式的话，其实就是服务是否共享，数据是否共享。

• 1.完全独立的设计，服务独立，数据独立。
• 2.数据独立，服务共享。
• 3.服务共享，数据也共享。
  
  可以看到，如果服务和数据都独立，那么隔离度和实现复杂度比较好，但是占用成本和资源共享度比较高。如果是共享的话，隔离度和共享低。开发难度比较高。
  所以一般采用折中的方案，采用服务共享，数据分区。而今天可以采用虚拟化技术来实现物理隔离来降低成本。

隔离设计的重点

隔离设计需要考虑以下问题

• **业务层面：**我们需要对业务足够了解之后，按照一定的拆分粒度进行设计系统，系统过大或者过小都不好。
• **复杂度层面：**无论是系统板块还是多租户的隔离，都需要考虑系统的复杂度、成本、性能、资源使用的问题，找到一个权衡的方案，确定哪些不要，哪些需要。
• **高可用设计层面：**隔离也需要配置一些高可用设计方案，比如 重试&幂等，限流&排队，降级&熔断，异步&隔离等配套使用
• **运维层面：**分布式系统的引入，虽然提升的整体的性能和稳定性，但是也因此带来了更多的问题，比如系统间通讯、运维层面。因此需要配置自动化运维工具，可以使用容器来管理。
• 监控系统，好的系统一定有一双眼睛可以实时监控系统的所有重要指标。这里多说一句，有些人只关注系统的业务数据指标是否正常，我觉得这并不够，而要从系统的各个层面去观测。比如系统层面（CPU、内存、磁盘、网络）中间件层（MySQL、MQ、Redis）应用层（JVM）日志层面，监控报警等多个角度去观测。

总结

好了，今天主要介绍了弹力设计中，隔离设计，所谓隔离也不过是通过将系统间进行按照一定粒度拆分，故障不会蔓延开来。然后聊了两种方式一种是系统板块，另一种多租户方式。最后说了下隔离设计的重点。