十二月 21, 2025
31 分钟阅读

云架构师面试问题:架构、迁移与安全

interview
career-advice
job-search
云架构师面试问题:架构、迁移与安全
Milad Bonakdar

Milad Bonakdar

作者

通过多云设计、云迁移、微服务、灾难恢复、零信任和成本权衡等实用问题,准备云架构师面试。


引言

云架构师面试通常考察你如何做架构取舍:可靠性与成本、托管服务与可移植性、统一标准与团队自治、安全控制与交付速度。好的回答会说明业务目标、约束条件、目标架构、主要风险,以及上线后的运营模型。

使用本指南练习云架构师面试中常见的问题:多云策略、迁移规划、微服务、服务网格、灾难恢复、零信任和成本优化。


多云策略

1. 你如何设计多云策略?

回答: 多云利用多个云服务提供商来实现弹性、成本优化并避免供应商锁定。

关键考虑因素:

Loading diagram...

架构模式:

1. 主动-主动(Active-Active):

  • 工作负载在多个云上同时运行
  • 跨提供商进行负载均衡
  • 最大可用性

2. 主动-被动(Active-Passive):

  • 主云用于生产
  • 辅助云用于灾难恢复
  • 具有成本效益

3. 云无关服务(Cloud-Agnostic Services):

  • 使用 Kubernetes 实现可移植性
  • 使用 Terraform 实现跨云的 IaC(基础设施即代码)
  • 标准化的 CI/CD 管道

挑战:

  • 管理复杂性
  • 数据传输成本
  • 技能要求
  • 一致的安全策略

稀有度: 常见 难度: 困难


2. 你如何计划和执行云迁移?

回答: 云迁移需要仔细的计划、风险评估和分阶段执行。

迁移的 7R 原则:

Loading diagram...

迁移策略:

1. 重新托管(Rehost,Lift and Shift):

  • 用最少改动迁移应用
  • 适合需要快速退出数据中心的场景
  • 迁移后通常还需要优化

2. Relocate:

  • 不改变应用本身,迁移平台或虚拟化工作负载
  • 当目标云提供兼容迁移路径时很有用
  • 验证网络、身份、备份和许可证假设

3. 重新平台化(Replatform):

  • 做有限改动,例如迁移到托管数据库或容器平台
  • 在迁移速度和运营改进之间取得平衡

4. 重构/重新架构(Refactor/Re-architect):

  • 为云原生扩展、韧性或交付速度重新设计
  • 成本和风险最高,应优先用于高价值系统

5. 重新购买(Repurchase):

  • 用 SaaS 替换应用
  • 例如用托管 CRM 平台替换自研 CRM

6. 退役(Retire):

  • 停用不再创造业务价值的应用

7. 保留(Retain):

  • 因合规、延迟、成本或迁移顺序原因暂时保留系统

迁移阶段:

# 迁移评估工具
class MigrationAssessment:
    def __init__(self, application):
        self.app = application
        self.score = 0
    
    def assess_cloud_readiness(self):
        factors = {
            'architecture': self.check_architecture(),
            'dependencies': self.check_dependencies(),
            'data_volume': self.check_data_volume(),
            'compliance': self.check_compliance(),
            'performance': self.check_performance_requirements()
        }
        
        # 计算迁移复杂度
        complexity = sum(factors.values()) / len(factors)
        
        if complexity < 3:
            return "Rehost - 低复杂度"
        elif complexity < 6:
            return "Replatform - 中等复杂度"
        else:
            return "Refactor - 高复杂度"
    
    def generate_migration_plan(self):
        return {
            'phase_1': '评估和规划',
            'phase_2': '概念验证',
            'phase_3': '数据迁移',
            'phase_4': '应用程序迁移',
            'phase_5': '测试和验证',
            'phase_6': '切换和上线',
            'phase_7': '优化'
        }

迁移执行:

1. 评估:

  • 清点应用程序和依赖项
  • 分析成本(TCO,总拥有成本)
  • 识别风险和约束

2. 规划:

  • 为每个应用程序选择迁移策略
  • 定义成功标准
  • 创建回滚计划

3. 试点迁移:

  • 从非关键应用程序开始
  • 验证方法
  • 优化流程

4. 数据迁移:

# 示例:使用 AWS DMS 进行数据库迁移
aws dms create-replication-instance \
    --replication-instance-identifier migration-instance \
    --replication-instance-class dms.t2.medium

