构建基于Linkerd与Cassandra的跨区域多活服务架构

分布式架构

文章字数: 3.5k

阅读时长: 14 分

要为全球用户提供低延迟、高可用的服务，单一数据中心的部署模式很快就会触及物理瓶颈。一个自然演进的方向是跨区域多活架构，即在多个地理位置上部署独立但功能对等的服务单元，共同对外提供服务。然而，这种架构的复杂性并非简单地复制部署单元。核心挑战在于两点：一是如何智能地路由流量，二是如何处理跨区域的数据一致性。任何一个环节处理不当，都可能导致数据错乱或服务雪崩。

定义问题：应用层 vs. 基础设施层

在构建多活架构时，我们面临第一个关键决策：将跨区域的服务发现、流量路由和故障转移逻辑放在哪里？

方案A：应用层自行实现

这是一种“传统”的解决方案。服务实例在启动时向一个全局的注册中心（例如跨区域部署的 Consul 或 Eureka 集群）注册自身信息，并附带地理位置标识。客户端或网关层在请求时，需要：

从注册中心拉取完整的服务列表。
实现复杂的客户端负载均衡算法，例如基于地理位置的就近访问、基于延迟的动态路由。
处理跨区域调用的 mTLS 加密、超时、重试和熔断。
在区域性故障发生时，应用逻辑需要能感知到并主动将流量切换到其他可用区域。

这种方案的弊端非常明显。它将网络拓扑和服务治理的复杂性深度耦合到了业务代码中。每一个需要跨区域调用的服务，都必须引入和维护一套沉重的、与业务无关的基础设施客户端库。这不仅增加了开发心智负担，也使得技术栈的升级和演进变得异常困难。比如，一个 Java 服务使用的库可能在 Python 或 Go 中没有对等的实现，导致异构系统集成成本剧增。在真实项目中，这种复杂性会随着服务数量的增加而指数级膨胀，最终变得不可维护。

方案B：下沉至基础设施（服务网格）

服务网格（Service Mesh）的出现为该问题提供了截然不同的解法。它通过 Sidecar 代理模式，将服务间通信的复杂性从应用中剥离出来，下沉到基础设施层。在这个模型下，应用只需关注本地通信（localhost），而所有关于服务发现、负载均衡、流量加密（mTLS）、重试、熔断、可观测性等能力，都由 Sidecar 透明地接管。

对于多活架构，Linkerd 这样的服务网格通过其多集群（multi-cluster）功能，可以将不同 Kubernetes 集群中的服务虚拟地“拉平”到一个统一的服务网络中。一个区域的服务可以直接调用另一个区域的服务，就像调用本地服务一样，其服务名完全相同。流量的切分、故障转移等策略，则通过声明式的 Kubernetes CRD（TrafficSplit）来定义，完全与应用代码解耦。

最终选择与理由

经过权衡，方案B是显而易见的更优选择。它遵循了我们设计分布式系统的核心原则：关注点分离。业务开发团队应该专注于实现业务价值，而不是解决复杂的网络通信问题。

我们的技术栈选型如下：

服务框架: Scala + Spring Boot。结合了 Scala 语言的强类型、表达式能力和 JVM 生态的成熟度，以及 Spring Boot 带来的快速开发和庞大社区支持。
数据存储: Cassandra。作为一个天然支持多数据中心复制的 NoSQL 数据库，它为我们解决了跨区域数据同步的核心难题。其可调的一致性级别（Tunable Consistency）允许我们在延迟和数据一致性之间做出精细的权衡。
服务网格: Linkerd。以其轻量、高性能和易用性著称。它的多集群功能是实现透明跨区域服务发现和流量控制的关键。

接下来的部分将详细展示如何将这些组件组合起来，构建一个可工作的跨区域多活系统。

核心实现概览

假设我们在 us-west 和 eu-central 两个区域分别部署了一套 Kubernetes 集群。我们的目标是部署一个 metric-service，它可以在两个区域同时接收写入请求，并能从任一区域读取到全局数据。

