从单体到微服务：可扩展性架构设计与性能演进实践

1. 从单体到微服务：为什么要做这场架构演进

可扩展性架构设计大概是每个后端团队绕不开的一道坎。我自己在前几年维护过一套典型的单体应用，刚开始的时候一切都很美好，代码结构清晰、部署简单、排查问题直接翻日志就行。但等到业务量上来，用户数从几万涨到几十万，团队从三个人扩到十几个人的时候，问题开始像雪崩一样涌过来。每次上线都像一场赌博，改一个模块的小功能，都可能把整个服务搞挂。那时候才真正理解，单体架构的瓶颈不在代码本身，而在“扩展”这件事上。

后来我们花了将近一年的时间，把系统从单体逐步演进到微服务架构，这个过程中踩过无数坑，也沉淀了不少经验。这篇文章就围绕“从单体到微服务的性能演进”这条主线，把我自己经历过的技术选型、拆分思路、部署方案、压测验证这些环节完整地梳理一遍，希望能给正在做同样决策的团队一些参考。

要说清楚为什么需要演进，就得先弄明白单体架构的核心痛点。很多文章喜欢从概念上对比“单体”和“微服务”，但作为实际干过活的人，我更愿意从三个非常具体的现象说起。第一个现象是部署越来越频繁、越来越慢。一个大型单体应用，编译打包就要十几分钟，启动又要几分钟，每次发版都心惊胆战。第二个现象是资源无法精细化控制。整个应用被捆绑在一个进程里，有的模块是CPU密集型的，有的模块是内存密集型的，但没办法单独扩容某一个部分，只能整台机器一起加配置，浪费非常严重。第三个现象是团队协作成本急剧上升。十几个开发者在同一个代码仓库里改代码，每天光解决合并冲突就要花掉大半天时间，代码审查也越来越流于形式。

1.1 单体架构的瓶颈在哪里

要理解单体架构的瓶颈，我们可以把单体应用想象成一个大工厂。这个工厂里有生产线、有仓库、有办公区，所有部门都在同一栋楼里。刚开始业务量小，这种模式效率很高，什么东西都在一个地方，找起来方便，沟通也快。但工厂规模大了以后，问题就出现了。

首先是故障隔离的问题。在单体架构下，所有模块共享同一个进程、同一个内存空间。只要有一个模块出现内存泄漏、死循环、或者访问了一个不存在的依赖，整个进程就可能崩溃，所有用户都会受到影响。我还记得有一次，一个内部报表定时任务因为数据量暴涨，把整个JVM堆内存吃满，结果所有在线用户的请求全都超时，那次事故直接让公司损失了半天的业务。这种“一损俱损”的耦合关系，是单体架构最让人头疼的地方。

其次是扩展维度的问题。单体应用确实可以水平扩展，也就是多启动几个实例，前面挂一层负载均衡。但这种扩展是“整体复制”，不是“按需扩容”。如果系统里只有订单模块是热点，其他模块都很空闲，单体架构也只能整台整台地加机器，无形中把成本推得很高。而且数据库连接数也是个大问题，每个实例都会占一批数据库连接，实例多了，数据库先扛不住了，这又变成了新的瓶颈。

1.2 微服务到底解决了什么问题

微服务架构解决的核心问题，就是把“大工厂”拆分成“专业小店”。每个小店只做一件事，但是可以独立扩张、独立部署、独立故障处理。这样当订单模块成为热点时，只需要给订单服务多加几个实例，其他服务完全不用动。

微服务架构带来的第二个好处，是技术栈的解放。单体架构基本上绑定了一种语言、一种框架，想引入新的技术栈几乎是不可能的任务。而微服务架构下，每个服务是独立的进程，理论上可以用不同的语言来写。当然，现实中我不建议盲目引入多种语言，这会给运维带来很大压力，但至少在某些特定场景下，可以针对性地选型。比如需要用大量内存排序的场景，用Go或者Rust写一个独立服务，性能就会比Java好很多。

还有一个非常重要的点是团队自治。拆分成微服务之后，每个团队围绕一个或几个服务进行开发，拥有独立的代码仓库、独立的发布流程、独立的监控告警，这大大降低了沟通成本。从管理的维度看，这是一种典型的“分而治之”策略，让每个团队的上下文边界变得清晰，开发效率自然就上来了。