# 创建迁移任务
aws dms create-replication-task \
    --replication-task-identifier db-migration \
    --source-endpoint-arn arn:aws:dms:region:account:endpoint/source \
    --target-endpoint-arn arn:aws:dms:region:account:endpoint/target \
    --migration-type full-load-and-cdc

5. 切换策略:

  • 大爆炸(Big Bang): 一次性全部迁移(风险高)
  • 分阶段(Phased): 逐步迁移(更安全)
  • 并行运行(Parallel Run): 同时运行两个环境

风险缓解:

  • 全面测试
  • 自动化回滚程序
  • 性能基准
  • 安全验证
  • 成本监控

稀有度: 非常常见 难度: 中等-困难


微服务架构

3. 你如何设计微服务架构?

回答: 微服务将应用程序分解为小型、独立的服务。

架构:

Loading diagram...

关键原则:

1. 服务独立性:

  • 每个服务拥有自己的数据
  • 独立部署
  • 允许技术多样性

2. 通信:

# 同步(REST API)
import requests

def get_user(user_id):
    response = requests.get(f'http://user-service/api/users/{user_id}')
    return response.json()

# 异步(消息队列)
import pika

def publish_order_event(order_data):
    connection = pika.BlockingConnection(pika.ConnectionParameters('rabbitmq'))
    channel = connection.channel()
    channel.queue_declare(queue='orders')
    channel.basic_publish(
        exchange='',
        routing_key='orders',
        body=json.dumps(order_data)
    )
    connection.close()

3. API 网关:

  • 单一入口点
  • 身份验证/授权
  • 速率限制
  • 请求路由

4. 服务发现:

  • 动态服务注册
  • 健康检查
  • 负载均衡

优点:

  • 独立扩展
  • 技术灵活性
  • 故障隔离
  • 更快的部署

挑战:

  • 分布式系统复杂性
  • 数据一致性
  • 测试复杂性
  • 运营开销

稀有度: 非常常见 难度: 困难


4. 你如何在微服务中实现服务网格?

回答: 服务网格 为服务到服务通信提供基础设施层,处理流量管理、安全性和可观察性。

架构:

Loading diagram...

主要特点:

1. 流量管理:

  • 负载均衡
  • 断路器
  • 重试和超时
  • 金丝雀部署
  • A/B 测试

2. 安全性:

  • mTLS 加密
  • 身份验证
  • 授权策略

3. 可观察性:

  • 分布式追踪
  • 指标收集
  • 访问日志

Istio 实现:

# 用于流量路由的虚拟服务
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        user-type:
          exact: premium
    route:
    - destination:
        host: reviews
        subset: v2
      weight: 100
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

---
# 用于负载均衡的目标规则
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

断路器配置:

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: circuit-breaker
spec:
  host: payment-service
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

mTLS 安全性:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-read
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET"]

使用 Kiali 进行可观察性:

# 安装带有可观察性插件的 Istio
istioctl install --set profile=demo

# 部署 Kiali、Prometheus、Grafana、Jaeger
kubectl apply -f samples/addons/

# 访问 Kiali 仪表板
istioctl dashboard kiali

服务网格比较:

功能IstioLinkerdConsul
复杂性中等
性能良好优秀良好
功能全面基本全面
学习曲线陡峭平缓中等
资源使用中等

何时使用:

  • 共享流量、身份和可观察性策略能够抵消运营复杂性的微服务环境
  • 需要高级流量管理
  • 安全要求(mTLS)
  • 多集群部署
  • 可观察性要求

稀有度: 常见 难度: 困难


设计模式

5. 解释断路器模式以及何时使用它。

回答: 断路器(Circuit Breaker) 模式可以防止分布式系统中的级联故障。

状态:

  1. 关闭(Closed): 正常运行
  2. 打开(Open): 检测到故障,请求快速失败
  3. 半开(Half-Open): 测试服务是否已恢复
from enum import Enum
import time

