在 Nomad 上为移动后端实现一个 Serverless Swift WASI 运行时

后端架构

文章字数: 3.3k

阅读时长: 13 分

业务逻辑的动态化是移动端开发一个绕不开的话题。将易变的业务规则硬编码在 Android 应用内，意味着每次调整都需要经历完整的发版、审核、用户更新流程，这在快速迭代的场景下是无法接受的。一个常见的方案是将逻辑移至后端API，但这又引入了另一个问题：后端的服务通常是整体部署的，为了一点小的逻辑变更而重启整个服务，同样存在风险和效率问题。

我们的挑战是：构建一个轻量级、安全隔离且能动态更新的后端逻辑执行环境。它需要满足几个苛刻的条件：

安全沙箱: 客户端触发的逻辑必须在严格隔离的环境中运行，不能影响宿主或其他租户。
语言亲和性: 最好能使用一种内存安全的现代语言，比如 Swift，这能减少很多低级错误。
低运维成本: 整个系统要足够简单，避免引入 Kubernetes 这样复杂的庞然大物。
无状态与 Serverless: 每次执行都是独立的，按需启动，用完即毁，符合 Serverless 的理念。

经过一番技术选型，我们最终敲定了一个非主流但极为高效的组合：Android (Client) -> Nomad (Orchestrator) -> Wasmtime (Runner) -> Swift (Business Logic compiled to WASI)。这里的核心是利用 WebAssembly (WASI) 作为安全沙箱，将 Swift 编写的业务逻辑编译成 .wasm 模块，然后通过 Nomad 的 raw_exec 驱动器，按需启动一个 Wasmtime 进程来执行它。

核心组件：可执行的 Swift-WASI 业务模块

首先，我们需要一个承载业务逻辑的 Swift 模块。这里的关键是，它不能依赖任何特定于 Apple 平台的库，并且必须通过标准输入/输出（stdin/stdout）与外界通信，这是 WASI 模型下最简单的 IPC 方式。

假设我们的业务逻辑是评估一笔贷款申请的初步风险。它接收一个 JSON 格式的申请数据，输出一个包含风险评分的 JSON 结果。

RiskCalculator/Sources/main.swift

import Foundation

// 定义输入结构体，与客户端传入的 JSON 对应
// 在真实项目中，这些模型应该在客户端和WASM模块之间共享
struct LoanApplication: Codable {
    let applicantId: String
    let amount: Double
    let termInMonths: Int
    let creditScore: Int
    let annualIncome: Double
}

// 定义输出结构体
struct RiskAssessment: Codable {
    let applicantId: String
    let riskScore: Double // 0.0 (low) to 1.0 (high)
    let assessmentId: String
    let message: String
}

// 核心业务逻辑：计算风险评分
// 这是一个纯函数，易于测试和维护
func calculateRisk(for application: LoanApplication) -> Double {
    var score: Double = 0.0

    // 规则1：信用分低于600，基础风险分增加0.4
    if application.creditScore < 600 {
        score += 0.4
    }

    // 规则2：贷款金额超过年收入的50%，风险分增加0.3
    let debtToIncomeRatio = application.amount / application.annualIncome
    if debtToIncomeRatio > 0.5 {
        score += 0.3
    }

    // 规则3：贷款期限超过36个月，风险分增加0.1
    if application.termInMonths > 36 {
        score += 0.1
    }

    // 将分数限制在 0.0 到 1.0 之间
    return min(max(score, 0.0), 1.0)
}

// 主执行入口
func main() {
    // 1. 从标准输入读取所有数据
    // 在WASI环境中，stdin是与宿主环境交互的主要方式
    guard let inputData = try? FileHandle.standardInput.readToEnd() else {
        // 如果无法读取输入，则向标准错误输出日志并退出
        let errorMsg = "{\"error\": \"Failed to read from stdin\"}\n"
        FileHandle.standardError.write(errorMsg.data(using: .utf8)!)
        exit(1)
    }

    // 2. 解码输入JSON
    let decoder = JSONDecoder()
    guard let application = try? decoder.decode(LoanApplication.self, from: inputData) else {
        let errorMsg = "{\"error\": \"Failed to decode input JSON\"}\n"
        FileHandle.standardError.write(errorMsg.data(using: .utf8)!)
        exit(2)
    }

    // 3. 执行核心业务逻辑
    let riskScore = calculateRisk(for: application)

    // 4. 构建响应结果
    let result = RiskAssessment(
        applicantId: application.applicantId,
        riskScore: riskScore,
        assessmentId: UUID().uuidString,
        message: riskScore > 0.6 ? "High risk application." : "Standard risk application."
    )

    // 5. 将结果JSON编码并写入标准输出
    let encoder = JSONEncoder()
    encoder.outputFormatting = .prettyPrinted
    guard let outputData = try? encoder.encode(result) else {
        let errorMsg = "{\"error\": \"Failed to encode output JSON\"}\n"
        FileHandle.standardError.write(errorMsg.data(using: .utf8)!)
        exit(3)
    }

    FileHandle.standardOutput.write(outputData)
    // 正常退出
    exit(0)
}

