微服务和 Serverless 架构（一）

第 1 章推因果链的时候提过一句：单体应用改不动了，才有了"服务化"这个架构模式。这一章把这句话展开，看企业应用架构具体是怎么一步步从单体走到微服务的，以及阿里自己在这条路上沉淀出来的产品——EDAS。

企业应用架构的演进：从单体到微服务

这是一条常考的主线，四个阶段：

阶段	特征	问题
单体架构	所有功能打包在一个进程里，一起编译、一起部署	改一行代码要重新构建整个应用，团队规模大了互相踩脚，没法独立发布
垂直架构	按业务模块拆成几个独立部署的应用（比如电商拆成用户、订单、商品几个子系统）	系统之间往往还是直接调用，甚至共享同一个数据库，谈不上真正解耦
SOA（面向服务架构）	引入 ESB（企业服务总线）作为服务间通信的中枢，统一处理协议转换、路由	ESB 本身是个又大又重的中心节点，一旦压力大或者出问题，容易变成全局瓶颈
微服务架构	比 SOA 粒度更细，去中心化——不再依赖一个重的中枢，每个服务独立部署、独立数据库，通过轻量级协议（HTTP、RPC）直接通信	服务多了之后，"怎么找到对方""怎么容错"这些问题需要专门的框架来解决

从 SOA 到微服务最关键的转变是去中心化：SOA 把治理能力集中在 ESB 这一个节点上，微服务把治理能力下放到每个服务自己身上（或者像第 1 章说的，进一步下沉到 Mesh 的 Sidecar 里）。

微服务框架要解决什么问题

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

服务注册与发现：服务的实例会动态增减、IP 会变，调用方怎么知道现在该找谁
负载均衡：一个服务有多个实例，请求该分给哪一个
配置管理：几百个服务的配置要能集中管理、动态推送，不能改一个配置就要重新发布代码
服务治理：限流、熔断、降级——第 1 章因果链里提过，服务拆得越细，越需要提前设计好"允许哪些部分先坏"
分布式链路追踪：一个请求跨了十几个服务，出问题了怎么知道是哪一跳出的（这块具体产品见第 5 章的 ARMS）

行业里常见的微服务框架，Spring Cloud（源自 Netflix 的开源体系）和 Dubbo（阿里开源的高性能 RPC 框架）是最有代表性的两个。

阿里自己的微服务之路

阿里在微服务这件事上走得比大多数企业早：

2008 年，Dubbo 在阿里内部诞生；同一时期，淘宝这边独立发展出了另一个服务框架 HSF——两个框架各管一摊，彼此不互通
2011 年，阿里 B2B 决定把 Dubbo 开源，很快在业界收获了大批用户
2014 年，因为内部团队调整，Dubbo 一度暂停更新
2017 年，Dubbo 重启开源并启动 3.0 的规划，2019 年由 Apache 孵化毕业，继 RocketMQ 之后又一个阿里巴巴的 Apache 顶级项目
后续几年，阿里把内部 HSF 多年沉淀的经验反哺进 Dubbo3，目前阿里核心电商业务已经全面完成从 HSF 到开源 Dubbo3 的迁移

这段历史的重点在于：EDAS 不是从零设计的产品，而是阿里自己十几年双十一大促流量验证过的内部经验，包装成产品对外开放。

EDAS 整体架构

EDAS（企业级分布式应用服务） 是阿里云对外提供的一站式微服务 PaaS 平台，定位是应用托管 + 微服务治理：

应用托管：负责应用的部署、发布、扩缩容，底层可以跑在 ECS 虚拟机上，也可以跑在容器 / ACK 集群上（和第 3 章的容器产品打通）
微服务治理：核心依赖 Nacos 作为注册中心。EDAS 自带商用版 Nacos，用 Nacos 开发的应用不用改代码就能直接部署上去；如果企业已经在用阿里云的 MSE（微服务引擎） 托管注册中心，EDAS 也能对接

简单说：Dubbo/Spring Cloud 这些是"怎么写微服务"的框架层，Nacos 是"服务怎么互相找到对方"的注册中心层，EDAS 是把这一整套跑起来、管起来的托管平台层。

EDAS 的主要功能

应用生命周期管理：一键部署、灰度发布（先放一小部分流量验证新版本）、蓝绿发布（新旧版本并存切换）、弹性扩缩容
微服务治理：服务注册发现、流量管理（按比例分流、按规则路由）
多语言支持：以 Java 生态为主，也覆盖其他常见语言

EDAS 基本操作和优势总结

典型的使用流程：上传部署包 → 创建应用 → 配置分组和资源 → 一键发布，发布过程中可以配置灰度策略，观察没问题再全量。