不过我必须强调，微服务不是银弹。它带来了分布式系统固有的复杂度，比如网络延迟、服务间调用失败、数据一致性等等。如果把单体比作一辆小型货车，微服务就是一支货运车队，虽然单辆车灵活性高，但车队需要一个调度中心来协调。这个调度中心，就是我们后面要讲的Kubernetes（简称K8s）和一系列配套的基础设施。

2. 可扩展性架构设计的核心思路

真正开始做架构演进的时候，我发现最难的问题不是技术本身，而是“边界怎么划分”。很多团队在拆分微服务时，都是拿着代码模块列表，按功能把服务切出来，结果上线后才发现服务之间的调用关系错综复杂，一个请求要串起七八个服务，延迟高得离谱，排障更是噩梦。可扩展性架构设计的第一步，不是画架构图，而是想清楚业务域是怎么划分的。

这里要引入领域驱动设计（DDD）里“限界上下文”的概念。简单来说，就是找到业务中那些联系极其紧密、变化节奏一致、数据归属清晰的部分，把这一部分内聚成一个服务。比如在一个电商系统里，商品、订单、库存、支付、用户，这些就是天然的限界上下文，每个都可以作为一个独立的微服务。但如果把“订单管理”和“订单统计报表”强行拆成两个服务，那就是人为制造复杂度了，因为订单管理的每次变更都要同步改动统计逻辑，拆了反而更糟。

2.1 服务拆分的边界怎么定

我总结了几个判断服务边界是否合理的指标，纯经验型的，不是教科书里的定义。

第一个指标是“独立演化的频率”。如果两个模块每次需求的变更都会互相牵扯，那说明它们应该是一个服务。反过来，如果两个模块的发布频率完全不同，比如一个每周发版几次，另一个一个月才发一次，那它们更适合拆开。

第二个指标是“数据的所有权”。微服务之间不能直接共享数据库表，每个服务应该拥有自己的数据存储，也就是说，数据库要跟着服务走。这是微服务架构的一个核心原则。如果两个服务共享同一张表，就会形成隐式耦合，破坏了服务的独立性。

第三个指标是“团队的结构”。康威定律讲得很明白：系统架构是组织沟通结构的缩影。如果你的团队已经按照业务线划分成了几个小组，那服务边界最好按照小组的职责来定，否则团队之间的沟通成本会直接转移到代码和接口上。

拆服务的时候还有一个常见的误区，就是“粒度越细越好”。我见过有人把用户服务拆成了用户基础信息服务、用户画像服务、用户偏好服务，结果一个页面要调三次用户相关的接口。这里要记住一个原则：可扩展性不等于服务数量多，而是“能够独立扩展的部分尽量独立，不该分开的不要强行拆开”。微服务的粒度要用“能力”来衡量，而不是用“数据表”或“类”来衡量。

2.2 容器化与编排：K8s在微服务中的角色

服务拆分完之后，接下来的问题是：这些服务跑在哪里？怎么编排？

微服务的部署方式和单体完全不一样。单体应用只需要打一个包，放到几台服务器上，配好负载均衡就好了。但微服务可能有十几个甚至几十个服务，每个服务的实例数、资源配额、健康检查、滚动更新策略都不一样，如果还是用传统的方式手工部署，运维压力会大到无法承受。

这就是容器化和编排平台的价值所在。容器（以Docker为代表）把服务连同它的运行环境一起打包成标准化的镜像，解决了“在我机器上好好的，怎么到服务器就不行”的问题。而K8s在这之上又做了一层抽象，用声明式的方式管理容器的生命周期。比如你告诉K8s“订单服务需要运行3个实例，镜像版本是v1.2.3”，K8s就会自动帮你调度到合适的节点上，如果某个实例挂了，它会自动拉起一个新的来维持实例数不减少。

我在实际项目中用的是单节点K8s。很多人一听到K8s就觉得它很重，一定要搞那种多节点的高可用集群。其实对于中小型团队、对于开发和预发环境，单节点K8s完全够用。它的部署成本低、运维简单，还可以在本地用Minikube或k3s快速搭建一套。真正的生产环境，如果预算和团队能力允许再扩展到多节点也不迟。有一点要提前规划好：K8s只是解决了“编排”的问题，它不代表服务就能自动扩展了，服务的副本数、资源限制、HPA（水平自动伸缩）策略都需要你自己去配置，这些东西才是可扩展性设计的关键部分。

2.3 数据层的扩展策略

微服务拆分之后，数据库怎么处理？这是整个演进过程中最痛苦、也最需要谨慎的部分。单体架构下通常是一个大数据库，所有的表都在里面，服务拆分时不能光把代码拆开就完事，数据也得跟着拆。但直接拆数据库，风险极高。一旦涉及跨服务的事务，原来可以用本地事务解决的问题，现在变成了分布式事务，处理起来非常棘手。

