微服务和 Serverless 架构（一）

第 1 章讲过服务化：当一个应用里各部分的修改、发布开始互相拖累，就可能需要重新划分服务边界。这一章接着看拆开之后的事——服务怎么互相调用，谁来托管和治理，以及新版本怎么上线。

从单体到微服务

课程把企业应用架构概括成四个阶段。这张表适合对比各自的取舍，不表示每个系统都必须按顺序走一遍：

架构	特征	要处理的问题
单体架构	所有功能打包在一个进程里，一起编译、一起部署	修改和发布互相牵连；团队规模大了，难以独立交付
垂直架构	按业务模块拆成几个独立部署的应用，比如用户、订单、商品子系统	应用之间可能仍直接耦合，或共享数据库，拆开部署不等于解耦
SOA（面向服务架构）	通过服务接口复用业务能力；课程以 ESB（企业服务总线）统一处理协议转换、路由的实现为例	集中式 ESB 需要控制复杂度和容量，避免成为瓶颈；SOA 本身并不要求使用 ESB
微服务架构	围绕业务边界独立部署，通过 HTTP、RPC 等协议通信，服务各自管理数据	需要额外处理服务发现、网络故障和跨服务一致性；数据归属独立也不等于每个服务都必须独占一台数据库

课程里从 ESB 式 SOA 到微服务的对比，重点是减少对一个集中式业务中枢的依赖。但拆分不会让治理工作消失：它可能由框架、网关、平台承担，也可能像第 1 章说的，部分下沉到服务网格里。

服务拆开后，调用怎么完成

原来单体应用里一个函数调用就能搞定的事，现在要跨网络调用别的服务，随之而来一串新问题：

• 服务注册与发现：服务的实例会动态增减、IP 会变，调用方怎么知道现在该找谁
• 负载均衡：一个服务有多个实例，请求该分给哪一个
• 配置管理：几百个服务的配置要能集中管理；适合动态调整的配置，可以通过客户端接收更新
• 服务治理：限流、熔断、降级——服务拆得越细，越需要提前设计好“允许哪些部分先坏”
• 分布式链路追踪：一个请求跨了十几个服务，出问题了怎么知道是哪一跳出的（这块具体产品见第 5 章的 ARMS）

框架：Dubbo 与 Spring Cloud Alibaba

Dubbo 和 Spring Cloud 都在解决这些问题，但侧重点和组件组织方式不同。阿里在两条路线上都有投入：

• Dubbo3：以 RPC 调用为核心，提供服务发现、流量治理等能力，支持兼容 gRPC 的 Triple 协议
• Spring Cloud Alibaba：把阿里的开源组件（Nacos、Sentinel、Seata、RocketMQ）集成到 Spring Cloud 体系里，习惯 Spring Boot 的团队比较容易接上已有开发方式

两者不互斥，Dubbo 可以作为 Spring Cloud Alibaba 的 RPC 层使用。已有技术栈、协议需求和团队经验，通常比单独比较“谁更快”更能决定选型。

Nacos：找到实例，再发起调用

不管用哪套框架，都得先解决服务怎么互相找到对方。Nacos 的注册发现承担的是下面这条虚线，实线才是业务请求：

这里画的是使用 Nacos 客户端发现实例的常见方式。实例变化需要经过注册信息更新和客户端感知，不能把它理解成零延迟同步；重试、超时和失效实例处理仍然需要设计。Nacos 的服务发现说明也明确区分了发现实例与实际调用。

Nacos 还提供配置管理：把配置集中存放，客户端监听变化。不过“配置已经推送”和“应用已经按新配置运行”是两件事，是否能动态生效取决于配置项和应用的刷新机制，不是所有修改都能省掉重启。

常被拿来比较的 ZooKeeper 是分布式协调服务，也可用于注册发现；Eureka 主要做服务发现。Nacos 则把注册发现和配置管理放在一起。自建集群仍要自己保证高可用，需要托管时可以看 MSE。

阿里云怎样托管微服务

阿里的微服务历程

课程会穿插 Dubbo 和 HSF 的历史，用来说明这些产品的背景：

• 2008 年，Dubbo 在阿里内部发展；淘宝这边则有另一套服务框架 HSF
• 2011 年，Dubbo 开源；2014 年一度暂停更新，2017 年重启活跃维护
• 2019 年，Dubbo 从 Apache 孵化毕业；后续 Dubbo3 的发展也吸收了阿里内部 HSF 的实践经验