优势可以归三点：免运维（注册中心、配置中心这些基础设施不用自己搭）、深度集成（和阿里云的负载均衡 SLB、数据库 RDS、监控 ARMS 打通）、部署形态灵活（ECS、容器、Kubernetes 都能跑）。

微服务框架选型：Dubbo 和 Spring Cloud Alibaba

前面提到 Dubbo 和 Spring Cloud 是业界最有代表性的两个微服务框架。阿里在两条路线上都有投入：

Dubbo3：阿里自研的高性能 RPC 框架，从 HSF 反哺而来，强项是服务调用的性能和治理能力，原生支持 Triple 协议（兼容 gRPC）
Spring Cloud Alibaba：把阿里的开源组件（Nacos、Sentinel、Seata、RocketMQ）集成到 Spring Cloud 体系里，习惯 Spring Boot 的团队可以直接上手

两者不互斥，Dubbo3 可以作为 Spring Cloud Alibaba 的 RPC 层使用。选型上，团队已经在用 Spring Cloud 生态就选 Spring Cloud Alibaba，对调用性能要求高或已有 Dubbo 基础就直接用 Dubbo3。

Nacos：注册中心 + 配置中心

不管选 Dubbo 还是 Spring Cloud Alibaba，都绕不开一个基础问题：服务怎么互相找到对方，配置怎么集中管理。Nacos（Naming and Configuration Service）是阿里开源的注册配置中心，两个核心能力：

服务发现：微服务启动后把自己注册到 Nacos，调用方从 Nacos 查询目标服务的地址列表，不用硬编码 IP。实例上下线时 Nacos 自动更新，调用方实时感知
配置管理：把各服务的配置集中存放在 Nacos，修改后服务实时生效，不用重新发布

和常被拿来比较的 ZooKeeper、Eureka 的区别：Nacos 同时覆盖注册和配置两个能力（ZooKeeper 主要做注册发现，配置管理是附带的；Eureka 只做注册发现），而且自带管理控制台，运维门槛更低。

自建 Nacos 集群需要自己保证高可用，阿里云提供了托管版本，就是下面要说的 MSE。

MSE 微服务引擎

MSE（微服务引擎）是阿里云面向开源微服务生态的一站式托管平台，包含三个核心模块：

注册配置中心：托管版的 Nacos（也支持 ZooKeeper 和 Eureka），不用自己搭建和运维注册中心集群
微服务治理：全链路灰度、无损上下线、离群实例摘除等治理能力，对 Spring Cloud 和 Dubbo 应用都生效
云原生网关：兼容 Kubernetes Ingress 标准，作为微服务集群的统一流量入口，集成限流、鉴权、协议转换

MSE 和 EDAS 的关系：EDAS 是应用托管 + 微服务治理的 PaaS 平台，自带商用 Nacos；MSE 更偏向基础设施托管，只管注册中心、网关这些组件，不管应用本身的部署。两者可以独立使用，也可以搭配：EDAS 管应用生命周期，MSE 管注册中心和网关。

Seata：分布式事务

第 1 章提到分布式事务有 XA、TCC、SAGA、AT 等方案，但没说用什么产品。Seata 就是阿里开源的分布式事务框架，目前是 Apache 孵化项目。

Seata 最核心的卖点是 AT 模式（Automatic Transaction）：业务代码不用写补偿逻辑，Seata 通过拦截 SQL 自动生成回滚日志，事务失败时自动反向补偿。对开发者来说，分布式事务的使用体验接近本地事务，侵入性很低。

除了 AT，Seata 也支持 TCC（需要业务自己写 try / confirm / cancel 三个接口，灵活但开发量大）和 SAGA（长事务场景，按步骤编排补偿）。考试里常考这几种模式的适用场景：AT 适合大多数数据库操作；TCC 适合对性能和一致性要求极高的核心链路；SAGA 适合流程长、参与方多的业务编排。

发布策略：滚动、蓝绿和金丝雀

EDAS 和 MSE 都支持多种发布策略，考试里经常考区别：

策略	做法	优点	代价
滚动更新	逐批替换旧版本实例，每批验证通过后替换下一批	不需要双倍资源	替换过程中新旧版本共存，新版有问题影响范围逐步扩大
蓝绿发布	同时维护新旧两套完整环境，验证无误后一次性切流量	切换瞬间完成，回滚也是一次性切回	需要双倍资源
金丝雀发布（灰度发布）	先把一小部分流量（比如 5%）导到新版本，没问题再逐步放大比例	风险可控，影响范围最小	需要流量分配能力，验证周期较长

实际使用中最常见的是金丝雀 + 滚动的组合：先用小流量验证新版本，确认没问题后再滚动替换全部实例。

EDAS、MSE 这些产品解决的都是"用服务器或容器跑微服务"前提下的问题。但还有一类场景，用户连服务器都不想管，下一节看 Serverless。