【海量之道】海量之道之SET模型

本文介绍了set模型。

 

 

 

一 提供海量服务时面对的场景

 

场景1:如何令黄村机房的TWS机器访问黄村机房的APP服务,避免TWS跨机房调用永丰机房的APP机器?

场景2:DB和Redis如何实现快慢分离,读写分离,加速读取速度,改善用户体验?

场景3:如何实现单节点错误不影响全局服务,防止单点失效造成全局服务挂掉?


场景4:如何实现用户暴增或业务增加导致的机器负载过高性能下降问题?

 

 

二 SET模型是什么

 

SET模型是在系统设计过程中,根据业务特征为进行规模化扩容或部署而建立的基础资源模型,一种工程化、规模化设备容量建设单位。SET模型的核心是用户模型、容量模型,其主要有以下三个特性:

1 高度标准化:充分考虑各种不同的环境以及场景,综合成本、效率多个方面的要求。

2 高度规格化:充分考虑适用环境的一些要求,提供有限种规格。

3 高度模块化:强调的是麻雀虽小五脏俱全

 

 

 

三 SET模型能做什么

 

3.1 有效防止故障扩散、单点失效

利用SET思想将一个服务按用户范围分成不同的小单元,每个小单元(SET)具备全部业务服务能力,当一个SET发生故障时候,只影响这一小部分用户从实现到有效防止故障扩散。

在带有容错机制的SET架构中,在SET之间增加容错处理,当一个SET发生故障时,使用类似一致性哈希的算法,调用方可以自动切换到下一个SET来存储,并且将新的位置记录在index上以实现高效容错。

3.2 实现海量服务的高效运营

SET模块就像一个集装箱,把各模块标准化、模块化、规模化,它为海量服务运营,特别是设备管理、网络架构,提供了宏观运营支撑框架,从而极大提高了海量服务运营效率。

以电商的SET模型为例,从接入层开始,数据开始sticky,按订单号路由,即按单号分SET,同一个SET尽可能在一个IDC 里,减少模块间调用的耗时,在同一个SET内,逻辑层任何一台机器,调用方可实时摘除,如果是数据层发生故障,先在接入层,把新产生的订单号屏蔽有故障对应的SET编号,比如,SET1 数据库出现故障,为了避免在故障的SET1 上继续产生新的支付请求,在订单生成器直接跳过SET1的单号规则,把新请求导入其它SET。只有未完成的订单会提示故障,稍后恢复阻止了故障引发的进一步恶化。在故障DB上的数据,通过备机与业务逻辑层的数据核对,完成数据一致性的修复。

3.3 应对用户及业务增加带来的服务压力

使用SET模型可以实现服务的动态伸缩,适应业务的增长。在微信手Q的后台服务框架中,相应的TWS请求APP服务时,我们使用SET模型服务以实现压力均分、同机房接入、动态增减APP服务器以实现业务变更需要、用户增长需要。

 

3.4 实现快慢分离、读写分离

使用SET模型可以方便的管理服务资源,有效实现服务的快慢分离,避免轻量级服务与重量级服务需求杂糅请求到同一服务点,高效避免了请求拥塞和拒绝服务的发生。

使用SET模型还可以做到读写分离,对DB或Redis的读写实施分离,以实现读写互不干扰、提高海量读取服务速度与质量的目标。

3.5 实际场景分享(微信和手Q如何使用SET模型容灾以确保高可用性)

首先是SET标准化。SET是标准业务部署模块,接入层、逻辑层和存储层标准化成不同的SET。

每个SET内都有固定数量的服务器和标准服务容量。譬如,上海XX接入SET设计容量XXX万用户,当前用户数为XXX万,离警戒水位还有XX%,XX小时后可进入扩容点。

SET都具有自动化部署能力,几百台服务器的SET部署时间小于10分钟。SET按单元分布在不同城市之间。每个重点城市都会部署许多套接入SET,逻辑SET和存储SET。