main()

为了编译这个 Swift 文件到 WASI，我们需要 Swift SDK 和 WASI Target。编译过程很简单：

# 假设你已经安装了支持WASI的Swift工具链
# --triple 指定了目标平台为 wasm32-unknown-wasi
swift build --triple wasm32-unknown-wasi -c release

# 编译产物位于 .build/wasm32-unknown-wasi/release/RiskCalculator.wasm
# 我们将它重命名并放到 Nomad Client 节点可以访问的地方，比如一个内部的 artifactory 或者直接放在节点的文件系统上
cp .build/wasm32-unknown-wasi/release/RiskCalculator.wasm /opt/nomad/wasm_modules/risk_calculator_v1.wasm

这里的坑在于，Swift 对 WASI 的支持仍在发展中，并非所有 Foundation 库都能完美工作。例如，网络、多线程等功能会受限。因此，WASM 模块的逻辑最好是计算密集型的纯函数，所有 I/O 通过 stdin/stdout 完成。

调度核心：Nomad Jobspec

Nomad 是整个系统的调度大脑。我们将定义一个参数化的批处理（batch）作业，这意味着它不会常驻运行，而是在被dispatch时才启动，执行一次后就销毁。

这个 Jobspec 的设计是整个方案的精髓。

execute-swift-wasi.nomad.hcl

job "execute-swift-wasi" {
  datacenters = ["dc1"]
  type        = "batch" # 关键：这是一个批处理作业，按需运行

  # 参数化块，允许在 dispatch 时传入变量
  parameterized {
    # payload "required" 表示 dispatch 时必须提供 payload
    payload = "required"
    # 我们允许在 dispatch 时覆盖 wasm_module_name 这个元数据
    meta_required = ["wasm_module_name"]
  }

  group "wasm-runners" {
    count = 1 # 每次 dispatch 只启动一个实例

    task "run-logic" {
      driver = "raw_exec" # 使用 raw_exec 驱动，直接在宿主机上执行命令

      # 这里的坑：确保 Nomad client 节点上安装了 wasmtime
      # 并且 nomad 用户有权限执行它
      config {
        command = "/usr/bin/wasmtime"
        args = [
          # wasmtime 的参数，告诉它要运行哪个模块
          # NOMAD_META_wasm_module_name 会被 dispatch 时传入的元数据替换
          "/opt/nomad/wasm_modules/${NOMAD_META_wasm_module_name}.wasm"
        ]
      }

      # 模板：这是将客户端数据注入WASM模块 stdin 的核心
      template {
        # NOMAD_PAYLOAD 是 dispatch 时传入的整个 payload 内容
        # 我们直接将它作为 stdin 的内容
        data        = "{{ .NOMAD_PAYLOAD }}"
        destination = "local/stdin.txt" # 写入一个本地文件
        change_mode = "signal"
        splay       = "5s"
      }

      # 标准输入重定向
      # 将模板生成的文件内容重定向到任务的标准输入
      stdin = "local/stdin.txt"

      # 资源限制：这是沙箱的关键部分
      # 严格限制每个 WASM 模块可以使用的 CPU 和内存
      resources {
        cpu    = 100 # MHz
        memory = 64  # MB
      }

      # 日志配置：捕获WASM模块的 stdout 和 stderr
      # 这对于调试和结果获取至关重要
      logs {
        max_files     = 2
        max_file_size = 5 # MB
      }
    }
  }
}

这个 HCL 文件定义了我们的 Serverless 执行单元。几个关键点：

type = "batch": 作业执行完后会自动停止并清理。
parameterized: 允许我们通过 API 调用动态地传递要执行的 .wasm 模块名（通过 meta）和输入数据（通过 payload）。
driver = "raw_exec": 直接在 Nomad Client 节点上执行命令，无需 Docker。这带来了更低的启动延迟，但牺牲了一层隔离。WASM本身的沙箱机制弥补了这一点。
template 和 stdin: 这是数据流转的核心。Nomad API 接收到的 payload 被 template 引擎写入一个临时文件，然后通过 stdin 重定向给 wasmtime 进程，最终被 Swift 代码的 FileHandle.standardInput.readToEnd() 读取。
resources: 严格的资源限制是实现多租户安全和成本控制的基础。

