【海量之道】海量之道之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服务调用单台机器以实现每天刷新当天最新数据。