微服务架构演进：从单体到分布式，如何设计高可用系统

本文将介绍微服务架构和相关的核心组件，探讨它们是什么以及为什么需要使用。文章侧重于勾勒微服务架构的全局图景，因此不会深入具体组件的实现细节。

要理解微服务，最好先看看它的对立面。通常，与微服务相对的是单体应用，即所有功能都打包在一个独立单元中的应用程序。从单体演进到微服务并非一蹴而就，而是一个逐步演变的过程。下面我们以一个网上超市应用的成长故事为例，来生动地说明这一过程。

最初的需求与单体架构

几年前，小明和小皮决定创业做网上超市。小明负责程序开发。当时，网上超市还是蓝海市场，只要功能实现就能赚钱。因此，他们的需求非常直接：一个挂在公网上的网站，用户能浏览和购买商品；再加一个管理后台，用于管理商品、用户和订单。

我们整理一下功能清单：

1）网站

• 用户注册、登录功能
• 商品展示
• 下单

2）管理后台

• 用户管理
• 商品管理
• 订单管理

需求简单，小明三下五除二就做好了网站。出于安全考虑，管理后台没有和网站做在一起，也很快完成。总体架构图如下：

小明找了家云服务商部署上去，网站顺利上线，初期运营得不错。

业务发展带来的架构混乱

好景不长，竞争对手涌现。在压力下，团队决定开展营销活动：比如促销活动、拓展移动端APP和微信小程序、利用数据进行精准营销等。

小红加入团队负责移动端和数据分析。由于开发任务紧迫，他们没有进行良好的架构规划，拍脑袋决定将新功能塞进现有系统。促销管理和数据分析放进了管理后台，微信和移动端则另起炉灶。几天通宵后，新功能上线，此时架构变得复杂：

这一阶段的架构暴露了很多问题：

• 代码重复：网站和移动端有大量相同业务逻辑的重复代码。
• 接口混乱：数据交互时而走数据库共享，时而走接口调用，关系杂乱。
• 应用边界模糊：单个应用为了提供接口，塞进了许多不属于它的逻辑。
• 数据库瓶颈：所有应用共用一个数据库，尤其数据分析任务运行时，性能急剧下降。
• 维护困难：即使只修改一个小功能，也需要整个应用一起发布，风险高，常需在凌晨操作。

尽管问题重重，但这一阶段实现了业务的快速响应。不过，紧迫的任务容易让人做出短视的妥协决策，缺乏全局设计，长期来看系统将举步维艰。

向微服务架构演进

意识到问题后，小明和小红开始着手改造。改造的前提是必须有足够的精力和资源，否则在业务压力下寸步难行。

改造的核心是抽象。他们梳理业务，抽象出几个公共服务：

• 用户服务
• 商品服务
• 促销服务
• 订单服务
• 数据分析服务

各个前端应用（网站、移动端、后台）只需从这些服务获取数据，自身只保留轻量的控制层。架构演进如下：

然而，只要数据库仍然共用，许多问题就依然存在：数据库仍是性能瓶颈和单点故障源，数据管理易混乱，表结构难以调整。

因此，他们进一步拆分了数据库，让每个服务管理自己的数据持久化。同时，引入消息队列提高系统实时性。架构最终变为：

拆分后，各服务可采用异构技术栈，例如数据分析服务用数仓，高频访问的服务引入 Redis 缓存。

除了技术上的好处，微服务架构也明确了团队分工和责任，使每个人能专注于提供更好的服务，避免了公共功能“无人认领”或“能者多劳”的背锅现象。这通常也需要组织结构的相应调整。

微服务带来的新挑战

在一次购物节中，系统因促销服务不堪重负而宕机，引发了链式雪崩。虽然通过紧急扩容暂时恢复，但仍造成了损失。事后分析发现是商品服务的 Bug 导致了对促销服务的海量无效请求。

这次事故暴露了微服务架构的新问题：

1. 故障定位困难：应用分散，排查问题时需要跨多个服务。
2. 稳定性下降：服务增多，单个服务故障概率增大，且可能引发连锁反应。
3. 运维复杂度高：服务数量多，部署、管理工作量巨大。
4. 测试复杂：功能涉及多个服务间调用，测试更困难。

