架构图在真实流量面前从来都撑不过三秒。Azure上的微服务承诺独立部署、团队自治、细粒度扩缩容和故障隔离——这些好处确实存在，但教程里很少诚实告诉你代价：如果不小心，运维复杂度的增长速度会超过团队扩张速度。

这不是微服务入门指南。而是我们在Azure多个生产系统上构建和运行微服务架构的真实经验——平台哪里做得好、哪里会坑人，以及区分凌晨3点能扛住和会崩盘的系统的具体模式。

打开网易新闻 查看精彩图片

为什么选择Azure？ 它的微服务故事主要围绕三个服务展开：Azure Kubernetes Service（AKS）托管Kubernetes，处理控制平面升级、节点池管理，与Azure生态（AAD、ACR、Monitor）干净集成——跑容器化服务的默认选择。Azure Container Apps是Kubernetes和KEDA之上的更高层抽象，控制力比AKS弱，但运维开销大幅降低，适合想要微服务好处却不想全投Kubernetes的团队。Azure Service Bus则是服务间异步通信的骨干，比自建队列更可靠，内置死信队列、消息会话和重复检测。

AKS和Container Apps的选择是第一个关键决策。我们的经验法则：有专职平台工程师或SRE，选AKS——你最终需要的灵活性它都能给。没有的话，Container Apps能让你保持理智。

服务边界比代码更重要。 最贵的微服务错误不是技术性的——是边界画错了。粒度过细（纳米服务）会造成分布式单体问题：运行时紧耦合，尽管独立部署。你会得到同步的服务调用链，一个慢服务拖垮整个系统的级联延迟。粒度过粗则失去架构好处，白加了运维复杂度却没换来部署独立性。

正确的启发式原则：服务应拥有自己的数据，能独立部署而无需与其他服务协调。如果部署服务A必须同时部署服务B，边界就画错了。领域驱动设计给了这套词汇：限界上下文。每个服务应对应一个限界上下文——有自己数据模型、自己业务规则的领域区域。