class CircuitState(Enum):
    CLOSED = "closed"
    OPEN = "open"
    HALF_OPEN = "half_open"

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60, success_threshold=2):
        self.failure_threshold = failure_threshold
        self.timeout = timeout
        self.success_threshold = success_threshold
        self.failures = 0
        self.successes = 0
        self.last_failure_time = None
        self.state = CircuitState.CLOSED
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time > self.timeout:
                self.state = CircuitState.HALF_OPEN
                self.successes = 0
            else:
                raise Exception("断路器已打开")
        
        try:
            result = func(*args, **kwargs)
            self.on_success()
            return result
        except Exception as e:
            self.on_failure()
            raise e
    
    def on_success(self):
        self.failures = 0
        if self.state == CircuitState.HALF_OPEN:
            self.successes += 1
            if self.successes >= self.success_threshold:
                self.state = CircuitState.CLOSED
    
    def on_failure(self):
        self.failures += 1
        self.last_failure_time = time.time()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN

# 用法
breaker = CircuitBreaker()
result = breaker.call(external_api_call, user_id=123)

用例:

  • 外部 API 调用
  • 数据库连接
  • 微服务通信
  • 第三方集成

稀有度: 常见 难度: 中等-困难


事件驱动架构

6. 解释事件驱动架构以及何时使用它。

回答: 事件驱动架构(Event-Driven Architecture,EDA) 使用事件来触发和在解耦的服务之间进行通信。

架构:

Loading diagram...

核心概念:

1. 事件(Event):

  • 发生的不可变的事实
  • 包含相关数据
  • 带有时间戳

2. 事件生产者(Event Producer):

  • 发布事件
  • 不知道消费者

3. 事件消费者(Event Consumer):

  • 订阅事件
  • 异步处理

4. 事件总线/代理(Event Bus/Broker):

  • 路由事件
  • 示例:Kafka、RabbitMQ、AWS EventBridge

Kafka 实现:

from kafka import KafkaProducer, KafkaConsumer
import json
from datetime import datetime
import uuid

# 事件生产者
class OrderEventProducer:
    def __init__(self):
        self.producer = KafkaProducer(
            bootstrap_servers=['localhost:9092'],
            value_serializer=lambda v: json.dumps(v).encode('utf-8')
        )
    
    def publish_order_created(self, order_id, customer_id, items, total):
        event = {
            'event_type': 'OrderCreated',
            'event_id': str(uuid.uuid4()),
            'timestamp': datetime.utcnow().isoformat(),
            'data': {
                'order_id': order_id,
                'customer_id': customer_id,
                'items': items,
                'total': total
            }
        }
        self.producer.send('order-events', value=event)
        self.producer.flush()

# 事件消费者
class InventoryEventConsumer:
    def __init__(self):
        self.consumer = KafkaConsumer(
            'order-events',
            bootstrap_servers=['localhost:9092'],
            value_deserializer=lambda m: json.loads(m.decode('utf-8')),
            group_id='inventory-service'
        )
    
    def process_events(self):
        for message in self.consumer:
            event = message.value
            if event['event_type'] == 'OrderCreated':
                self.reserve_inventory(event['data'])
    
    def reserve_inventory(self, order_data):
        # 保留库存逻辑
        print(f"为订单 {order_data['order_id']} 保留库存")
        # 发布 InventoryReserved 事件

事件溯源模式(Event Sourcing Pattern):

# 存储事件而不是当前状态
class EventStore:
    def __init__(self):
        self.events = []
    
    def append(self, event):
        self.events.append(event)
    
    def get_events(self, aggregate_id):
        return [e for e in self.events if e['aggregate_id'] == aggregate_id]

# 从事件重建状态
class OrderAggregate:
    def __init__(self, order_id):
        self.order_id = order_id
        self.status = 'pending'
        self.items = []
        self.total = 0
    
    def apply_event(self, event):
        if event['type'] == 'OrderCreated':
            self.items = event['data']['items']
            self.total = event['data']['total']
        elif event['type'] == 'OrderPaid':
            self.status = 'paid'
        elif event['type'] == 'OrderShipped':
            self.status = 'shipped'
    
    def rebuild_from_events(self, events):
        for event in events:
            self.apply_event(event)

CQRS(命令查询职责分离):

Loading diagram...

优点:

  • 松耦合
  • 可扩展性
  • 灵活性
  • 审计跟踪(事件溯源)
  • 实时处理

挑战:

  • 最终一致性
  • 事件模式演变
  • 调试复杂性
  • 重复事件处理

用例:

  • 电子商务订单处理
  • 实时分析
  • 物联网数据处理
  • 微服务通信
  • 审计和合规系统

稀有度: 常见 难度: 困难


灾难恢复

7. 你如何设计灾难恢复策略?

回答: DR 确保中断期间的业务连续性。

关键指标:

  • RTO(恢复时间目标): 最大可接受的停机时间
  • RPO(恢复点目标): 最大可接受的数据丢失

