康威定律对微服务的启示

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

└─ 架构和组织不匹配

回归单体:

├─ 组织是一个团队

├─ 系统就该是一个整体

├─ 符合康威定律 ✅

└─ 自然、高效、低成本


总结

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

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

相关推荐
原则猫10 分钟前
曝光埋点
架构
运维全栈笔记2 小时前
K8S部署WordPress+MySQL:模块化YAML配置详解
服务器·mysql·docker·云原生·容器·kubernetes·服务发现
apollowing2 小时前
Avalonia UI 12.0.0 正式发布:架构演进和性能飞跃
ui·架构
heimeiyingwang3 小时前
【架构实战】管道模式与责任链模式实战
架构
前端不太难3 小时前
鸿蒙 App 架构升级:从页面到 System
架构·状态模式·harmonyos
眷蓝天3 小时前
k8s-pod资源对象实验
云原生·容器·kubernetes·pod资源对象
Mr.45673 小时前
SpringBoot多模块依赖冲突排查与架构优化实战(避坑指南)
java·spring boot·架构
easy_coder4 小时前
ReAct 进入死循环?用 Harness 把它拉回来
人工智能·架构·云计算
EasyDSS4 小时前
企业级融媒体生产管理平台/私有化音视频系统EasyDSS一体化架构打造全流程应急指挥视频会议体系
架构·音视频·媒体