康威定律对微服务的启示

● 康威定律(Conway's Law)

原文

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

--- Melvin Conway, 1967

翻译

设计系统的组织,其产出的系统架构,必然是该组织沟通结构的复制。


通俗理解

┌─────────────────────────────────────────────────────────┐

│ │

│ 怎么分团队 ──────决定了──────▶ 怎么分系统 │

│ │

│ 人怎么沟通 ──────决定了──────▶ 模块怎么交互 │

│ │

└─────────────────────────────────────────────────────────┘

一句话:公司的组织架构长什么样,系统架构就长什么样。


举例说明

例子1:三个团队

组织架构 系统架构

┌─────────────┐ ┌─────────────┐

│ 前端团队 │ │ 前端应用 │

│ 5人 │ │ │

└──────┬──────┘ └──────┬──────┘

│ │ API调用

│ 开会沟通 │

▼ ▼

┌─────────────┐ ┌─────────────┐

│ 后端团队 │ │ 后端服务 │

│ 8人 │ │ │

└──────┬──────┘ └──────┬──────┘

│ │ SQL

│ 发邮件沟通 │

▼ ▼

┌─────────────┐ ┌─────────────┐

│ DBA团队 │ │ 数据库 │

│ 3人 │ │ │

└─────────────┘ └─────────────┘

团队之间有边界 → 系统之间就有接口

例子2:按业务拆团队

组织架构 系统架构

┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐

│ 订单组 │ │ 支付组 │ │ 订单服务 │ │ 支付服务 │

│ 5人 │ │ 4人 │ │ │ │ │

└───────────┘ └───────────┘ └─────┬─────┘ └─────┬─────┘

│ │

▼ ▼

┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐

│ 用户组 │ │ 商品组 │ │ 用户服务 │ │ 商品服务 │

│ 4人 │ │ 3人 │ │ │ │ │

└───────────┘ └───────────┘ └───────────┘ └───────────┘

4个团队 → 4个服务

例子3:创业公司

组织架构 系统架构

┌─────────────────────────┐ ┌─────────────────────────┐

│ │ │ │

│ 全栈团队 5人 │ │ 单体应用 │

│ 前后端+DBA都在一起 │ │ 一个仓库一个服务 │

│ │ │ │

└─────────────────────────┘ └─────────────────────────┘

没拆团队 → 没必要拆服务


康威定律的推论

推论1:强扭的瓜不甜

❌ 错误做法:

复制代码
 组织架构              系统架构
 ┌─────────┐          ┌───┐ ┌───┐ ┌───┐
 │ 一个团队 │    →     │ A │ │ B │ │ C │   硬拆微服务
 │  5人    │          └───┘ └───┘ └───┘
 └─────────┘

 结果:5个人维护3个服务,扯皮、混乱、低效

推论2:系统跟着组织走

✅ 正确做法:

复制代码
 先拆团队,再拆服务

 第一步:组织先拆
 ┌─────────┐          ┌─────────┐
 │ 团队A   │          │ 团队B   │
 └─────────┘          └─────────┘

 第二步:系统跟着拆
 ┌─────────┐          ┌─────────┐
 │ 服务A   │   ←──→   │ 服务B   │
 └─────────┘          └─────────┘

推论3:逆康威定律

如果想改变系统架构,先改变组织架构

想要:微服务架构

必须:先把团队拆成多个独立小组

想要:中台架构

必须:先成立中台团队


现状:

├─ 团队人数:不多

├─ 组织架构:没有拆成几十个小组

├─ 系统架构:几十个微服务

└─ 结论:违背康威定律 ❌

问题:

├─ 人没那么多,服务拆那么细

├─ 沟通成本在团队内部,系统边界却在外部

├─ 一个人跨N个服务开发

└─ 架构和组织不匹配

回归单体:

├─ 组织是一个团队

├─ 系统就该是一个整体

├─ 符合康威定律 ✅

└─ 自然、高效、低成本


总结

康威定律核心 说明
组织决定架构 不是架构决定组织
团队边界=服务边界 团队怎么分,服务就怎么分
先拆人,再拆系统 顺序不能反
小团队用单体 这是自然规律

架构不是技术问题,是组织问题。

相关推荐
TDengine (老段)2 小时前
TDengine RAFT共识协议 — 选举、日志复制、快照与仲裁
android·大数据·数据库·物联网·架构·时序数据库·tdengine
码云之上2 小时前
万星入坞:我们如何用三层插件体系干掉巨石应用
前端·架构·前端框架
kyriewen2 小时前
一口气讲清楚 Monorepo、Turborepo、pnpm、Changesets 到底是什么?
前端·架构·前端工程化
zzmgc44 小时前
纯静态 + Web Worker + 虚拟滚动:我是怎么让浏览器吃下 10MB JSON 不卡的
前端·架构
星辰_mya4 小时前
彩云之上——[特殊字符]的架构师
java·后端·微服务·面试·架构
2601_954526755 小时前
逆向解析Temu底层动销算法:基于API高并发轮询与全域存量透视的自动化架构重构
算法·架构·自动化
小蒋聊技术5 小时前
电商系列第七课:售后与物流中心 —— 服务质量提升与智能物流路由
架构·系统架构·电商
EBABEFAC6 小时前
架构沟通能力提升
架构
RingWu7 小时前
微服务架构-全链路追踪
微服务·云原生·架构
爱勇宝7 小时前
别焦虑,也别躺平:给年轻程序员的一封信
前端·后端·架构