客户端集成：Android App 的调用

在 Android 端，我们需要一个机制来触发这个 Nomad 作业。这通常通过一个轻量级的 API 网关或“调度器服务”来完成，它负责认证、鉴权，然后调用 Nomad 的 HTTP API。为了简化示例，我们假设 Android 客户端可以直接（或通过一个简单的代理）调用 Nomad API。

在真实项目中，绝不能让移动客户端直接访问 Nomad API。必须有一个中间层服务。

Android 端 NomadDispatchService.kt (使用 Retrofit)

import okhttp3.RequestBody
import okhttp3.ResponseBody
import retrofit2.Response
import retrofit2.http.Body
import retrofit2.http.Header
import retrofit2.http.POST
import retrofit2.http.Path

// Nomad API 的 dispatch 接口定义
interface NomadApiService {
    @POST("v1/job/{jobId}/dispatch")
    suspend fun dispatchJob(
        @Path("jobId") jobId: String,
        @Header("X-Nomad-Token") token: String?, // Nomad ACL Token
        @Body body: RequestBody
    ): Response<ResponseBody> // Nomad dispatch API 返回 job dispatch ID
}

// 调度请求的封装
data class NomadDispatchRequest(
    // Payload 是一个字符串，这里我们直接传入JSON字符串
    @SerializedName("Payload") val payload: String,
    // Meta 是一个键值对，用于传递额外参数
    @SerializedName("Meta") val meta: Map<String, String>
)

在 ViewModel 或 Repository 中调用

import com.google.gson.Gson
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import okhttp3.MediaType.Companion.toMediaType
import okhttp3.RequestBody.Companion.toRequestBody

class RiskAssessmentViewModel(
    private val nomadApiService: NomadApiService,
    private val gson: Gson
) : ViewModel() {

    private val _assessmentResult = MutableLiveData<Result<RiskAssessment>>()
    val assessmentResult: LiveData<Result<RiskAssessment>> = _assessmentResult

    // 假设的输入数据模型，与Swift端一致
    data class LoanApplication(
        val applicantId: String,
        val amount: Double,
        val termInMonths: Int,
        val creditScore: Int,
        val annualIncome: Double
    )
    
    // ...

    fun submitApplicationForRiskAssessment(application: LoanApplication) {
        viewModelScope.launch {
            _assessmentResult.value = Result.Loading
            try {
                val result = performRemoteAssessment(application)
                _assessmentResult.value = Result.Success(result)
            } catch (e: Exception) {
                // 详尽的错误处理
                _assessmentResult.value = Result.Error(e)
            }
        }
    }

    private suspend fun performRemoteAssessment(application: LoanApplication): RiskAssessment {
        return withContext(Dispatchers.IO) {
            // 1. 准备请求体
            val payloadJson = gson.toJson(application)
            val dispatchRequest = NomadDispatchRequest(
                // Base64 编码 payload 是一个好习惯，可以避免特殊字符问题
                payload = Base64.getEncoder().encodeToString(payloadJson.toByteArray()),
                meta = mapOf("wasm_module_name" to "risk_calculator_v1")
            )
            
            val requestBodyJson = gson.toJson(dispatchRequest)
            val requestBody = requestBodyJson.toRequestBody("application/json".toMediaType())

            // 2. 调用 Nomad API dispatch 作业
            val dispatchResponse = nomadApiService.dispatchJob("execute-swift-wasi", NOMAD_ACL_TOKEN, requestBody)
            if (!dispatchResponse.isSuccessful) {
                throw RuntimeException("Failed to dispatch Nomad job: ${dispatchResponse.errorBody()?.string()}")
            }
            
            // 在真实项目中，这里不是直接等待结果。
            // dispatch 是异步的。你需要轮询 Nomad 的 allocation status API
            // 或者通过 Consul/Event Stream 等机制来获取结果。
            // 为了演示，我们简化为长时间轮询。
            
            // ... 这里需要实现一个轮询逻辑来获取作业的执行结果 ...
            // 作业的 stdout 就是我们的 JSON 响应。
            // 这是一个复杂但关键的部分，需要一个健壮的轮询和结果检索机制。
            // 伪代码:
            // val dispatchId = parseDispatchResponse(dispatchResponse.body())
            // val allocId = pollForAllocationId(dispatchId)
            // val logContent = getLogsForAllocation(allocId, "stdout")
            // return gson.fromJson(logContent, RiskAssessment::class.java)

            // 为了本示例的完整性，我们模拟一个成功的返回
            // 实际实现要复杂得多
            val mockResultJson = """
            {
                "applicantId": "${application.applicantId}",
                "riskScore": 0.4,
                "assessmentId": "mock-uuid-from-server",
                "message": "Standard risk application."
            }
            """
            return@withContext gson.fromJson(mockResultJson, RiskAssessment::class.java)
        }
    }
}

