智慧互通（IICT）高级软件架构师

智慧互通（IICT）
  成立：2015年，北京中关村
  阶段：D轮+，1000-9999人
  方向：AI + 智慧交通（计算机视觉 + 智能感知）
  产品线：
    爱通行（AITS）→ 智慧交通
    爱泊车（AIPARK）→ 智慧停车
    领航者（AIPILOT）→ 自动驾驶
  技术：ASER超视线机器人、VSA车态感知、HRS全息道路、IRN智能路网
  荣誉：国家级AI创新平台（智慧交通车态感知）
  覆盖：45+城市，每年服务车次10亿+

① 云网融合能力 → 智慧交通场景天然需要
   路测设备 → 边缘节点 → 云端平台
   确定性网络保证实时性
   → "智慧交通的路侧设备到云端需要低延迟通信，
      我在紫金山做的DetNet/SRv6正好解决这个问题"

② 多租户架构 → 多城市部署天然需要
   智慧互通覆盖45+城市
   每个城市可能是一个"租户"
   → "45个城市的部署可以抽象为多租户架构，
      我的四层隔离模型直接复用"

③ 边缘计算经验 → 路侧设备部署天然需要
   矿山项目的云边协同经验
   → "路侧AI设备的推理下沉到边缘，
      只上传结构化数据到云端，降低带宽成本"

"面试官您好，我是风清扬，10年后端和平台架构经验。

我的核心能力可以用三个关键词概括：

第一个是 云原生平台。
我主导构建了一个服务40+行业租户的企业级PaaS平台，
基于K8s + CNCF生态实现了完整的平台能力——
多租户四层隔离、Dapr微服务治理、Argo工作流编排、
Emissary灰度发布、Prometheus可观测体系。
新租户交付从2周缩短到3天。

第二个是 云网融合。
我在紫金山实验室主导了网云融合平台的架构设计，
基于K8s云原生体系替代传统OpenStack——
KubeVirt管计算、Kube-OVN管网络、Longhorn管存储、
Karmada管多云调度。
核心创新是DetNet Controller，
通过SDN RESTful API实现云网双向联动，
VM迁移后自动重算确定性网络路径。

第三个是 工程效能。
我有20人团队管理经验，
搭建过完整的CI/CD流水线和GitOps发布体系，
制定过技术规范和Code Review制度。

我注意到智慧互通需要建设底层技术平台，
支撑多条产品线的交付——爱通行、爱泊车、领航者。
这和我过去做的多租户PaaS平台本质上是同一个问题：
如何用一个平台支撑多条业务线的快速迭代。
我相信我的经验能直接复用到这个场景中。"

"底层技术平台的核心目标是让业务团队专注业务逻辑，
不用关心基础设施和通用能力。

我认为应该包含8个核心模块：

① 应用托管：代码提交到部署运行的全自动化
② 微服务治理：服务发现、限流熔断、配置中心
③ 发布部署：CI/CD、灰度发布、回滚
④ 弹性伸缩：按需扩缩容、跨云溢出
⑤ 可观测性：监控告警、链路追踪、日志检索
⑥ 安全合规：认证鉴权、策略引擎、审计日志
⑦ 中间件服务：数据库、缓存、消息队列的标准化供给
⑧ 多环境管理：开发/测试/预发/生产环境一致性

在智慧互通的场景下，还需要额外关注：
- 边缘计算能力（路侧设备管理）
- AI推理服务托管（GPU调度）
- 多城市部署（类似多租户）

我之前做的Elevate-SaaS平台覆盖了前8个模块，
云边协同和AI推理在矿山项目中也有实践。"

"我搭建过两套集群：

第一套是aPaaS集群——3 Master + 1 Worker，
基于kubeadm v1.28.2搭建，HAProxy+Keepalived高可用，
Calico网络，Longhorn存储，部署了Dapr、Emissary、
Argo、OPA、Prometheus等全套CNCF组件。

第二套是IaaS集群——3节点混合Master+Worker，
Kube-OVN替代Calico实现VPC隔离，
KubeVirt实现VM管理，
Karmada纳管了自建集群和k3s轻量集群。

规模不算大，但重点是跑通了完整的技术栈。
生产环境的规模化，核心挑战在于：
- 节点弹性（Cluster Autoscaler）
- 跨可用区调度（Pod拓扑分散）
- 资源碎片整理（Descheduler）

如果智慧互通需要支撑45+城市部署，
我建议用Karmada做多集群联邦管理，
每个区域一个集群，中心统一调度。"

