为什么架构设计要进行服务隔离?

前言

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

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

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

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

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

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

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

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

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

二、服务隔离应该怎么做?

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

按服务/功能做隔离

按用户分类隔离

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

网上找了一张图,虽然原图的作用不是用来表述这个的,但是也类似,将就看吧。

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

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

那按照服务隔离有没有弊端呢?有,肯定有!

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

2、不同服务模块之间的交互也会比较复杂一些,因为要做服务隔离,避免服务强依赖,所以模块之间的交互调用最好是走异步模式,需要通过异步线程或消息中间件来传递实现。

3、在进行运营大数据分析的时候,由于数据是散落在不同服务模块的,因此需要做额外的汇聚操作,还得有唯一字段保证数据在不同模块产生的先后顺序。

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

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

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

怎么给用户分类?

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

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

多租户模式有三种形式:

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

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

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

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

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

三、服务隔离的注意事项

我们在做服务隔离的时候,还是有一些原则和事项需要注意的:

1、不可越界:能在隔离模块内完成的逻辑,就尽量不要跨模块调用,减少依赖。

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

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

4、考虑颗粒度:隔离模块设计的大小问题,过大和过小都不合适,需充分考虑。

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

总结

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

原文地址:http://blog.51cto.com/13732225/2161504

时间: 2024-10-11 04:00:44

为什么架构设计要进行服务隔离?的相关文章

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

前言 我们在做系统架构设计的时候,经常离不开的一个话题就是进行服务的隔离设计. 那什么是「服务隔离」呢? 顾名思义,它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖.当有故障发生时,能将问题和影响隔离在某个模块内部,而不扩散风险,不波及其它模块,不影响整体的系统服务. 其实隔离设计并非软件行业独创,它是借鉴于造船行业.行业有一个专业术语叫做「舱壁隔离」.利用舱壁将不同的船舱隔离起来,如果某一个船舱进了水,那么就可以立即封闭舱门,形成舱壁隔离,只损失那一个船舱,其他船

架构设计之「服务限流」

上一篇我们聊过了架构设计中的「服务隔离」模式,今天我们继续来探索一下在分布式系统架构中的另一个常用的设计:服务限流.那么,什么是「服务限流」呢? 在解释「服务限流」之前,我们来看一下前些时间网上很火的一个段子,说的是新浪微博的一名工程师正在家里办婚礼,突然接到公司的电话要紧急处理线上流量激增的问题,那天应该是某当红明星突然在微博上公布恋情,微博流量突增好几倍,导致系统功能出现不稳定,用户访问不畅.然后这名工程师就只好晾开新娘,在婚礼现场穿着西装打开笔记本调试代码了.当时这名工程师内心肯定是崩溃的

App架构设计经验谈:服务端接口的设计

转自:http://www.jb51.net/article/60796.htm App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉. 安全机制的设计 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息.实现上,大部分都采用token的认证方式,一般流程是: 用户用密码登录成功后,服务器返回token

GPS部标平台的架构设计(五)-地图服务算法库

GPS平台,需要和各种地图打交道,需要解决以下的问题: 1.坐标偏移,这个不用多说,需要将原始坐标加偏,然后在百度地图或谷歌上显示出来,需要注意的是百度地图的加偏是偏上再偏,谷歌.高德地图等是火星坐标: 2.坐标解偏,或者纠偏,这个我们也是需要的,因为当用户在地图上画出的各种区域,标注,发送到后台存储的坐标都是基于地图所采用的坐标系统,因而是偏移的,这就面临一个严重的问题,因为在部标808协议中,对于区域报警,需要将区域的顶点坐标,下发给终端,终端在实际运行中,不断用GPS坐标和区域坐标进行比对

.NET应用架构设计—用户端的防腐层作用及设计

阅读目录: 1.背景介绍 2.SOA架构下的显示端架构腐化 3.有效使用防腐层来隔离碎片服务导致显示端逻辑腐烂 4.剥离服务调用的技术组件让其依赖接口 5.将服务的DTO与显示端的ViewModel之间的转换放入防腐层 5.1.转换逻辑过程化,直接写在防腐层的方法中 5.2.转换逻辑对象化,建立起封装.重用结构,防止进一步腐化 6.防腐层的两种依赖倒置设计方法 6.1.事件驱动(防腐层监听显示逻辑事件) 6.2.依赖注入接口 7.总结 1.背景介绍 随着现在的企业应用架构都在向着SOA方向转变,

软件系统的架构设计

软件系统架构(Software Architecture)是关于软件系统的结构.行为.属性.组成要素及其之间交互关系的高级抽象.任何软件开发项目,都会经历需求获取.系统分析.系统设计.编码研发.系统运维等常规阶段,软件系统架构设计就位于系统分析和系统设计之间.做好软件系统架构,可以为软件系统提供稳定可靠的体系结构支撑平台,还可以支持最大粒度的软件复用,降低开发运维成本.如何做好软件系统的架构设计呢?笔者就这一问题做如下探讨分析. 软件系统架构设计方法步骤 基于体系架构的软件设计模型把软件过程划分

NET架构设计、框架设计系列文章总结

NET架构设计.框架设计系列文章总结 从事.NET开发到现在已经有七个年头了.慢慢的可能会很少写.NET文章了.不知不觉竟然走了这么多年,热爱.NET热爱c#.突然想对这一路的经历进行一个总结. 是时候开始下一阶段的旅途,希望这些文章可以在发挥点价值作用. 架构设计: ElasticSearch大数据分布式弹性搜索引擎使用 (推荐) DDD实施经验分享-价值导向.从上往下进行(圈内第一个吃螃蟹DDD实施方案)(推荐) 软件工程-思考项目开发那些事(一)(推荐) SOA架构设计经验分享-架构.职责

K8S介绍及架构设计

                                              K8S架构设计 跟新服务时,会创建新RS副本机,并创建实例POD,更新完成一个POD实例,旧RS会停掉一个旧实例                   全部更新完成之后架构如下所示 原文地址:https://www.cnblogs.com/CMX_Shmily/p/12095787.html

领域驱动设计的面向服务架构

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店 一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列