第三,SET间、城市间、区域间都具备全网调度能力。用户到接入SET的调度通过GLBS来切换,譬如接入SET会有许多个VIP,通过域名服务变更VIP就可以把用户请求从天津切到上海。

接入SET到逻辑SET,或逻辑SET到存储SET的访问则通过内部名字服务系统来切换。这样当任何一个IDC或某城市出现问题时,运维人员通过调度可以在几分钟内把流量切到正常的SET,甚至可以通过调度系统做到自动化切换。

第四,存储层的多地同步。存储层会在三地以上部署多套,譬如华南、华中和华北各部署一套存储SET。有写请求时先写华南SET,写成功后通过同步中心把数据同步到华中和华北SET,通过最终一致性保证数据保存在多地存储。数据在三地同步最长时间才几千毫秒,因此用户对数据的不一致基本无感知。

 

 

 

 

四 应用SET模型到实际项目

 

 

以【金手指项目】为例,本节将对上述模型应用进行列举介绍,并回答开始的四个问题

下图是项目整体的SET服务配置

4.1 TWS访问相同机房APP服务问题

使用SET模型服务可以很简单的实现同机房的服务调用,防止跨地域调用带来的各种问题,下图是IDC的APP服务机的SET配置

图中人为的将不同机房的机器进行SET划分,将APP机器划分为黄村、永丰、灰度机三个集合,对应的TWS机器也进行相应划分,如下图:

如此即可将不同机房的TWS对应不同机房的APP以实现服务调用,即TWS的SET0集合的黄村机器调用APP的SET0集合的黄村机器;TWS的SET1集合的永丰机器调用APP的SET1集合的永丰机器;TWS灰度机访问APP灰度机。下面两张图分别是机房的配置情况及同机房TWS访问相同位置APP的模型:

目前只有在异常情况或测试情况下才会配置TWS跨机房访问APP。

4.2 读写分离

应对DB、Redis的读写分离问题,可以将APP服务机划分为DB、Redis读访问机和写访问机两个服务组。

【金手指项目】中我们需要对DB进行读取和非读取划分,因此我们将APP划分为两组:DB访问组、DB隔离组,如下图:

上图所示APP机器无DB读取权限,仅用于接收TWS用户获取已生成数据的请求;

上图所示APP机器有DB读取权限,用于接收管理端、Daemon端的生成规则关键词请求,该请求需要访问数据库获取黑名单、规则详情等信息,并生成规则下关键词以存储或返回管理端。

上述DB权限不同的服务被被调程序分别调用以实现相应服务,将两个权限组的机器再进行地区SET划分:SET0是黄村机房机器,SET1是永丰机房机器,SET2是灰度机,以实现区域隔离,加速访问效率。下图是对应请求服务的TWS机器的SET划分。

4.3 实现容错、预防单点失效

根据上述图表,每个SET有至少一个以上机器可供使用,SET中设置多机器即可实现不同TWS对应APP的SET中的不同机器获取服务,以防止单台服务机失效问题

4.4 应对业务变化、用户增加

对于业务变化问题,如图所示

项目后期,由于IDC机器不能根据域名访问相应JSS机器拉取数据,根据需要增加了HTTP服务SET,如图橙色和浅紫色所示,使用该服务可以令相应APP机器访问JSS服务器82号机。

对于用户增加业务增加问题,我们也可以相同的增加相应服务SET或增加SET中的机器数量以适应业务变更,同样的当活动结束需求降低,可以摘除部分SET内的机器或整体摘除服务。

4.5 关于监听端口

SET集合的端口是用于被调的,即该端口用于监听并提供来自于该端口的请求服务,因此APP的SET集合的端口应该向上级申请,并实现绝对独立,而TWS不用于向APP提供服务,所以其监听端口无用,但是该端口号不能重合现有服务,防止其阻塞TWS正常服务的监听。

4.6 写在最后

其实SET模型只是一种解耦、内聚的思想,用于方便操作和业务需要,应该因地制宜的使用,就如上图的Daemon服务机SET组,仅用于Daemon服务调用单台机器以实现每天刷新当天最新数据。

