本文转载自公众号不止思考
我们在做系统架构设计的时候,经常离不开的一个话题就是进行服务的隔离设计。
那什么是「服务隔离」呢? 顾名思义,它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖。当有故障发生时,能将问题和影响隔离在某个模块内部,而不扩散风险,不波及其它模块,不影响整体的系统服务。
其实隔离设计并非软件行业独创,它是借鉴于造船行业。
如上图,造船行业有一个专业术语叫做「舱壁隔离」。利用舱壁将不同的船舱隔离起来,如果某一个船舱进了水,那么就可以立即封闭舱门,形成舱壁隔离,只损失那一个船舱,其他船舱不受影响,整个船只还是可以正常航行。
我们在做系统设计的时候,必须有一个清楚的认知是:任何软件系统,故障是不可避免的,并且大多数还是不可预测的,因此,我们只能在系统的设计之初就充分的考虑好应对措施,如何在故障发生时,去尽最大可能的止损和减少故障范围。
没有人敢说他的系统是百分百可用,我们能做的就是,使用一切方法去减少故障的影响面,尽可能的去提高系统的整体可用率。
而把系统分离成子服务,将子服务进行一定程度隔离的做法,能保证在有不可预测的故障发生时,缩小故障范围的最佳手段。
那在实际项目中,一般通过什么方法去做服务隔离呢?主要有以下两种:
首先说一下按照服务进行隔离的做法。
网上找了一张图,虽然原图的作用不是用来表述这个的,但是也类似,将就看吧。
比如上图里面,微博项目可以把 Feed信息流、用户系统、评论系统 都分拆为独立业务模块,这些模块无论是对外的接口应用、还是到数据库、到底层硬件资源都是完全隔离的。其中任何一个模块的故障,理论上都不会影响到其它模块。
再举个例子,如果我们要设计个电商平台,可以将其中的 用户系统、订单系统、支付系统、仓储系统 都分别进行独立隔离,这样做就是从服务层面实现了故障的隔离效果。
那按照服务隔离有没有弊端呢?有,肯定有。
接下来说一下按用户隔离的做法。
继续网上找图,虽然原图的作用不是用来表述这个的,但是也类似。粉丝又不多,我又懒得画图,将就看吧,多发挥一下想象力,哈哈。
简单一句话解释就是:我们先部署多套一模一样的业务服务,然后将用户根据一定的特征去做分类,让不同分类的用户去访问不同的业务实例,达到分流和隔离的效果。
怎么给用户分类? 可以用按照用户是否VIP、用户等级、用户IP等等,方法很多,要结合自己实际业务的特性来做。
其实这也是一种「多租户架构」,在SaaS服务中用得比较多。 多租户模式有三种形式:
上述三种方式,从下到上,独立性和安全性越来越高,资源利用率越来越低,根据业务特性去选择,一般选择折中方案。
另外,功能隔离和用户隔离 两种方式并非互斥的,是可以结合在一起使用的。
我们在做服务隔离的时候,还是有一些原则和事项需要注意的:
服务隔离的设计模式能降低依赖服务对整个系统的影响,保护有限的资源不被耗尽,提高了整个系统的可用性。本文参考了很多其它资料,属于抛砖引玉,希望大家能一起交流,提出更好的架构设计思路。