阿里Skill架构实战：如何设计高可用的技能服务系统

4次阅读

没有评论

共计 2313 个字符，预计需要花费 6 分钟才能阅读完成。

在构建像阿里 Skill 这样的大型技能服务平台时，开发者经常会遇到几个典型的高并发问题。这些问题如果不妥善解决，会导致系统稳定性下降，甚至直接影响用户体验。

状态不一致问题 ：当多个请求同时修改同一个技能状态时，如果没有适当的并发控制，很容易出现状态覆盖或混乱的情况。例如，一个技能正在执行中，却被另一个请求误判为可执行状态。
重复执行问题 ：在网络不稳定的情况下，客户端可能会重试请求，导致同一个技能被多次触发执行。这不仅浪费系统资源，还可能造成业务逻辑错误。
系统过载问题 ：在流量高峰期，大量并发请求可能导致系统资源耗尽，进而引发级联故障，影响整个系统的可用性。

针对上述问题，我们需要选择合适的分布式解决方案。以下是几种常见方案的对比分析：

分布式锁方案
Redis：基于内存，性能高，适合读多写少场景
ZooKeeper：强一致性保证，适合对一致性要求高的场景
事务消息方案
适用于异步处理场景
可以实现最终一致性
对系统性能影响较小

在阿里 Skill 架构中，我们主要采用 Redis+Lua 的方案，因为它在性能和一致性之间取得了很好的平衡。

通过 Redis 的原子性操作配合 Lua 脚本，我们可以确保技能状态切换的原子性。以下是关键实现思路：

-- Lua 脚本示例：原子化状态切换
local key = KEYS[1]
local expected = ARGV[1]
local newValue = ARGV[2]

local current = redis.call('GET', key)
if current == expected then
    redis.call('SET', key, newValue)
    return 1
else
    return 0
end

为了防止重复执行，我们使用 Snowflake 算法生成唯一 ID 作为请求标识：

// Java 代码示例：生成请求 ID
public class RequestIdGenerator {
    private final long datacenterId;
    private final long workerId;
    private long sequence = 0L;

    // 构造方法等代码省略...

    public synchronized long nextId() {long timestamp = System.currentTimeMillis();

        if (timestamp < lastTimestamp) {throw new RuntimeException("Clock moved backwards");
        }

        if (lastTimestamp == timestamp) {sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {timestamp = tilNextMillis(lastTimestamp);
            }
        } else {sequence = 0L;}

        lastTimestamp = timestamp;

        return ((timestamp - twepoch) << timestampLeftShift)
                | (datacenterId << datacenterIdShift)
                | (workerId << workerIdShift)
                | sequence;
    }
}

我们使用 Sentinel 来实现熔断和降级：

// Sentinel 配置示例
@Configuration
public class SentinelConfig {

    @Bean
    public DegradeRule degradeRule() {DegradeRule rule = new DegradeRule();
        rule.setResource("executeSkill");
        rule.setGrade(RuleConstant.DEGRADE_GRADE_RT);
        rule.setCount(100);  // 响应时间阈值 (ms)
        rule.setTimeWindow(10);  // 熔断时长 (s)
        rule.setRtSlowRequestAmount(5);  // 最小请求数
        rule.setMinRequestAmount(5);
        return rule;
    }
}

我们进行了基准测试，结果如下：