本文介绍了set模型。

 

 

 

一 提供海量服务时面对的场景

 

场景1:如何令黄村机房的TWS机器访问黄村机房的APP服务,避免TWS跨机房调用永丰机房的APP机器?

场景2:DB和Redis如何实现快慢分离,读写分离,加速读取速度,改善用户体验?

场景3:如何实现单节点错误不影响全局服务,防止单点失效造成全局服务挂掉?


场景4:如何实现用户暴增或业务增加导致的机器负载过高性能下降问题?

 

 

二 SET模型是什么

 

SET模型是在系统设计过程中,根据业务特征为进行规模化扩容或部署而建立的基础资源模型,一种工程化、规模化设备容量建设单位。SET模型的核心是用户模型、容量模型,其主要有以下三个特性:

1 高度标准化:充分考虑各种不同的环境以及场景,综合成本、效率多个方面的要求。

2 高度规格化:充分考虑适用环境的一些要求,提供有限种规格。

3 高度模块化:强调的是麻雀虽小五脏俱全

 

 

 

三 SET模型能做什么

 

3.1 有效防止故障扩散、单点失效

利用SET思想将一个服务按用户范围分成不同的小单元,每个小单元(SET)具备全部业务服务能力,当一个SET发生故障时候,只影响这一小部分用户从实现到有效防止故障扩散。

在带有容错机制的SET架构中,在SET之间增加容错处理,当一个SET发生故障时,使用类似一致性哈希的算法,调用方可以自动切换到下一个SET来存储,并且将新的位置记录在index上以实现高效容错。

3.2 实现海量服务的高效运营

SET模块就像一个集装箱,把各模块标准化、模块化、规模化,它为海量服务运营,特别是设备管理、网络架构,提供了宏观运营支撑框架,从而极大提高了海量服务运营效率。

以电商的SET模型为例,从接入层开始,数据开始sticky,按订单号路由,即按单号分SET,同一个SET尽可能在一个IDC 里,减少模块间调用的耗时,在同一个SET内,逻辑层任何一台机器,调用方可实时摘除,如果是数据层发生故障,先在接入层,把新产生的订单号屏蔽有故障对应的SET编号,比如,SET1 数据库出现故障,为了避免在故障的SET1 上继续产生新的支付请求,在订单生成器直接跳过SET1的单号规则,把新请求导入其它SET。只有未完成的订单会提示故障,稍后恢复阻止了故障引发的进一步恶化。在故障DB上的数据,通过备机与业务逻辑层的数据核对,完成数据一致性的修复。

3.3 应对用户及业务增加带来的服务压力

使用SET模型可以实现服务的动态伸缩,适应业务的增长。在微信手Q的后台服务框架中,相应的TWS请求APP服务时,我们使用SET模型服务以实现压力均分、同机房接入、动态增减APP服务器以实现业务变更需要、用户增长需要。

 

3.4 实现快慢分离、读写分离

使用SET模型可以方便的管理服务资源,有效实现服务的快慢分离,避免轻量级服务与重量级服务需求杂糅请求到同一服务点,高效避免了请求拥塞和拒绝服务的发生。

使用SET模型还可以做到读写分离,对DB或Redis的读写实施分离,以实现读写互不干扰、提高海量读取服务速度与质量的目标。

3.5 实际场景分享(微信和手Q如何使用SET模型容灾以确保高可用性)

首先是SET标准化。SET是标准业务部署模块,接入层、逻辑层和存储层标准化成不同的SET。

每个SET内都有固定数量的服务器和标准服务容量。譬如,上海XX接入SET设计容量XXX万用户,当前用户数为XXX万,离警戒水位还有XX%,XX小时后可进入扩容点。

SET都具有自动化部署能力,几百台服务器的SET部署时间小于10分钟。SET按单元分布在不同城市之间。每个重点城市都会部署许多套接入SET,逻辑SET和存储SET。

第三,SET间、城市间、区域间都具备全网调度能力。用户到接入SET的调度通过GLBS来切换,譬如接入SET会有许多个VIP,通过域名服务变更VIP就可以把用户请求从天津切到上海。