我的建议是分阶段进行。先不要急着拆数据库，而是先把服务的调用边界理清楚，禁止服务之间的互相访问表，要求所有跨服务的数据访问必须通过API。等代码层面的耦合完全解除之后，再考虑把某几张表迁移到独立数据库，同时引入一个数据同步机制，比如通过消息队列做异步同步，确保过渡期新旧系统可以共存。

数据层的扩展性还涉及一个问题：读写分离和分库分表。当单表的数据量到达几千万级以上时，SQL查询性能会明显下降。这个时候可以先用读写分离缓解主库的压力，把读流量引导到从库。再往上走就是分库分表，比如按用户ID取模分到不同的数据库实例上。不过这块我建议非必要不要自己造轮子，优先考虑使用成熟的开源方案，比如MyCat或ShardingSphere，而且一定要在业务设计之初就把分片键想好，否则后期改分片键的代价是巨大的。

3. 实操过程：从0到1搭建微服务环境的完整链路

理论讲了一堆，接下来分享一套实战路径。我把从搭建微服务环境到完成性能验证的完整过程都记录在下面，这套方案我在好几个项目里验证过，是性价比很高的一条路。

假设我们现在要搭建一套电商核心系统，包含用户、商品、订单、库存、支付五个微服务，加上一个API网关，一个认证服务。框架选择上，我建议优先用Spring Cloud Alibaba这套组合，它包含Nacos作为注册中心和配置中心、Sentinel做流量控制，整体和国内的主流技术栈匹配度很高，社区资料也丰富。如果你的团队更轻量，也可以考虑用若依微服务Plus这种现成脚手架来起步，它已经帮你把用户管理、权限管理、代码生成这些基础能力都搭好了，开箱即用，省去了大量写基础CRUD的时间。

3.1 技术选型：为什么是Spring Cloud Alibaba

选型这件事，团队里往往会有很大争议。有些同学倾向于用比较新的Go微服务框架，比如go-micro、go-zero，觉得性能更好。有些同学则倾向于保持Java生态。我的观点是：框架本身不是决定性能的关键，架构设计才是。Java在微服务生态上沉淀时间最长，无论是Spring Cloud还是Dubbo，都有大量生产环境的验证，遇到问题很容易找到现成的解决方案。而Go的优势在于单机高并发处理能力强、资源占用小，但周边生态相对Java还是弱一些。

Spring Cloud Alibaba这套东西特别适合国内团队使用，它把服务发现、配置管理、限流降级这些需要用到的微服务基础能力集成得很完整。服务发现用Nacos，它同时支持注册中心和配置中心两个角色，比单独的Eureka加Spring Cloud Config少维护两个组件。限流降级用Sentinel，它有一个可视化的控制台，可以动态调整规则，也不用重启应用。这些能力如果在单体架构中是不存在需求的，但在微服务架构中都是必需品。

3.2 单节点K8s上的微服务部署实战

应用开发完之后，下一步就是部署。这里我以单节点K8s为例，讲一下具体的部署流程。

首先需要一个K8s集群。如果是线上环境，我推荐直接用云厂商的容器服务，比如阿里云的阿里云容器服务 Kubernetes 版（ACK），可以快速创建一套完整的K8s集群，避免自己从零搭建带来的各种坑。如果只是本地开发和测试，用Minikube就够了，一条命令就能起一个单节点的K8s环境。

集群准备好之后，第一件事是创建命名空间。命名空间是K8s用来隔离资源的逻辑单元，建议按环境来分，比如dev、staging、prod，这样每个环境的配置和应用互不干扰。我见过不少团队一上来就把所有服务都塞在default命名空间里，混乱程度肉眼可见。

然后要给每个微服务编写Dockerfile。这里有几个经验点要提：第一，尽量使用多阶段构建，把编译环境和运行环境分开，这样镜像体积会小很多。比如一个Java服务，用maven进行编译，再用精简的JRE镜像作为运行基础，镜像可以从几百MB降到一百多MB。第二，基础镜像的版本要锁定，不要用latest标签，否则镜像构建一次一个样，排障时很容易怀疑人生。第三，不要以root用户运行容器，新建一个低权限的用户，虽然多几行配置，但安全性提升明显。