构建稳定性保障体系

面对故障，通常从两方面入手：减少故障概率，降低故障影响。

监控：发现故障征兆

必须建立完善监控，以便提前发现问题。由于微服务组件众多，监控指标各异，通常采用标准化的 metrics 接口。各个组件（如业务服务、Redis、MySQL）暴露指标，由统一的指标采集器（如 Prometheus）收集，再通过 UI（如 Grafana）展示和告警。

链路跟踪：定位问题

当一个用户请求涉及多个内部服务调用时，需要记录完整的调用链，即链路跟踪。例如，一个访问商品页的请求，可能先后调用详情服务和评论服务。

实现上，每次服务调用需在 HTTP Headers 中记录 traceId、spanId、parentId 等数据，并通过日志收集器和 UI 进行展示与分析。开源方案如 Zipkin，其理论基础源于 Google 的 Dapper 论文。

日志分析：深入排查

当服务规模变大，日志分散在多台服务器，排查如同大海捞针。需要一个日志“搜索引擎”。经典的 ELK 栈（Elasticsearch, Logstash, Kibana）就用于此目的：Logstash 采集日志，Elasticsearch 存储和索引，Kibana 提供查询和展示界面。

网关：统一入口与治理

服务增多，调用关系变得混乱。网关作为统一入口，可以进行权限校验、流量控制，并作为 API 文档平台。根据粒度，可以是整个系统一个网关，或按业务域分区设置。

服务注册与发现：支撑动态扩容

为应对流量波动，服务实例需要动态增减。服务注册与发现机制能自动管理服务实例地址。服务启动时自动注册到发现中心，其他服务同步地址列表，发现中心定期检查健康状态并剔除异常实例。

这常与客户端负载均衡结合，实现更灵活的流量路由，如 A/B 测试。常用组件有 Zookeeper、Eureka、Consul、Etcd 等。

熔断、降级与限流：止损与自保

• 熔断：当调用一个服务多次失败，直接“熔断”该调用，快速返回错误，避免资源被长时间占用，等待服务恢复后再尝试重建连接。
  

• 服务降级：当非核心服务故障时，暂时关闭该功能，保障核心业务流程不受影响。例如推荐服务挂掉后，下单功能仍应可用。

• 限流：防止服务被突发流量击垮。可在全局或针对特定来源（如某个问题服务）进行限流，丢弃超额请求。
  

测试策略调整

微服务下的测试分为三层，构成一个金字塔：

• 单元测试：最容易实施，效率高，但覆盖范围有限。
• 服务测试：针对服务接口测试，常需使用 Mock Server 来模拟依赖服务。
  
• 端到端测试：覆盖整个系统，信心最足，但实施成本最高。

应重点关注核心业务的端到端测试，并将失败案例转化为单元测试，以便快速捕获同类错误。

微服务框架 vs Service Mesh

将监控、链路跟踪、服务发现等公共代码集成到每个服务中很耗时。通常有两种抽象方案：

1. 微服务框架
开发一套统一框架，将所有公共对接代码和功能（如熔断限流）封装其中。好处是实现深度集成和自定义（如代码级链路跟踪），但框架升级成本高，需要所有应用服务配合，管理挑战大。

2. Service Mesh（服务网格）
将网络通信等公共功能抽象到一个独立的 Sidecar 代理中，与服务实例部署在同一主机。所有进出流量都经过 Sidecar 处理。再由统一的 控制平面 管理所有 Sidecar 的配置。

Service Mesh 的优点是非侵入式，升级维护方便；缺点是有一定的性能开销（内存拷贝）。它代表了另一种解耦的思路。

结束，也是开始

微服务并非架构演变的终点。更细粒度的 Serverless、FaaS 正在兴起，同时，也有人重新审视适度聚合的价值。架构的选择始终围绕着业务复杂度、团队能力和运维成本在做平衡。希望这个网上超市的故事，能帮助你更直观地理解微服务架构的来龙去脉及其核心组件的设计思想。

如果你对微服务架构或Service Mesh等云原生技术有更多兴趣，欢迎到 云栈社区 的 云原生/IaaS 板块交流讨论，那里有更多开发者分享实战经验和前沿资讯。

来源：www.cnblogs.com/skabyy/p/11396571.html