2. Azure微服务基础设施选型

在 Azure 上落地微服务，第一步往往不是写业务代码，而是决定“服务跑在哪里”。这个决定会直接影响服务之间怎么发现彼此、怎么调用、怎么限流、怎么加密、怎么观测。AKS、Container Apps、Service Fabric 和 App Service 都能承载微服务，但它们的通信模型差异很大：有的把网络控制权完全交给你，有的把服务发现和流量治理做成平台能力，有的则更偏向传统 Web 应用的通信方式。理解这些差异，才能避免“选错宿主，后期靠补丁硬撑”。

四种宿主的通信能力定位

AKS（Azure Kubernetes Service）提供的是最完整的 Kubernetes 原生通信能力。Pod 之间通过 Service 做稳定访问，ClusterIP 用于集群内东西向流量，Ingress 或 Gateway API 负责南北向入口。服务发现依赖 CoreDNS，配置通过 ConfigMap 和 Secret 注入。更重要的是，AKS 可以接入服务网格（如 Istio、Linkerd）或 Dapr，实现 mTLS、重试、熔断、流量切分和分布式追踪。代价是这些能力需要你自己安装、配置和运维，网络策略、DNS、证书轮换都要纳入日常管理。

Container Apps是托管型容器平台，通信能力“开箱即用”。它内置服务发现：同一环境内的应用可以用应用名直接互访，平台自动注入 DNS 和环境变量。入口分两类：外部入口暴露给公网，内部入口只在环境内可达。Container Apps 原生集成 Dapr，服务调用、发布订阅、状态管理可以通过 sidecar 完成，不需要自己搭消息中间件。它还支持基于 KEDA 的伸缩和基于流量的修订版本切分。适合希望少运维、但仍需要微服务间可靠调用的团队。

Service Fabric是微软早期的微服务运行时，通信模型围绕 Reliable Services 和 Reliable Actors 构建。它提供命名服务（Naming Service）做服务发现，支持有状态服务，通信方式可以是远程过程调用（Remoting）、HTTP、WCF 或自定义协议。Service Fabric 的强项是有状态、低延迟、高吞吐的场景，但它的通信栈和编程模型绑定较深，容器化支持相对有限，新项目选型时通常不是首选。

App Service本质是 Web 应用托管平台，通信以 HTTP/HTTPS 为主。它支持 VNet 集成、私有终结点、混合连接，也能通过 API Management 或 Front Door 做统一入口。但 App Service 没有内置的服务发现和东西向服务网格，服务间调用通常要依赖外部 DNS、API Management 或 Service Bus。它更适合“微服务数量不多、以 HTTP API 为主、团队不想碰 Kubernetes”的场景。

选型决策：从通信需求反推宿主

选型时不要先问“哪个平台更先进”，而要先问“我的服务之间需要什么样的通信”。如果服务数量多、调用关系复杂、需要 mTLS 和细粒度流量切分，AKS 配合服务网格或 Dapr 是最稳妥的。如果团队规模小、希望把服务发现和入口治理交给平台，Container Apps 的性价比最高。如果业务本身有强状态、要求分区和副本内建故障转移，Service Fabric 仍有价值，但要接受它的学习曲线和生态现状。如果只是几个 HTTP API 互相调用，App Service 加 API Management 就足够，不必为了“微服务”三个字引入 Kubernetes。

一个常见的误区是：先用 App Service 快速上线，等调用关系变复杂后再迁移到 AKS。迁移成本往往被低估，因为服务发现、配置注入、健康检查、证书管理都要重做。更务实的做法是在项目初期就明确通信边界：哪些调用是同步 HTTP，哪些是异步消息，哪些需要跨环境隔离。把这些边界画清楚，再对照上表的四列能力，选型就不再是拍脑袋。

一个可执行的选型检查清单

下面这份清单可以直接在选型评审会上逐项确认。每一项都对应通信能力，而不是泛泛的平台功能。

把这张表填完，通常会得到两个候选平台。接下来做一次小规模验证：用真实的一个服务调用链，在候选平台上跑通服务发现、一次失败重试和一次版本切分。验证通过再全面迁移，比直接全量切换风险低得多。选型不是一次性的，随着服务数量和治理要求变化，可以保留从 Container Apps 向 AKS 演进的路径，但前提是通信契约和可观测性从一开始就设计清楚。