镜像构建好之后，就需要编写K8s的部署清单了。一个典型的工作负载包括Deployment、Service、ConfigMap/Secret这三样。Deployment管理应用的副本数量和滚动更新策略，Service负责在集群内部做负载均衡，让其他服务可以通过服务名访问。这些配置建议以YAML文件的形式放到Git仓库里，方便版本管理。以下是一个简单的示例：

yaml复制apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: prod
  labels:
    app: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: registry.example.com/order-service:v1.2.3
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "1Gi"
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

这个配置里，我需要特别强调两个地方。第一个是resources，也就是资源配额。很多新手不写这一项，导致某个服务把节点资源耗尽，所有服务一起遭殃。第二个是readinessProbe，就绪探针。它告诉K8s什么时候容器算是真正启动好了，可以接受流量了。如果没配这个，K8s会在容器进程起来但还没就绪的时候就把流量打进来，导致大量请求超时。

最后是Ingress，也就是集群的入口。外部流量统一走Ingress到API网关服务，API网关再路由到具体的后端微服务。K8s的Ingress本身就是一个七层负载均衡器，可以配置域名和路径的路由规则，把这层放在最前面，整个入口就是统一的了。

3.3 迁移到云环境时的坑

在我们的实际项目中，最初应用跑在自建的物理服务器上。随着业务增长和架构演进，我们决定把整个微服务环境迁移到阿里云ECS上，目标是不停服、不丢数据。这件事理论上不复杂，但实际操作起来，关键在于节奏控制。

首先，在云上先创建一个和现有环境隔离的VPC（虚拟私有网络），把新的K8s集群和数据库都放在里面。然后，通过数据库迁移工具做在线数据同步，让云上的数据库实例从本地的源库实时同步数据，确保两边数据是齐的。应用层则分批切换，先用灰度发布的方式，把一部分外部流量导到云上环境，验证核心链路没有问题，再逐渐增加流量比例，直到全部切到新环境。

迁移过程中最容易出问题的是“配置漂移”。本地环境的配置文件参数和云上可能不一样，比如数据库连接、缓存地址、消息队列地址。如果这些配置写死在代码里或者镜像里，迁移时就要改代码、重新镜像，相当麻烦。所以一定要把配置外置，用Nacos或者K8s的ConfigMap来管理，让应用读取环境变量而不是本地文件。

另外，迁移前一定要先做一次完整的压测，摸清云上环境的承载能力。我见过不止一个团队，迁移完才发现云服务器性能不如物理机，结果原有的1000并发降到了500并发，导致上线当天线上就告警。所以“迁移到云”这件事，不是简单地换个运行环境，而是要重新对系统做一次全方位的性能验证。

4. 性能验证：压测才是检验架构的唯一标准

架构演进好不好，不是靠“感觉”来说的，得靠数据说话。每次架构调整之后，我都会组织一场完整的压测。压测的目的不是为了拿一个好看的吞吐量数字给领导看，而是要发现系统在高并发下暴露出来的瓶颈。

压测分几个层次。第一个层次是单服务压测，看每个微服务的接口支持多少QPS、响应时间是多少。第二个层次是链路压测，从入口网关到后端服务，完整模拟用户操作流程，找出全链路中最薄弱的环节。第三个层次是容量规划，根据压测结果决定每台服务器上部署多少个实例，以及整体需要多少台机器来支撑预估的业务峰值。

在热词的描述里，提到了用配套的JMeter脚本做高并发测试，这确实是目前应用最广泛的压测方式。不过我要先说一句公道话，JMeter做接口级的、中小规模的压测是足够的，但如果你的目标是超过每秒上万请求的超高并发压测，JMeter可能会在客户端就变成瓶颈。那个时候可以考虑用Gatling或者Locust这类支持分布式压测的工具。但在绝大多数业务场景下，JMeter已经够用了。

4.1 压测方案怎么设计

压测方案不能拍拍脑袋随便写，以下是我常用的一套设计方案。

第一步，明确压测场景。比如在这个电商系统里，我们把“用户浏览商品->加入购物车->下单->支付”这条主链路定义为核心链路，所有的压测资源都要优先保证这条链路的验证。

第二步，明确压测模型。需要模拟多少在线用户数、每个用户的操作间隔、请求的分布比例以及测试时长。比如计划模拟1000个用户并发操作，每个用户每5秒执行一次操作，那么总请求量就是每秒200个左右。注意，这里的“并发用户数”和“QPS”是两个概念，不要搞混。压测过程中，JMeter会用线程数模拟虚拟用户，一个线程模拟一个用户，线程越多并发越高。