graph TD
    subgraph "Region: us-west"
        direction LR
        User_US --> Ingress_US[K8s Ingress]
        Ingress_US --> App_US[Pod: metric-service]
        App_US -- localhost --> Sidecar_US[Linkerd Proxy]
        Sidecar_US -- mTLS --> App_EU_Mirror[ServiceMirror for eu-central]
        App_US -- LOCAL_QUORUM --> Cassandra_US[Cassandra Node]
    end

    subgraph "Region: eu-central"
        direction LR
        User_EU --> Ingress_EU[K8s Ingress]
        Ingress_EU --> App_EU[Pod: metric-service]
        App_EU -- localhost --> Sidecar_EU[Linkerd Proxy]
        Sidecar_EU -- mTLS --> App_US_Mirror[ServiceMirror for us-west]
        App_EU -- LOCAL_QUORUM --> Cassandra_EU[Cassandra Node]
    end

    subgraph "Global Infrastructure"
        DNS[GeoDNS] --> User_US
        DNS --> User_EU
        Cassandra_US <--> Cassandra_EU
        App_EU_Mirror -.-> Sidecar_EU
        App_US_Mirror -.-> Sidecar_US
    end

    style App_EU_Mirror fill:#f9f,stroke:#333,stroke-width:2px
    style App_US_Mirror fill:#f9f,stroke:#333,stroke-width:2px

1. Cassandra 跨数据中心配置

Cassandra 的多活能力始于 Keyspace 的复制策略。我们需要使用 NetworkTopologyStrategy，并为每个数据中心（DC）指定副本因子。

-- 在任一集群的 Cassandra 节点上执行此 CQL
CREATE KEYSPACE metrics WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'us-west': '3',
  'eu-central': '3'
} AND durable_writes = true;

USE metrics;

