康威定律对微服务的启示

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

└─ 架构和组织不匹配

回归单体:

├─ 组织是一个团队

├─ 系统就该是一个整体

├─ 符合康威定律 ✅

└─ 自然、高效、低成本


总结

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

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

相关推荐
极限实验室16 小时前
APM(一):Skywalking 与 Easyearch 集成
数据库·云原生
云空16 小时前
《解码机器人操作系统:从核心架构到未来趋势的深度解析》
架构·机器人
_oP_i20 小时前
Docker 整体架构
docker·容器·架构
canonical_entropy20 小时前
Nop入门:增加DSL模型解析器
spring boot·后端·架构
ascarl201021 小时前
Kubernetes 环境 NFS 卡死问题排查与解决纪要
云原生·容器·kubernetes
jinxinyuuuus21 小时前
局域网文件传输:WebRTC与“去中心化应用”的架构思想
架构·去中心化·webrtc
阿里云云原生21 小时前
快速构建企业 AI 开放平台,HiMarket 重磅升级
云原生
狗哥哥1 天前
从零到一:打造企业级 Vue 3 高性能表格组件的设计哲学与实践
前端·vue.js·架构
小马哥编程1 天前
【软考架构】滑动窗口限流算法的原理是什么?
java·开发语言·架构