单体架构图解——一个可部署单元,一个数据库 · 思维导图

单体架构图解——一个可部署单元,一个数据库. 可编辑的思维导图,以彩色分支、子主题和曲线连接呈现想法。 曲线表示联系;只有方向重要时才使用箭头。

单体是作为一个单元构建并部署的应用:UI、业务逻辑和数据访问都跑在同一个进程里,面对同一个共享数据库,而扩容意味着把整个东西复制一份。

单体架构图解——一个可部署单元,一个数据库 · 思维导图

The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

如何阅读这张思维导图

  • 从中心主题开始,沿着彩色分支探索相关想法。
  • 曲线表示联系;只有方向重要时才使用箭头。

Client request

这一分支汇集 “Client sends a request”.

One application

这一分支汇集 “Request enters the single deployable application”, “Business logic module processes it”, “The response returns through the same modules”, “UI module routes and renders”, “Data access module queries the database”.

Shared database

这一分支汇集 “All modules share a single schema, which keeps joins and transactions simple — the main reason a monolith is so fast to build at first.”.

Scaling tradeoff

这一分支汇集 “One busy feature forces the entire codebase and database connection pool to be copied to another server — the scaling ceiling that pushes teams toward splitting it.”.

跨分支联系

所有模块共用一个进程、一个代码库、一次部署——这种包含关系就是定义本身。

共享数据库把每个模块都耦合到同一套表结构上。

请求在一次往返中穿过每一个模块——中间没有独立的服务调用。

扩容的粒度很粗:不管哪个功能繁忙,被复制的都是整个应用。

单体的开发速度是真实的;它拿来交换的,正是那道扩容天花板。

Key relationships and takeaways

  • 所有模块共用一个进程、一个代码库、一次部署——这种包含关系就是定义本身。
  • 共享数据库把每个模块都耦合到同一套表结构上。
  • 请求在一次往返中穿过每一个模块——中间没有独立的服务调用。
  • 扩容的粒度很粗:不管哪个功能繁忙,被复制的都是整个应用。
  • 单体的开发速度是真实的;它拿来交换的,正是那道扩容天花板。

When to use this visual

  • 解释一个团队的应用为什么开发起来容易,扩容起来却很难。
  • 讲清楚那个让微服务变得可理解的对比——只有对着单体的天花板,拆分才说得通。
  • 在规划如何拆解之前,先把遗留系统的结构记录下来。

运作方式

  1. 调整中心主题

    根据项目或课程修改中心主题的名称。

  2. 扩展分支

    编辑想法并添加示例或注释。

  3. 连接相关想法

    绘制跨分支连接;只有方向重要时才使用箭头。

常见问题

什么是单体架构?

单体是这样一种应用:它的 UI、业务逻辑和数据访问被当作一个单元一起构建、部署和扩容——一个代码库产出一个可部署制品,运行在一个共享数据库之上。图上把请求画成在同一条应用泳道内穿过全部三个模块,因为这种包含关系就是定义。

团队为什么大多从单体开始?

因为对大多数团队、对一个应用生命周期的大部分时间来说,单体是最快能交付的方式。模块之间没有网络,共享的表结构让关联查询和事务都很简单,部署也只有一个制品。图上那个共享数据库方框把这一点直接说了出来——只有当独立扩容或团队自治成为约束瓶颈时,这笔交换才开始变得不划算。

单体最主要的问题是什么?

扩容天花板和耦合。扩容意味着复制整个应用,所以一个繁忙的功能会在其余所有部分上浪费容量;而每一次改动都要碰一个所有人都依赖的代码库和表结构。随着团队和代码库变大,这两个效应会拖慢部署、逼出大量协调——团队正是在这种条件下开始抽取服务的。

单体怎么变成微服务?

循序渐进,一次抽取一项能力。第一步是找出一个能独立存在的模块——它有自己边界清晰的数据——然后给它自己的数据库、一个 API,最终让它独立部署。图解里那个画出可抽取候选模块的步骤演示的正是这件事:标出模块,切断耦合,然后拆分。常见的错误是一次性重写整个单体,迁移就是这样失败的。

在 QueryChart 中编辑此思维导图

在可编辑画布中打开思维导图。移动想法、添加分支并绘制连接。

在 QueryChart 中编辑此思维导图

思维导图中的更多内容