第三步，准备压测数据。很多人忽略这一步，但数据的影响是决定性的。如果数据库里只有几千条订单数据，那么查询走索引和全表扫描差别都不大，压测结果毫无参考价值。压测数据要尽量贴近生产环境，包括数据量、数据分布、索引情况。

第四步，搭建独立的压测环境。压测是有破坏性的，它会把目标系统的CPU打满、内存吃紧，如果在生产环境直接压测，一定会影响到真实用户。所以压测环境要尽量和线上结构一致，但数据可以使用脱敏后的生产数据快照。

JMeter脚本怎么写，这里给一个简单的HTTP请求的例子，用JMeter的“线程组”和“HTTP请求”采样器就能完成。核心点是“线程组”里设置并发用户数和循环次数，“HTTP请求”里配置目标的域名、端口、路径和请求体。为了模拟多用户并发登录的场景，一般还会加一个“CSV数据文件配置”，从外部文件读取不同的账号密码，避免所有线程共用同一个账号。

4.2 压测结果解读：这些坑你一定遇到过

压测跑完之后，最关键的工作是解读结果。JMeter里常见的指标包括：响应时间（Avg、P90、P99）、吞吐量（Throughput）、错误率（Error%）。很多人只盯着“平均响应时间”看，其实这是有误导性的。如果一秒钟内有20个请求响应时间是50毫秒，但有一个请求响应时间是10秒，平均值就变成了530毫秒左右，这完全掩盖了长尾请求的恶劣表现。所以，我更看重的是P99响应时间和错误率。P99小于200毫秒，错误率为0，这个系统在用户侧的感知才是“丝滑”的。

第一次压测几乎100%会暴露一些问题。最常见的包括数据库连接池不够用、Redis连接数达到上限、慢SQL在并发下被放大、服务线程池满了导致请求排队，等等。

我印象最深的一次压测是“订单列表查询”接口，单机能扛200QPS，但把并发提到500时，P99响应时间直接从80毫秒飙到5秒。排查后发现，这个接口底层关联了订单表、订单明细表、商品表、用户表四张表，有一个嵌套循环查询在数据量小的时候没问题，但在压测数据量大了之后触发了全表扫描。解决方案也不复杂，把那个嵌套循环改成一次性IN查询，再优化SQL让索引生效，问题就解决了。这个案例也让我再次确认了一个道理：压测不仅能验证架构容量，它更是发现代码问题的利器。

4.3 高并发场景下的限流降级设计

压测之后，如果发现系统扛不住预期的高并发流量，除了扩容之外，更核心的手段是“限流降级”。

限流是指在流量过大时，主动拒绝部分请求，保护系统不被拖垮。降级是指在依赖的下游服务出现故障或超时时，执行一些兜底逻辑，比如从缓存中读取旧数据返回给用户，而不是一直等待超时。

Sentinel就非常适合做这件事。它支持QPS并发线程数流量控制，也支持基于响应时间的熔断降级。在秒杀这种高并发场景下，核心的玩法是“流量整形”。比如商品详情接口的流量瞬间冲到每秒一万次，但下单服务只能扛两千QPS，那就在网关层或者下单服务入口配置一个限流规则，把多余的流量挡在外面，返回“系统繁忙，请稍后再试”之类的提示。这样虽然牺牲了一部分用户体验，但至少保证了系统整体的可用性。

限流降级的规则一定要在压测阶段就调好，不要等到线上出事了才临时加规则。通过压测，你能摸清楚每个服务的真实承载上限，然后以这个上限为基准，再预留30%~50%的缓冲，设置合理的限流阈值。这个阈值设置得过高，等于没限流；设置得过低，又会误伤正常用户，需要在多次压测中慢慢找到合适的值。

5. 微服务落地中的常见问题与排查技巧

微服务架构落地之后，日常运维中遇到的问题和单体架构完全不是一个量级。单体应用出问题，基本就是翻日志、查慢SQL、重启两三板斧。但微服务环境下，一个请求要穿越网关、认证服务、业务服务、数据库缓存消息队列等多个环节，任何一个环节出了问题，表现都是“接口超时”，但根因可能千差万别。

我把自己在这些年运维微服务的过程中遇到的几个典型问题整理一下，希望能帮你少走一些弯路。

5.1 服务发现与配置管理问题

Nacos作为注册中心和配置中心，几乎是整个微服务系统里最核心的基础设施。它一旦不稳定，所有服务的注册、发现、配置拉取都会异常，连锁反应非常严重。