DR 策略:

策略RTORPO成本复杂性
备份和恢复小时小时
领航灯分钟分钟中等中等
温备分钟中等
主动-主动接近零或取决于工作负载最高

实施示例:

Loading diagram...

自动化:

# 自动化故障转移脚本
def initiate_failover():
    # 1. 停止写入主数据库
    stop_primary_writes()
    
    # 2. 提升辅助数据库
    promote_secondary_to_primary()
    
    # 3. 更新 DNS
    update_route53_failover()
    
    # 4. 启动 DR 区域服务
    start_dr_services()
    
    # 5. 验证健康状况
    verify_dr_health()
    
    # 6. 通知团队
    send_alert("已完成到 DR 区域的故障转移")

测试:

  • 根据工作负载关键性定期进行 DR 演练
  • 自动化测试
  • 文档化运行手册
  • 事故后审查

稀有度: 非常常见 难度: 困难


安全与合规

8. 你如何在云架构中实施零信任安全?

回答: 零信任(Zero Trust) 假设没有隐含的信任,验证一切。

原则:

  1. 显式验证
  2. 最小权限访问
  3. 假设违规

实施:

Loading diagram...

组件:

1. 身份和访问:

# 示例:条件访问策略
policies:
  - name: "对敏感应用要求 MFA"
    conditions:
      applications: ["finance-app", "hr-system"]
      users: ["all"]
    controls:
      - require_mfa: true
      - require_compliant_device: true
      - allowed_locations: ["corporate-network", "vpn"]

2. 网络分段:

  • 微分段
  • 服务网格(Istio、Linkerd)
  • 网络策略

3. 加密:

  • 静态数据
  • 传输中的数据
  • 端到端加密

4. 持续监控:

  • 实时威胁检测
  • 行为分析
  • 自动化响应

稀有度: 常见 难度: 困难


成本优化

9. 你如何优化跨多个云提供商的成本?

回答: 多云成本优化策略:

1. 工作负载放置:

  • 分析定价模型
  • 考虑数据传输成本
  • 利用区域定价差异

2. 预留容量:

  • AWS 预留实例
  • Azure 预留虚拟机实例
  • GCP 承诺使用折扣

3. 竞价型/抢占式实例:

# 成本比较:填入最新云成本计算器中的值
def compare_options(options):
    return sorted(options, key=lambda option: (
        option["monthly_cost"],
        option["operational_risk"],
        option["commitment_months"]
    ))

4. 监控和治理:

  • 统一的成本仪表板
  • 预算警报
  • 基于标签的成本分配
  • 自动化资源清理

5. 架构优化:

  • 用于可变工作负载的无服务器架构
  • 自动缩放策略
  • 存储分层
  • 用于静态内容的 CDN

稀有度: 非常常见 难度: 中等-困难


结论

云架构师面试更看重实际决策能力,而不是背诵架构图。请准备好解释:

  1. 多云: 为什么某个工作负载需要多个云提供商,以及这会增加哪些复杂性
  2. 迁移: 7R 选项、依赖发现、分阶段切换、回滚和迁移后优化
  3. 微服务: 服务边界、数据所有权、API 契约、韧性和运营成本
  4. 服务网格: 什么时候 mTLS、流量策略和可观察性足以证明额外平台层的价值
  5. 设计模式: 断路器、Saga、CQRS、幂等性、重试和超时
  6. 事件驱动系统: 事件契约、顺序、重复处理、模式演进和最终一致性
  7. 灾难恢复: RTO/RPO、区域策略、运行手册、测试和恢复证据
  8. 安全: 以身份为中心的访问、最小权限、加密、分段、日志和假设已被入侵的思维
  9. 成本优化: 合理规格、承诺折扣、标签、清理闲置资源、数据传输和 FinOps 治理

回答时先说明业务约束,再说清取舍,并解释你会如何在生产环境中验证设计。

Newsletter subscription

真正有效的每周职业建议

将最新见解直接发送到您的收件箱

创建一份让您被录用速度提高60%的简历

在几分钟内,创建一份量身定制的、ATS友好的简历,已证明可以获得6倍以上的面试机会。

创建更好的简历

分享这篇文章

战胜75%的ATS拒绝率

4份简历中有3份从未被人眼看到。我们的关键词优化将您的通过率提高了80%,确保招聘人员真正看到您的潜力。