一个系统越做越大，改一行怕牵一发动全身。于是有人提出：把它拆成一堆小服务，各管一摊。这就是微服务。

一、单体 vs 微服务

  • 单体（Monolith）：所有功能塞进一个程序，像一整块大蛋糕。做起来简单，但越往后越笨重：改个小功能也要整体重新部署，一个模块崩了全盘皆输。
  • 微服务：把蛋糕切成小块，每块是独立的小店（用户服务、订单服务、支付服务……），各自开发、各自部署、各自扩容。

整蛋糕 vs 切块

二、微服务解决了什么

  • 独立部署：改订单服务，不用动用户服务，互不打架。
  • 按需扩容：下单人多就只给订单服务加机器，省钱。
  • 技术自由：不同服务可以用不同语言/数据库，最适合的才用。

三、代价也实在

拆开后，服务之间得通过网络互相调用，于是冒出一堆新问题：怎么找对方（服务发现）、调用失败了怎么办（熔断/重试）、数据怎么一致、链路出错了去哪查（链路追踪）。运维复杂度直线上升。

四、不是非拆不可

小项目硬上微服务，反而是给自己找罪受。先单体、长胖了再拆，是更稳的路线。

一句话：微服务是把“一个大系统”切成“一群小系统”，灵活但要付出分布式的复杂度；别为了酷而拆，等真长大了再拆。