"Service Mesh本质上是把微服务治理能力
从SDK下沉到基础设施层。

传统方案是Istio，但它太重了——
每个Pod注入一个Envoy Sidecar，
控制面istiod也很消耗资源。

我选的方案是Dapr，原因有三：

第一，资源占用只有Istio的1/5。
Dapr Sidecar大约50MB内存，Envoy要200MB+。

第二，Dapr解决的问题更多。
Istio只管网络层（mTLS/限流/路由），
Dapr还管应用层（Pub/Sub/状态管理/Binding），
覆盖面更广。

第三，中间件可移植性。
Dapr的Component模型让中间件切换只改YAML不改代码。
从自建机房迁移到公有云，NATS换成云MQ，业务代码零修改。

但如果智慧互通需要更细粒度的网络治理，
比如mTLS强制加密、L7级别的流量观测，
那可以考虑Dapr + Cilium组合——
Dapr管应用层能力，Cilium管网络层能力。

JD里提到了Knative/Serverless，
这块我的理解是用于AI推理场景——
模型推理服务平时缩容到0，有请求时自动拉起，
按实际调用量计费，降低GPU成本。"

"这是平台架构师最核心的职责——
不是每条产品线各搞一套，而是统一底座+差异化配置。

我的方案是三层架构：

第一层：统一基础设施
  所有产品线共用同一个K8s集群（或集群联邦）
  统一的CI/CD流水线、镜像仓库、监控体系
  → 保证基础能力一致

第二层：统一技术规范
  统一的微服务框架（Spring Boot + Dapr）
  统一的API规范（RESTful + 版本管理）
  统一的日志格式、监控指标命名
  统一的发布流程（GitOps + 灰度策略）
  → 保证工程实践一致

第三层：差异化配置
  每条产品线独立的Namespace
  独立的ResourceQuota（资源配额）
  独立的Helm values.yaml（参数不同）
  独立的灰度策略（按产品线灰度）
  → 保证业务灵活性

在智慧互通的场景下：
  爱通行、爱泊车、领航者 三条产品线
  共用同一个平台底座
  通过Namespace+配置差异化隔离
  新产品线上线只需创建Namespace+apply配置
  不需要重新搭建基础设施"

"DevOps落地最大的挑战不是技术，是人和流程。
我的经验是分三步走：

第一步：工具链先行（1个月）
  搭建GitLab CI/CD流水线
  搭建Harbor镜像仓库
  搭建SonarQube代码扫描
  → 先让团队有工具可用

第二步：规范跟进（2个月）
  制定分支管理规范（GitFlow/Trunk-based）
  制定Code Review制度（至少1人审核）
  制定发布规范（灰度比例、回滚条件）
  → 用规范约束流程

第三步：自动化收敛（持续）
  Flux GitOps管理所有配置变更
  OPA Gatekeeper拦截不合规的部署
  Prometheus自动化告警
  → 用自动化替代人工检查

我在之前的团队推动过这个过程，
关键经验是：不要一次性推太多规范，
先解决最痛的问题（比如发布出错），
让团队尝到甜头后再逐步推进其他规范。"

"自建K8s和托管K8s的核心区别在于控制面。

托管K8s（ACK/CCE）：
  控制面由云厂商管理，用户只管Worker节点
  优势：省心，不用管etcd/apiserver
  劣势：控制面不可定制，网络受限

自建K8s（我的经验）：
  控制面自己搭建和运维
  优势：完全可控，网络可定制（比如Kube-OVN VPC）
  劣势：运维成本高

对智慧互通来说，我建议混合模式：
  开发测试环境 → 用托管K8s（省成本）
  生产环境 → 自建或托管都可以
  边缘节点 → k3s轻量化部署（路侧设备）
  多集群统一管理 → Karmada联邦

我自建K8s的经验价值在于：
我理解K8s控制面每个组件的工作原理，
出了问题能快速定位是apiserver/scheduler/etcd哪个环节，
这个能力在使用托管K8s时同样重要——
因为Worker节点和网络层的问题，
即使是托管集群也需要自己排查。"

"智慧交通的技术架构我理解是三层：

边缘层：路侧设备（摄像头/雷达/信号机）
  → 本地AI推理，结构化数据上传
  → 对标我的矿山云边协同经验

平台层：统一的技术底座
  → 应用托管、微服务治理、多城市部署
  → 对标我的Elevate-SaaS多租户平台