最典型的一个问题是“服务注册了但调用方发现不了”。排查思路是这样的：先从消费方的日志看，是不是有“No instances available for xxx”之类的告警。如果有，接下来检查服务提供方是否成功注册到了Nacos上，在Nacos控制台的服务列表中搜索对应的服务名。如果服务列表里没有，去看提供方应用日志，确认它是否连接了正确的Nacos地址。这里要特别注意，Nacos集群的地址不要只配一个节点，要全部配上，否则单节点挂了会导致服务不可用。

配置管理的问题也很常见。很多团队把配置写进Nacos之后，修改了配置，但应用没有动态刷新。这通常是因为没有使用Nacos的配置监听机制。在Spring Cloud Alibaba中，需要用@RefreshScope注解对配置类进行标记，配置中心的改动才会自动同步到运行中的服务。这个细节非常容易遗漏，但要排查起来却不容易，因为日志上看不到任何报错，只是配置没生效。

5.2 数据库连接池打满的问题

在高并发压测下，数据库连接池告警是出现频率最高的问题之一。连接池的原理很好理解，就是预创建一批数据库连接放在池子里，应用需要时从池子里借一个，用完归还。连接池的大小是有限的，默认值在如HikariCP中一般是10个。如果业务代码里有连接泄漏，也就是借出去的连接始终没有归还，池子很快就空了，后面所有请求都会卡在“获取连接”这一步上，表现就是接口超时、大量线程阻塞。

排查连接泄漏有几个技巧。第一，看连接池的监控指标，比如HikariCP暴露的active连接数。如果active数一直维持在最大值附近，而且没有波动，基本可以断定有连接没有被释放。第二，看线程栈，用jstack命令导出应用线程的堆栈信息，搜索关键词“HikariPool.getConnection”，看看有多少线程阻塞在这里，以及这些线程是从哪些业务代码发起的调用。第三，检查代码里有没有忘记关闭ResultSet、Statement或Connection的地方，特别是用了旧式的JDBC模板或者自己封装的数据库工具类时。

解决连接池打满问题，除了修复连接泄漏之外，还可以适当调大连接池的上限，但要记住，连接池不是越大越好。数据库能同时处理的连接是有上限的，连接太多反而会增加数据库服务器的CPU和内存开销。合理的大小和机器的CPU核心数以及数据库的实例规格都有关系，需要结合压测数据进行调整。

5.3 可观测性体系建设：监控、日志、链路追踪

微服务拆完之后，还有一个必须解决的问题：系统出故障时，怎么快速定位到是哪个服务出了问题？单体时代，一台服务器上跑着所有代码，登录上去看日志就行。微服务时代，代码散落在几十个Pod里，日志也是分散的，没有一套统一的观测体系的话，排查一个问题可能要花上大半天。

可观测性一般分成三个维度：监控指标（Metrics）、日志（Logs）、链路追踪（Traces）。监控指标负责告诉你“哪个服务出问题了”，日志负责告诉你“这个服务里发生了什么”，链路追踪负责告诉你“一个请求经过了哪些服务、每个服务花多少时间”。

链路追踪这个工具真的很重要。我最早用微服务的时候，线上用户反映下单很慢，但我们不知道慢在哪。后来接入了链路追踪系统之后，一个请求从网关到用户服务到订单服务再到支付服务，每个环节的耗时一目了然。结果发现，慢的是支付服务调第三方支付平台的那段外部HTTP调用，在某些时段会超过2秒。如果没有链路追踪，我们可能还会在订单服务内部到处排查，浪费大量时间。

链路追踪现在主流的方案是SkyWalking或者Micrometer+Tracing，前者功能更完整，自带UI和告警，推荐优先考虑。部署复杂度也不高，只要在每个服务的启动命令里增加探针参数，就能自动采集链路数据。从成本上看，一套监控体系带来的排障效率提升，完全是值得的。

我相信微服务架构的演进没有终点，它不是一个“做完就结束”的项目，而是一个持续迭代、持续优化的过程。从单体到微服务的性能演进，本质上是从“能用”到“好用”再到“可扩展”的不断打磨。每个人的业务场景不同，技术选型可以不一样，但可扩展性设计的核心思路是共通的，希望这篇文章能给正在做同样决策的你提供一点参考。

如果你正打算进行架构演进，我建议从最小的模块开始尝试，不要一上来就做“大爆炸式”的重构。先把工具链搭好，把部署流程理顺，把监控覆盖到位，然后再逐步迁移业务模块。这个过程中，你会收获比架构本身更有价值的东西——对整个系统更深刻的理解。