康威定律对微服务的启示

● 康威定律(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个服务开发

└─ 架构和组织不匹配

回归单体:

├─ 组织是一个团队

├─ 系统就该是一个整体

├─ 符合康威定律 ✅

└─ 自然、高效、低成本


总结

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

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

相关推荐
xu_wenming3 小时前
嵌入式软件架构中的6种解耦艺术
c语言·驱动开发·嵌入式硬件·架构
ZGIAI3 小时前
ZGI Workflow 变量池:接住节点输出
人工智能·架构
ZGIAI3 小时前
ZGI 记忆隔离:多人共用不串号
人工智能·架构
星栈独行4 小时前
决定 Agent 交付下限的「操作系统」:Harness 六层架构拆解
人工智能·架构
Cicada1284 小时前
配置文件格式选择指南:JSON、YAML、TOML、INI、ENV、XML
架构
美狐美颜SDK开放平台6 小时前
视频美颜SDK是什么?直播APP开发中美颜功能实现方式介绍
深度学习·架构·实时互动·音视频·视频美颜sdk
AKCJDJ6 小时前
k8s的管理及控制器管理
云原生·容器·kubernetes
画中有画7 小时前
论多源异构数据集成与数据架构设计
架构
风萧何8 小时前
架构艺术,是权衡的艺术。
前端·javascript·架构