应用层：多条产品线
  → 爱通行、爱泊车、领航者
  → 每条产品线基于平台快速开发

我的经验复用点：

① 多租户/多城市
   45个城市的部署 ≈ 45个租户
   我的四层隔离模型直接复用
   Karmada按城市/区域调度到就近集群

② 边缘计算
   路侧设备的AI推理下沉到边缘
   和矿山项目的云边协同同一思路
   k3s部署边缘节点，Karmada统一纳管

③ 实时性
   交通信号控制需要低延迟
   和我的DetNet确定性网络场景类似
   边缘到云端的数据通路需要QoS保证

④ AI服务托管
   视觉模型的训练和推理
   GPU资源调度（K8s DRA/Device Plugin）
   模型版本管理和灰度发布"

不要主动提这个问题。如果面试官问，坦然回应：

"学历确实是本科，但我用10年的持续学习和实践弥补了这个差距。
我的技术深度体现在两个方面：

第一，从底层到顶层的完整理解。
从物理网络（SDN/SRv6）到虚拟网络（OVN/eBPF）
到容器编排（K8s）到应用治理（Dapr/Argo），
能做到端到端的架构设计。

第二，2项发明专利证明了技术创新能力。
DetNet确定性网络的云网联动架构，
是我独立设计和实现的。

JD也提到'能力优秀者薪酬可议'，
我理解这也意味着对优秀候选人有一定的灵活度。"

"JD标注的是25-50K，
考虑到我10年经验和P8级别的定位，
我期望在35-40K的范围，具体可以面谈。"

如果追问你现在多少：
"目前年薪40万左右，
来智慧互通主要看重的是平台架构的发展空间
和AI+交通的行业前景。"

JD 里提到了 Serverless 和 Knative，你要准备：

"Knative 解决的核心问题是'按需运行'：
没有请求时缩容到0个Pod，有请求时自动拉起。

它分两个模块：
  Knative Serving → 自动扩缩容（含缩到0）
  Knative Eventing → 事件驱动

在智慧互通的场景下，适合用Knative的是：

① AI推理服务
   不是每时每刻都有识别请求
   用Knative Serving按需拉起推理容器
   → 节省GPU资源成本

② 数据处理流水线
   视频片段上传后触发分析
   用Knative Eventing事件驱动
   → 处理完自动释放资源

③ 报表/分析服务
   只在查询时运行
   → 非高峰时段零资源占用

我目前的项目中Serverless用得不多，
但技术原理是清楚的——
Knative底层还是K8s的Deployment+HPA，
加上Queue Proxy做请求缓冲和并发控制。
如果智慧互通有这个方向的规划，我很愿意深入。"

① "目前技术平台团队有多大规模？
    现在用的技术栈是什么？
    是在现有基础上优化还是从头搭建？"
  → 了解你进去后要做什么

② "多条产品线（爱通行/爱泊车/领航者）
    目前是共用一个技术底座还是各自独立？
    最大的技术痛点是什么？"
  → 展示你对业务的理解

③ "公司对云原生落地的预期节奏是怎样的？
    是先解决某个产品线的问题，
    还是全面推进技术平台建设？"
  → 了解优先级和你的发挥空间

风险1：学历不够（本科 vs 要求硕士）
  应对：JD写了"能力优秀者薪酬可议"，说明有灵活度
       用深度技术能力弥补

风险2：C#/Flutter 不会
  应对：JD 标签里有 C#/Flutter，但这可能是现有团队的技术栈
       你可以说"我的主力是Java/Go，但技术栈切换
       对架构师来说不是核心障碍，核心是架构设计能力"

风险3：没有大厂经验
  应对：强调"服务过民生银行/中石化/紫金山实验室等头部企业"
       虽然是外包形式，但做的是核心系统

风险4：规模不够大
  应对："我的集群规模不算大，但跑通了完整技术栈。
       规模化的关键是架构设计正确，
       比如Karmada联邦、HPA弹性这些我都实践过。"

风险5：薪资 25-50K，你期望 35-40K
  应对：这个范围内，合理。不要开口就要顶薪。

□ 再看一遍自我介绍，出声练一遍（3分钟内）
□ 记住公司关键词：智慧交通/车态感知/45城市/10亿车次/D轮
□ 记住 JD 关键词：底层技术平台/多产线/K8s/Service Mesh/Serverless/DevOps
□ 准备好简历纸质版（如果线下）
□ 准备好要问面试官的3个问题
□ 手机调静音
□ 提前10分钟到