记住这段背景就够了：阿里云把内部使用过的框架和治理经验逐步产品化，EDAS 是其中面向应用托管的一层。实际选型还是要看产品能力和自己的运维边界。

EDAS：应用托管与发布

EDAS（Enterprise Distributed Application Service，企业级分布式应用服务） 是面向应用托管和微服务管理的 PaaS 平台。底层可以选择 ECS 或 Kubernetes 集群，上层主要处理这些事：

• 应用生命周期：部署、启动、停止、分批发布、扩缩容
• 健康与监控：检查应用状态，并集成 ARMS 查看关键指标和告警
• 微服务治理：服务查询、流量管理、无损上下线、离群实例摘除等
• 框架接入：支持 Spring Cloud、Dubbo、HSF；多语言托管范围与部署环境有关

具体能力见EDAS 产品说明。它把部署和治理放在同一个平台里，减少搭建与集成工作，但应用配置、容量规划和发布验证仍要有人负责。

典型操作是创建应用、选择集群和资源、上传部署包或镜像，再配置发布策略。是否放量，要靠新版本运行后的验证结果决定，不能只看“部署成功”。

MSE：注册配置、治理与网关

MSE（Microservices Engine，微服务引擎） 面向开源微服务生态，课程在这里主要关注三块能力：

• 注册配置中心：托管 Nacos、ZooKeeper 等组件，减少维护注册中心集群的工作
• 微服务治理：全链路灰度、无损上下线、离群实例摘除等，具体支持范围与框架、接入方式有关
• 云原生网关：作为统一流量入口，提供路由、限流、鉴权、协议转换等能力

当前MSE 产品说明还列有分布式任务调度 SchedulerX，因此这里的三块不是产品全部功能。

EDAS 和 MSE 的区别可以按工作来记：EDAS 管应用生命周期，也提供治理；MSE 提供可单独接入的注册配置、治理、网关等能力。两者有交集，也能组合使用，不能把 MSE 简化成“只管注册中心”。

跨服务的一致性：Seata

第 1 章提到分布式事务有 XA、TCC、Saga、AT 等方案。Apache Seata 是实现这类方案的开源分布式事务框架。

课程重点介绍 AT 模式（Automatic Transaction）：通过数据源代理记录回滚日志，失败时据此补偿，业务通常不用自己编写每个操作的反向逻辑。它减少了业务代码改造，但仍有适用条件和协调成本。Seata AT 文档明确包含数据源代理、回滚日志和全局锁，并不是给任意数据库操作加个注解就能解决一致性。

除了 AT，Seata 也支持 TCC 和 Saga。区别可以按“谁来保证撤销或补偿”来记：

• AT：框架根据日志回滚，需核对数据库、SQL 和数据源接入的支持范围，也要接受全局锁等协调成本
• TCC：业务实现 Try / Confirm / Cancel，提前设计资源预留、确认和取消；灵活，但要处理幂等、空回滚等边界
• Saga：把长流程拆成步骤，失败后执行补偿；适合能定义补偿动作的业务，不提供数据库本地事务那样的隔离

模式之间没有单纯的“性能和一致性都更强”。尤其是已经发出的通知、已经调用的外部服务，能不能补偿，要回到业务本身判断。

新版本怎么上线

发布时有两个不同的动作：替换运行实例，以及把流量交给新版本。滚动、蓝绿和金丝雀分别强调其中不同的安排：

图解释做法，选用时还要看这些代价：

策略	需要留意
滚动更新	新旧版本会共存，要能相互兼容；是否增加临时实例取决于发布配置，并非一定不多占资源
蓝绿发布	两套环境并存需要额外容量；切流有传播过程，数据库等共享状态也不会跟着入口自动回滚
金丝雀发布（灰度发布）	要有可靠的流量分配、观测和停止条件；小流量不一定覆盖所有用户或业务路径

Argo Rollouts 的发布策略说明区分了这些机制。图中的 5% 只是示例：若仅按新旧副本数量分配请求，通常只是近似比例；需要精确控制时，还要有网关或服务网格等流量路由能力。

这些策略也可以组合：先用小流量验证新版本，再逐步替换实例。具体能怎样组合，要看 EDAS 的部署形态、治理接入和发布配置。

下一节看另一种运维分工：用 Serverless 把底层基础设施交给平台之后，用户还需要管哪些事。