Android 端的难点在于结果的获取。Nomad 的 dispatch 是一个异步操作，它立即返回一个 DispatchID。你需要使用这个 ID 去查询对应的 Allocation 的状态，直到它变为 complete 或 failed。然后，再通过 Allocation Logs API 读取任务的 stdout，这才是 Swift 模块返回的 JSON 结果。这个轮询或回调机制是生产级实现中必须考虑的。

整体架构与数据流

整个系统的协作方式可以通过一个流程图来清晰地展示。

sequenceDiagram
    participant AndroidClient as Android App
    participant ApiGateway as API Gateway/Dispatcher
    participant NomadServer as Nomad Server API
    participant NomadClient as Nomad Client Node
    participant WasmRuntime as Wasmtime Process
    participant SwiftModule as Swift WASI Module

    AndroidClient->>ApiGateway: POST /assess (JSON: LoanApplication)
    ApiGateway->>ApiGateway: 1. Authenticate & Authorize
    ApiGateway->>NomadServer: POST /v1/job/execute-swift-wasi/dispatch 
 Meta: {wasm_module_name: "risk_calculator_v1"} 
 Payload: (Base64 encoded JSON)
    NomadServer->>NomadClient: Schedule task 'run-logic'
    NomadClient->>NomadClient: Create temp file from Payload
    NomadClient->>WasmRuntime: Start process: `wasmtime module.wasm` 
 (stdin redirected from temp file)
    WasmRuntime->>SwiftModule: Execute main()
    SwiftModule->>SwiftModule: Read stdin, process data
    SwiftModule->>WasmRuntime: Write result JSON to stdout
    WasmRuntime->>NomadClient: Process terminates, stdout captured as log
    NomadClient->>NomadServer: Task finished, send logs
    
    Note right of ApiGateway: Meanwhile, Gateway polls Nomad API 
 for allocation status.
    ApiGateway->>NomadServer: GET /v1/allocation/{alloc_id}/logs
    NomadServer-->>ApiGateway: Return stdout log content
    ApiGateway->>AndroidClient: 200 OK (JSON: RiskAssessment)

局限性与未来展望

这个架构虽然优雅且轻量，但并非没有权衡。

冷启动延迟: raw_exec 的启动速度远快于 Docker，但依然存在毫秒到秒级的延迟。对于需要极低延迟的场景，可能需要实现一个预热池（Pool of warm runners），但这会增加复杂性和资源消耗。
结果获取的复杂性: 如前所述，异步作业的结果获取机制需要精心设计。简单的轮询会给 Nomad Server 带来压力，更好的方案是利用 Nomad 的事件流（Event Stream）或集成 Consul 来实现更高效的结果通知。
状态管理: 该方案为纯无状态计算设计。如果业务逻辑需要访问数据库或缓存，需要在 WASI 模块中通过 WASI Sockets (wasi-sockets) 等提案标准来访问网络，或者通过宿主注入文件描述符等更高级的方式，这会显著增加复杂性。
WASI 生态: Swift 对 WASI 的支持虽然可用，但生态系统远不如 Rust 或 Go 成熟。编译时可能会遇到一些意想不到的兼容性问题，尤其是在使用第三方库时。

尽管存在这些局限，这种基于 Nomad 和 WASI 的 Serverless 模式为特定类型的移动后端负载提供了一个极具吸引力的选择。它在运维简单性、安全性、语言灵活性和成本效益之间取得了出色的平衡，尤其适合那些需要频繁更新、计算密集型、无状态的业务逻辑模块。

Android 开发 Serverless Nomad Swift WebAssembly WASI

在GKE上为多租户生成式AI服务构建基于JWT和InfluxDB的安全遥测管道

2023-10-27 云原生

GCP GKE 生成式AI InfluxDB JWT

集成依赖扫描与MLflow构建一个隔离且安全的微服务化模型发布网关

2023-10-27 平台工程

微服务 MLflow CSS Modules 依赖扫描