微服务是大型架构的核心，下面我重点详解微服务部署@mikechen
微服务多实例部署
在物理主机或虚拟机上部署：多个独立的微服务实例。
如下图所示：
通常每个实例作为一个独立进程运行，使用固定端口或不同子域进行区分。
优点
部署相对直观，资源利用率高，每个实例相对独立，故障隔离相对容易实现。
缺点
横向扩展的粒度和自动化能力有限，依赖运维手工或半自动化工具。
适用场景
小型到中型系统、团队对容器化与编排不熟悉、或初期希望快速落地的场景。
微服务容器化部署
容器化部署将每个微服务封装为一个独立的镜像（Image），并在容器中运行（如Docker）。
|—— Docker Host
├── user-service (container)
├── order-service (container)
├── payment-service (container)
环境一致性：开发、测试、生产完全一致；
轻量快速：启动比虚拟机快得多；
适用场景：中大型团队，已有CI/CD体系，希望提升部署自动化程度。
微服务 Serverless 部署
无服务器架构，将业务逻辑以函数形式部署到云厂商的平。
比如： AWS Lambda、阿里云函数计算，按调用计费并自动扩展。
成本更低，按调用计费；
弹性极强，自动适应高并发；
适用场景：低频任务、事件驱动型系统、API服务、自动化工具。
微服务编排部署
当微服务数量激增后，单纯容器化已不足以支撑规模化运维。
此时就需要 Kubernetes（K8s） 这样的容器编排系统，实现自动化部署、伸缩与负载均衡。
|—— K8s Cluster
├── Pod: user-service
├── Pod: order-service
├── Pod: payment-service
├── Service: 流量路由
├── Ingress: 对外暴露入口
Pod 弹性伸缩（HPA 自动扩容）。
优点：
高可用、高扩展性；
实现真正的云原生部署；
支持混合云与多集群环境。
缺点：
学习曲线较陡；
运维与监控体系要求高。
适用场景：
大型互联网项目、云原生架构、持续交付体系完善的团队。
