康威定律对微服务的启示

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

└─ 架构和组织不匹配

回归单体:

├─ 组织是一个团队

├─ 系统就该是一个整体

├─ 符合康威定律 ✅

└─ 自然、高效、低成本


总结

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

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

相关推荐
迎仔2 分钟前
13-云原生大数据架构介绍:大数据世界的“弹性城市”
大数据·云原生·架构
小码哥06825 分钟前
代驾系统微服务容器化部署与灰度发布流程
微服务·云原生·代驾系统·代驾·代驾服务·同城代驾
江畔何人初1 小时前
k8s静态pod
云原生·容器·kubernetes
硅基流动1 小时前
从云原生到 AI 的跃迁探索之路|开发者说
大数据·人工智能·云原生
小二·2 小时前
Go 语言系统编程与云原生开发实战(第10篇)性能调优实战:Profiling × 内存优化 × 高并发压测(万级 QPS 实录)
开发语言·云原生·golang
Crazy Struggle2 小时前
推荐 .NET 8.0 开源项目伪微服务框架
微服务·.net 8.0·微服务框架
ALex_zry2 小时前
分布式缓存与微服务架构的集成
分布式·缓存·架构
贾修行2 小时前
企业级网络安全架构实战:从防火墙部署到远程办公全解析
web安全·架构·智能路由器
一只专注api接口开发的技术猿3 小时前
淘宝商品详情API的流量控制与熔断机制:保障系统稳定性的后端设计
大数据·数据结构·数据库·架构·node.js
小马爱打代码3 小时前
熔断限流从入门到实战:打造高可用微服务架构
微服务·云原生·架构