CREATE TABLE metric_data (
    device_id uuid,
    event_time timestamp,
    value double,
    PRIMARY KEY (device_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

NetworkTopologyStrategy: 这是实现多数据中心复制的唯一正确选择。
'us-west': '3', 'eu-central': '3': 这意味着在 us-west 数据中心保存3个副本，在 eu-central 也保存3个副本。任何一个DC的写入都会异步复制到另一个DC。

这里的坑在于，Cassandra 节点的 cassandra-rackdc.properties 文件必须正确配置 dc 和 rack 属性，以使节点能识别自己所属的数据中心。例如，在 us-west 的节点上，配置应为 dc=us-west。

2. Scala 与 Spring Boot 服务实现

服务本身的代码应该对多活拓扑无感知。它只需要连接本地数据中心的 Cassandra 节点即可。

build.sbt 依赖

// build.sbt
ThisBuild / scalaVersion := "2.13.10"
ThisBuild / organization := "com.example"

lazy val root = (project in file("."))
  .settings(
    name := "metric-service",
    version := "0.1.0-SNAPSHOT",
    libraryDependencies ++= Seq(
      "org.springframework.boot" % "spring-boot-starter-web" % "2.7.5",
      "com.datastax.oss" % "java-driver-core" % "4.15.0",
      // Scala-friendly wrapper for future/async handling
      "org.scala-lang.modules" %% "scala-java8-compat" % "1.0.2"
    )
  )

application.yml 配置

# src/main/resources/application.yml
server:
  port: 8080

datastax:
  basic:
    contact-points:
      - "cassandra.cassandra-ns.svc.cluster.local:9042" # 连接本地K8s集群的Cassandra服务
    local-datacenter: "us-west" # **关键配置**: 驱动程序将优先连接此DC的节点
    load-balancing-policy:
      class: DcInferringLoadBalancingPolicy
  advanced:
    control-connection:
      timeout: 5s

注意 local-datacenter 配置，它至关重要。这告诉 Datastax 驱动程序所有查询都应首先路由到本地数据中心的节点，避免了不必要的跨区域网络延迟。在 eu-central 集群部署时，这个值需要被修改为 "eu-central"。这通常通过 CI/CD 流程中的变量替换来实现。

核心业务代码 (MetricRepository.scala & MetricController.scala)

// MetricRepository.scala
package com.example.metricservice.repository

import com.datastax.oss.driver.api.core.cql.{BoundStatement, PreparedStatement, ResultSet, Row}
import com.datastax.oss.driver.api.core.{ConsistencyLevel, CqlSession}
import org.springframework.stereotype.Repository

import java.time.Instant
import java.util.UUID
import scala.concurrent.{ExecutionContext, Future}
import scala.jdk.FutureConverters._

case class MetricData(deviceId: UUID, eventTime: Instant, value: Double)

@Repository
class MetricRepository(session: CqlSession)(implicit ec: ExecutionContext) {

  // 预编译CQL语句是性能优化的关键
  private val insertStmt: PreparedStatement = session.prepare(
    "INSERT INTO metrics.metric_data (device_id, event_time, value) VALUES (?, ?, ?)"
  )
  private val selectStmt: PreparedStatement = session.prepare(
    "SELECT device_id, event_time, value FROM metrics.metric_data WHERE device_id = ? LIMIT 10"
  )

  /**
   * 写入操作使用 LOCAL_QUORUM。
   * 这是多活架构中的一个典型权衡：优先保证本地写入的低延迟和高可用性。
   * 数据会异步复制到其他数据中心。在复制完成前，在其他DC查询可能无法看到最新数据。
   * 如果需要强一致性，可以使用 EACH_QUORUM，但这会以极高的延迟为代价，通常不适用于多活写入。
   * @param data MetricData to insert
   * @return Future[Unit]
   */
  def save(data: MetricData): Future[Unit] = {
    val bound: BoundStatement = insertStmt.bind(data.deviceId, data.eventTime, data.value)
      .setConsistencyLevel(ConsistencyLevel.LOCAL_QUORUM) // 关键点：写入本地法定节点

    session.executeAsync(bound).asScala.map(_ => ())
  }

  /**
   * 读取操作也使用 LOCAL_QUORUM。
   * 这保证了读取请求由本地数据中心处理，获得最佳性能。
   * 这也意味着读取可能会有轻微的延迟（stale read），读到非最新的数据。
   * 对于大部分监控、指标类系统，这种最终一致性是可以接受的。
   * @param deviceId UUID of the device
   * @return Future sequence of MetricData
   */
  def findByDeviceId(deviceId: UUID): Future[Seq[MetricData]] = {
    val bound: BoundStatement = selectStmt.bind(deviceId)
      .setConsistencyLevel(ConsistencyLevel.LOCAL_QUORUM) // 关键点：从本地法定节点读取

    session.executeAsync(bound).asScala.map { rs =>
      val iterator = rs.iterator()
      Iterator.continually(iterator.next()).takeWhile(_ => iterator.hasNext).map(rowToMetric).toSeq
    }
  }

  private def rowToMetric(row: Row): MetricData = {
    MetricData(
      deviceId = row.getUuid("device_id"),
      eventTime = row.getInstant("event_time"),
      value = row.getDouble("value")
    )
  }
}

// MetricController.scala
package com.example.metricservice.controller

import com.example.metricservice.repository.{MetricData, MetricRepository}
import org.slf4j.LoggerFactory
import org.springframework.http.{HttpStatus, ResponseEntity}
import org.springframework.web.bind.annotation._

import java.time.Instant
import java.util.UUID
import scala.concurrent.{ExecutionContext, Future}
import scala.util.{Failure, Success}

@RestController
@RequestMapping(Array("/api/metrics"))
class MetricController(repository: MetricRepository)(implicit ec: ExecutionContext) {

  private val logger = LoggerFactory.getLogger(getClass)

  @PostMapping(Array("/{deviceId}"))
  def recordMetric(@PathVariable deviceId: UUID, @RequestBody body: MetricValue): Future[ResponseEntity[String]] = {
    val metric = MetricData(deviceId, Instant.now(), body.value)
    logger.info(s"Recording metric for device $deviceId")

    repository.save(metric).map { _ =>
      new ResponseEntity("Metric recorded", HttpStatus.CREATED)
    } transform {
      case Success(response) => Future.successful(response)
      case Failure(ex) =>
        logger.error(s"Failed to record metric for $deviceId", ex)
        Future.successful(new ResponseEntity("Internal Server Error", HttpStatus.INTERNAL_SERVER_ERROR))
    }
  }

  @GetMapping(Array("/{deviceId}"))
  def getMetrics(@PathVariable deviceId: UUID): Future[ResponseEntity[AnyRef]] = {
    logger.info(s"Fetching metrics for device $deviceId")
    repository.findByDeviceId(deviceId).map { data =>
      new ResponseEntity(data, HttpStatus.OK)
    }
  }
}

case class MetricValue(value: Double)

这段代码的核心在于 setConsistencyLevel(ConsistencyLevel.LOCAL_QUORUM)。它明确指示 Cassandra 驱动，无论是读还是写，操作只需要在本地数据中心的法定节点（N/2 + 1）确认即可返回成功。这确保了应用的低延迟响应，而跨区域的数据复制则由 Cassandra 在后台异步完成。这是一个典型的可用性（A）和分区容错性（P）优先于强一致性（C）的架构决策，完全符合 CAP 理论。

3. Linkerd 多集群配置与流量切分

现在服务和数据库已经准备就绪，最后一步是配置 Linkerd 来管理跨集群的服务发现和流量。

首先，我们需要在两个集群之间建立 Linkerd 多集群连接。这通常通过 linkerd multicluster link 命令完成，它会生成一个包含凭证的 Link CRD 资源，应用到目标集群中。

操作完成后，us-west 集群就能“看到”eu-central 集群的服务，反之亦然。Linkerd 会为远端集群的服务在本地创建一个“镜像服务”（Service Mirror）。例如，在 us-west 集群中，会有一个名为 metric-service-eu-central 的服务，所有发往这个服务的请求都会被 Linkerd Proxy 通过加密隧道安全地转发到 eu-central 集群中的 metric-service。

服务发现的透明性正是由此实现。但更强大的是流量切分能力。假设我们希望将 5% 的写入流量从 us-west 区域发送到 eu-central 区域进行压力测试或灰度发布。我们只需在 us-west 集群应用一个 TrafficSplit 资源：

# trafficsplit-failover.yaml
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: metric-service-split
  namespace: default
spec:
  # 此 TrafficSplit 应用于名为 "metric-service" 的服务
  service: metric-service
  backends:
    # 95% 的流量流向本地的 metric-service
    - service: metric-service
      weight: 95
    # 5% 的流量流向远端 eu-central 集群的同名服务镜像
    # Linkerd 会自动创建名为 <service-name>-<cluster-name> 的镜像服务
    - service: metric-service-eu-central
      weight: 5

当我们在 us-west 集群应用这个 YAML 后，任何调用 metric-service.default.svc.cluster.local 的请求，都会被 Linkerd Sidecar 拦截。Sidecar 会根据 TrafficSplit 的权重，以 95/5 的比例将请求分发到本地服务实例或 eu-central 的服务实例。这一切对调用方完全透明。应用代码无需任何修改。

在区域性故障演练中，我们可以通过 CI/CD 管道动态地将权重调整为 0 和 100，从而实现秒级的流量无损切换。

架构的扩展性与局限性

这个架构的扩展性非常强。新增一个区域只需重复上述步骤：建立新的 Kubernetes 集群、扩展 Cassandra 数据中心、通过 Linkerd 连接新集群。由于服务治理逻辑已经下沉，业务应用几乎不需要改动。

然而，这个方案并非没有局限性。

首先，成本是显著的。在多个区域运行全套基础设施，包括计算、存储和跨区域数据传输，是一笔不小的开销。

其次，数据一致性模型是基于最终一致性的。虽然这对于很多场景（如指标、日志、社交动态）是可接受的，但对于需要强事务一致性的场景（如金融交易、库存管理），则完全不适用。在这种情况下，必须引入更复杂的分布式事务协议（如 Paxos/Raft 或两阶段提交），或者从业务层面设计以规避跨区域的强一致性需求，但这会大大增加系统的复杂度。

最后，虽然 Linkerd 屏蔽了网络细节，但物理定律无法被屏蔽。跨区域调用始终存在几十到几百毫秒的延迟。将流量切分到远端区域会直接影响这部分用户的响应时间。因此，流量路由策略必须经过精心设计，通常会结合 GeoDNS 等技术，先将用户引导至最近的区域，仅在故障转移或特定业务场景下才进行跨区域调用。

Scala Spring Boot Linkerd Cassandra 服务发现

构建由Jenkins驱动的动态SciPy计算与微前端集成的架构实践

2023-10-27 架构设计

SciPy Micro-frontends Jenkins Couchbase

构建服务于 iOS 与 Angular 的统一 API 网关整合遗留 Rails 单体与 Azure AKS 微服务

2023-10-27 架构设计

Ruby on Rails 微服务 Serverless iOS 开发 Angular Azure AKS API Gateway