看懂架构设计中的服务隔离

写在前面的话：我们在做系统架构设计的时候，经常离不开的一个话题就是进行服务的隔离设计。

那什么是「服务隔离」呢？

顾名思义，它是指将系统按照肯定的准则划分为若干个服务板块，各个板块之间相对独立，无强依赖。当有故障发生时，能将问题和影响隔离在某个板块内部，而不扩散风险，不波及其它板块，不影响整体的系统服务。

其实隔离设计并非软件行业独创，它是借鉴于造船行业。

行业有一个专业术语叫做「舱壁隔离」。利使用舱壁将不同的船舱隔离起来，假如某一个船舱进了水，那么即可以立即封闭舱门，形成舱壁隔离，只损失那一个船舱，其余船舱不受影响，整个船只还是可以正常航行。

一、为什么要做服务隔离设计呢？

我们在做系统设计的时候，必需有一个清楚的认知是：任何软件系统，故障是不可避免的，并且大多数还是不可预测的，因而，我们只能在系统的设计之初就充分的考虑好应对措施，如何在故障发生时，去尽最大可能的止损和减少故障范围。

没有人敢说他的系统是百分百可使用，我们能做的就是，用一切方法去减少故障的影响面，尽可能的去提高系统的整体可使用率。

而把系统分离成子服务，将子服务进行肯定程度隔离的做法，能保证在有不可预测的故障发生时，缩小故障范围的最佳手段。

二、服务隔离应该怎样做？

那在实际项目中，一般通过什么方法去做服务隔离呢？主要有以下两种：

按服务/功能做隔离

按使用户分类隔离

首先说一下按照服务进行隔离的做法。

网上找了一张图，尽管原图的作使用不是使用来表述这个的，但是也相似，将就看吧。

比方上图里面，微博项目可以把 Feed信息流、使用户系统、评论系统 都分拆为独立业务板块，这些板块无论是对外的接口应使用、还是到数据库、究竟层硬件资源都是完全隔离的。其中任何一个板块的故障，理论上都不会影响到其它板块。

再举个例子，假如我们要设计个电商平台，可以将其中的 使用户系统、订单系统、支付系统、仓储系统 都分别进行独立隔离，这样做就是从服务层面实现了故障的隔离效果。

那按照服务隔离有没有弊端呢？有，一定有。

当我们某个功能操作需要关联多个服务板块或者者同时查询所个板块数据的时候，代码写起来就会相对麻烦少量了，其中涉及到多板块调使用的性能问题、数据一致性问题、事物问题等。

不同服务板块之间的交互也会比较复杂少量，由于要做服务隔离，避免服务强依赖，所以板块之间的交互调使用最好是走异步模式，需要通过异步线程或者消息中间件来传递实现。

在进行经营大数据分析的时候，因为数据是散落在不同服务板块的，因而需要做额外的汇聚操作，还得有唯一字段保证数据在不同板块产生的先后顺序。

接下来说一下按使用户隔离的做法。

继续网上找图，尽管原图的作使用不是使用来表述这个的，但是也相似。粉丝又不多，我又懒得画图，将就看吧，多发挥一下想象力，哈哈。

简单一句话解释就是：我们先部署多套一模一样的业务服务，而后将使用户根据肯定的特征去做分类，让不同分类的使用户去访问不同的业务实例，达到分流和隔离的效果。

怎样给使用户分类？

可以使用按照使用户能否VIP、使用户等级、使用户IP等等，方法很多，要结合自己实际业务的特性来做。

其实这也是一种「多租户架构」，在SaaS服务中使用得比较多。

多租户模式有三种形式：

完全的隔离，即服务和数据都是完全独立的。

公共服务、独立数据源，即多个租户是使用的同一台服务程序，但是底层的数据源是独立的。

公使用服务、公使用数据源，即多个租户的服务程序与数据库源都是共享的，不同数据可能会做分区分表来独立。

上述三种方式，从下到上，独立性和安全性越来越高，资源利使用率越来越低，根据业务特性去选择，一般选择折中方案。

另外，功能隔离和使用户隔离 两种方式并非互斥的，是可以结合在一起用的。

三、服务隔离的注意事项

我们在做服务隔离的时候，还是有少量准则和事项需要注意的：

不可越界：能在隔离板块内完成的逻辑，就尽量不要跨板块调使用，减少依赖。

不可共享：数据和资源能独享的就尽量不要共享，不然很容易造成隔离失效。

考虑效率：设计隔离板块的时候，要根据业务情况而定，充分的考虑到未来的拓补结构，减少调使用效率的损失。

考虑颗粒度：隔离板块设计的大小问题，过大和过小都不合适，需充分考虑。

服务的全面监控：既然服务或者使用户进行隔离了，那么系统的复杂度一定是比之前要高了，那么针对多服务的全链路监控是必不可少的。

服务隔离的设计模式能降低依赖服务对整个系统的影响，保护有限的资源不被耗尽，提高了整个系统的可使用性。本文参考了很多其它资料，属于抛砖引玉，希望大家能一起交流，提出更好的架构设计思路。

欢迎工作一到五年的Java工程师朋友们加入Java架构开发：744677563

本群提供免费的学习指导 架构资料 以及免费的解答

不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导