接入SET到逻辑SET,或逻辑SET到存储SET的访问则通过内部名字服务系统来切换。这样当任何一个IDC或某城市出现问题时,运维人员通过调度可以在几分钟内把流量切到正常的SET,甚至可以通过调度系统做到自动化切换。

第四,存储层的多地同步。存储层会在三地以上部署多套,譬如华南、华中和华北各部署一套存储SET。有写请求时先写华南SET,写成功后通过同步中心把数据同步到华中和华北SET,通过最终一致性保证数据保存在多地存储。数据在三地同步最长时间才几千毫秒,因此用户对数据的不一致基本无感知。

 

 

 

 

四 应用SET模型到实际项目

 

 

以【金手指项目】为例,本节将对上述模型应用进行列举介绍,并回答开始的四个问题

下图是项目整体的SET服务配置

4.1 TWS访问相同机房APP服务问题

使用SET模型服务可以很简单的实现同机房的服务调用,防止跨地域调用带来的各种问题,下图是IDC的APP服务机的SET配置

图中人为的将不同机房的机器进行SET划分,将APP机器划分为黄村、永丰、灰度机三个集合,对应的TWS机器也进行相应划分,如下图:

如此即可将不同机房的TWS对应不同机房的APP以实现服务调用,即TWS的SET0集合的黄村机器调用APP的SET0集合的黄村机器;TWS的SET1集合的永丰机器调用APP的SET1集合的永丰机器;TWS灰度机访问APP灰度机。下面两张图分别是机房的配置情况及同机房TWS访问相同位置APP的模型:

目前只有在异常情况或测试情况下才会配置TWS跨机房访问APP。

4.2 读写分离

应对DB、Redis的读写分离问题,可以将APP服务机划分为DB、Redis读访问机和写访问机两个服务组。

【金手指项目】中我们需要对DB进行读取和非读取划分,因此我们将APP划分为两组:DB访问组、DB隔离组,如下图:

上图所示APP机器无DB读取权限,仅用于接收TWS用户获取已生成数据的请求;

上图所示APP机器有DB读取权限,用于接收管理端、Daemon端的生成规则关键词请求,该请求需要访问数据库获取黑名单、规则详情等信息,并生成规则下关键词以存储或返回管理端。

上述DB权限不同的服务被被调程序分别调用以实现相应服务,将两个权限组的机器再进行地区SET划分:SET0是黄村机房机器,SET1是永丰机房机器,SET2是灰度机,以实现区域隔离,加速访问效率。下图是对应请求服务的TWS机器的SET划分。

4.3 实现容错、预防单点失效

根据上述图表,每个SET有至少一个以上机器可供使用,SET中设置多机器即可实现不同TWS对应APP的SET中的不同机器获取服务,以防止单台服务机失效问题

4.4 应对业务变化、用户增加

对于业务变化问题,如图所示

项目后期,由于IDC机器不能根据域名访问相应JSS机器拉取数据,根据需要增加了HTTP服务SET,如图橙色和浅紫色所示,使用该服务可以令相应APP机器访问JSS服务器82号机。

对于用户增加业务增加问题,我们也可以相同的增加相应服务SET或增加SET中的机器数量以适应业务变更,同样的当活动结束需求降低,可以摘除部分SET内的机器或整体摘除服务。

4.5 关于监听端口

SET集合的端口是用于被调的,即该端口用于监听并提供来自于该端口的请求服务,因此APP的SET集合的端口应该向上级申请,并实现绝对独立,而TWS不用于向APP提供服务,所以其监听端口无用,但是该端口号不能重合现有服务,防止其阻塞TWS正常服务的监听。

4.6 写在最后

其实SET模型只是一种解耦、内聚的思想,用于方便操作和业务需要,应该因地制宜的使用,就如上图的Daemon服务机SET组,仅用于Daemon服务调用单台机器以实现每天刷新当天最新数据。

转载于:https://www.cnblogs.com/w10234/p/5497064.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值