一、康威定律基本概念

康威定律

康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。

康威定律可谓软件架构设计中的第一定律，起初只是在杂志上的发表，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。

只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四个定律：

• 第一定律 组织沟通方式会通过系统设计表达出来。
• 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
• 第三定律 线型系统和线型组织架构间有潜在的异质同态特性。
• 第四定律 大的系统组织总是比小系统更倾向于分解。

第一定律

Communication dictates design。
组织沟通方式决定系统设计。

这条定律重点是讲组织架构和沟通对系统设计的影响。组织的沟通和系统的设计之间紧密相连，特别是复杂系统，解决好人与人的沟通才能有一个更好的系统设计。

《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律：沟通成本 = n(n-1)/2。举例说明一下：

• 5人项目组，需要沟通的渠道是 5*(5–1)/2 = 10
• 15人项目组，需要沟通的渠道是15*(15–1)/2 = 105
• 50人项目组，需要沟通的渠道是50*(50–1)/2 = 1,225
• 150人项目组，需要沟通的渠道是150*(150–1)/2 = 11,175

这也是为什么互联网公司都追求小团队的原因之一。沟通的问题会带来系统设计的问题，进而影响整个系统的开发效率和最终产品结果。

第二定律

There is never enough time to do something right, but there is always enough time to do it over。
时间再多一件事情也不可能做的完美，但总有时间做完一件事情。

人手永远是不够的，事情永远是做不完的，但可以一件一件来。这不就是软件行业中“敏捷开发”模式所解决的问题吗。面对这样的状况，敏捷开发可以做到不断迭代、持续交付、快速验证和反馈，并持续改进。

再牛的开发也会写出bug，再全面的测试覆盖率也无法测出所有的问题。解决方案不是消灭这些问题，是容忍一些问题的存在，然后通过适当的设计（冗余、监控、高可用设计）当问题发生时能够快速解决。

几个开发人员的小公司，去追求微服务、去追求中台架构，这是追求完美吗？不是，是找死。

好的架构不是买来的，也不是设计出来的，而是根据业务落地生根长期演化来的。

第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization。
线型系统和线型组织架构间有潜在的异质同态特性。

这一定律是第一定律的具体应用。想象一下如果公司的组织架构是这样的：团队是分布式，每个团队都包含产品、研发、测试、运维等角色。而此时系统是单块的，项目沟通和协调的成本是巨大的，弄不好还会打起来。

如果将单块的系统拆分成微服务，每个团队负责自己的部分，对外提供对应的接口即可，互不干扰。系统效率将得到提升。这与软件设计中的高内聚、低耦合是相通的。

直白的说就是想要什么的系统就搭建什么样的团队，有什么样的团队就搭建什么样的系统。需要前后端分离的系统就搭建前后端分离的团队，反之，拥有前后端分离的团队，可以设计前后端分离的系统。当然，如果能统筹管理，拥有重组团队或设计系统架构的权利，那就再好不过了。通常情况下让两者形成1：1的映射关系，更加高效。

第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。
大的系统组织总是比小系统更倾向于分解。

“话说天下大势，分久必合，合久必分。”系统越复杂，越需要增加人手，人手越多，沟通成本也呈指数增长。分而治之便是大多数公司选择的解决方案。分不同的层级，分不同的小团队，让团队内部完成自治理，然后统一对外沟通。

 

---

二、每个架构师都应该研究下康威定律

背景

今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构，之前的工作过的公司 eBay、携程、唯品会都是平台型互联网公司，所以今天主要带着平台架构视角和大家分享心得体会。架构的视角每个人都不一样，可以说一万种眼光，有业务架构、安全架构、平台架构、数据架构，各不相同，这里仅是我的一家之言，欢迎大家加入『聊聊架构』社群参与讨论。今天聊的话题主要包括以下几点：

1. 我对架构定义的理解
2. 架构的迭代和演化性
3. 构建闭环反馈架构（Architecting for closed loop feedback）
4. 谈谈微服务架构和最新主题
5. 架构和组织文化关系
6. 架构师心态和软技能
7. 我对一些架构师争议主题的看法
8. 我对架构定义的理解

大概在 7~8 年前，我曾经有一个美国对口的架构师导师，他对我讲架构其实是发现利益相关者（stakeholder），然后解决他们的关注点（concerns），后来我读到一本书《软件系统架构: 使用视点和视角与利益相关者合作》，里面提到的理念也是这样说：系统架构的目标是解决利益相关者的关注点。

这是从那本书里头的一张截图，我之前公司分享架构定义常常用这张图，架构是这样定义的：

1. 每个系统都有一个架构
2. 架构由架构元素以及相互之间的关系构成
3. 系统是为了满足利益相关者（stakeholder）的需求而构建的
4. 利益相关者都有自己的关注点（concerns）
5. 架构由架构文档描述
6. 架构文档描述了一系列的架构视角
7. 每个视角都解决并且对应到利益相关者的关注点。

架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户 / 用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者，沟通不充分，都会造成架构有欠缺，不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的，比如管理层（可管理性）vs 技术方（性能），业务方（多快好省）vs 技术方（可靠稳定），这需要架构师去灵活平衡，如何平衡体现了架构师的水平和价值。

关于架构的第二点定义是说架构主要关注非功能性需求（non-functional requirements），即所谓的 -abilities。

这个是我上次公司内分享的一个图。

这个是 slideshare 一个 ppt 里头截取的，两个图都是列出了架构的非功能性关注点；关于架构的水平该如何衡量，去年我看到一句话，对我影响很大。

Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

翻译为中文就是，架构表示对一个系统的成型起关键作用的设计决策，架构定系统基本就成型了，这里的关键性可以由变化的成本来决定。这句话是 Grady Booch 说的，他是 UML 的创始人之一。

进一步展开讲，架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能的小。

我刚入软件开发这个行业之初，谈的架构主要是性能，高可用等等。现在，见过无数遗留系统，特别是国内企业 IT 的现状，无数高耦合的遗留系统，不良的架构像手铐一样牢牢地限制住业务，升级替换成本非常巨大， 所以我更加关注可理解，可维护性，可扩展性，成本 。我想补充一句，创业公司创业之初获得好的架构师或技术 CTO 非常重要。

架构的迭代和演化性

我是属于老一代的架构师，99 年参加工作。职业初学了很多 RUP，统一软件过程的理念。RUP 的理念对我的架构有很深的影响，RUP 总结起来就是三个特点：

1. 用例和风险驱动 Use Case and risk driven
2. 架构中心 Architecture centric
3. 迭代和增量 Iterative and incremental

RUP 很注重架构，提倡以架构和风险驱动，项目开始一定要做端到端的原型（prototype）；通过压测验证架构可行性，然后在原型基础上持续迭代和增量式开发，开发 -> 测试 -> 调整架构 -> 开发，循环，如下图所示：

从上图可以看出架构师要尽可能写代码，做测试，纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域）。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能形成有效快速的反馈，产品不满足最终用户需求，继续看下面两个图：

第一个图是讲最小可用产品（Minimum Viable Product， MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。第二个图是过度工程（Over Engineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。注意，在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。

另外，多年的经验告诉我，架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的。

给大家推荐两篇不错的微信文章（微信不能插入链接，根据题目 Google 下即可）：

1. 58 同城沈剑：好的架构源于不停地衍变，而非设计
2. 宜人贷系统架构–高并发下的进化之路

两篇文章其实都是讲架构的迭代和演化性，值得每个架构师学习吸收。

构建闭环反馈架构

先分享一个链接，这几年对我架构影响最深的一篇文章。这篇文章是关于 DevOps 的，但对系统架构同样适用：

http://itrevolution.com/the-three-ways-principles-underpinning-devops/

这篇文章讲述了企业通向 DevOps 的三条必经之路，我们来看看这三条道路对架构师的启示。

第一条道路，系统思维，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（System Thinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。

第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师，也是中国学生的普遍问题，就是生产运维意识不足（监控是系统反馈的重要环节）。有两句号这样讲的：

1. no measurement, no improvement 没有测量，就没有改进和提升
2. What your measure is what you get 你测量什么，就得到什么

没有监控或者监控不完善的系统相当于裸奔，开车上高速无仪表盘。有一篇很不错的关于测量驱动开发的文章，在 InfoQ 上的，向大家推荐：

http://www.infoq.com/cn/articles/metrics-driven-development

这篇文章提出了度量驱动开发的理念，即所谓 MDD，在系统，应用和业务三个层次，通过三级监控，构建三个反馈环，在监控测量基础上持续改进系统和架构，我最近也在参考这个理念设计一个电商平台的技术架构，见下图：

这是一个电商平台的架构，整个体现了闭环架构的思想，右侧是整个平台的反馈监控环节。具体如下：

1. 系统层监控计算网络存储，构建系统层的反馈环
2. 应用服务层，监控业务、应用、服务，甚至整个研发流程，构建应用和服务层的反馈环
3. 客户体验层，监控端用户和分析网站用户的行为，构建和客户的反馈环

下面这个图展示了系统提升和改进的一般方法：

收集 -> 测量 -> 调整 -> 闭环重复，在有测量数据和反馈的基础上，系统、应用、流程和客户体验才有可能获得持续的提升和改善，否则没有数据的所谓改进只能靠拍脑袋或者说猜测。

第三条道路，鼓励勇于承担责任，冒险试错和持续提升的文化。这点是最难的，一般和企业人才密度有关。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。

架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构（Architecting for closed loop feedback），提升整个系统效能。下图的 DevOps 和每日交付是每一个互联网系统架构师的梦想和努力的方向。

谈谈微服务架构

微服务我想大家都听得很多了，我本人也非常关注和推崇微服务，从技术角度讲，我认为微服务主要体现的是单一职责和关注分离的思想，从单进程模块化进一步拓展到跨进程分布式的模块化。微服务是独立的开发、测试、部署和升级单元，正如我在第一点架构定义中提到的，微服务中每个服务可以独立演变，它的 cost of change 比较小，整体架构比较灵活，是一种支持创新的演化式架构。

去年 MartinFowler 写了两篇文章，给微服务泼冷水的，建议大家好好读下。

1. http://martinfowler.com/bliki/MicroservicePrerequisites.html
2. http://martinfowler.com/bliki/MicroservicePremium.html

这个图讲什么时候该引入微服务。微服务有额外成本的，需要搭建框架、发布、监控等基础设施。初创和小规模团队不建议采用。主要决定是因素系统复杂性和团队规模，当到达一个点，单块架构严重影响效率才考虑 。另外补充一点，微服务更多是关于组织和团队，而不是技术。

架构和组织文化关系

再谈一下康威定律：Conway’s law: Organizations which design systems[…] are constrained to produce designs which are copies of the communication structures of these organizations.
（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。 )

从单块架构到微服务架构是这个定律的很好体现。

团队是分布式的，系统架构是单块的，开发，测试，部署协调沟通成本大，严重影响效率，严重时团队之间还容易起冲突。

将单块架构解耦成微服务，每个团队开发，测试和发布自己负责的微服务，互不干扰，系统效率得到提升。

可见，组织和系统架构之间有一个映射关系（1 ~ 1 mapping），两者不对齐就会出各种各样的问题，一方面，如果你的组织结构和文化结构不支持，你也无法成功建立高效的系统架构，例如集中式和严格职能（业务, Dev, QA, Deployment, Ops）的企业，很难推行微服务和 DevOps，推行 Docker/PaaS 平台也会比较困难，这样的组织职能之间都倾向于局部优化（local optimization），无法形成有效的合作和闭环。

反过来也是成立的，如果你的系统设计或者架构不支持，那么你就无法成功建立一个有效的组织；作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。

架构师心态和软技能

空杯，或者说开放心态（open minded）是一个成熟架构师的应有心态，stay hungry, stay foolish， 心态有多开放，视野就有多开阔。来自《高效能人士的七个习惯~ 史蒂芬~ 柯维》的一句话送给每一个架构师 :

如果一位具有相当聪明才智的人跟我意见不同，那么对方的主张必有我尚未体会的奥秘，值得加以了解。与人合作最重要的是，重视不同个体的不同心理、情绪与智能，以及个人眼中所见的不同世界。与所见略同的人沟通，益处不大，要有分歧才有收获。

另外再推荐一个本书《软件架构师的 12 项修炼》，这书中三个观点很值得每个架构师学习领会:

1. soft skills are always hard than hard skills，软技能比硬技能难
2. choosing relationship over correctness ，注重关系重于谁对谁错
3. 架构的政治性，在中大型公司里工作的架构师尤其要学习

政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。

架构师如何提升？实战，实战，实战！规划职业，找好的团队和项目，总结分享，学习 GitHub 开源项目，尽可能参与和开创自己的开源项目和产品，并长期积累。

我对一些架构师争议主题的看法

主要争议是两个话题：

1. 技术和业务的关系。
2. 架构师要写代码吗？

架构师怎么回答这类问题？一个成熟架构师的口头禅：视情况而定，不一定，是也不是，it depends。技术和业务，架构师要理解业务吗？看产品和客户，如果是业务性产品，肯定要理解业务，如果是技术型产品，就不一定。

架构师要写代码？也不一定，个人觉得尽可能要写，如果你写过十年以上代码了，每年不少于 2 万行，都玩通了，可以不写。另外架构师如果写代码，要把控度，不要一头钻入代码，花大量时间解决细节和复杂性问题，忽视全局和系统性问题。

最后

我想说中国现在的互联网发展趋势很好，越来越多的人加入架构师这个行业，这个行业正在“万物生长”。 但是我们现在还没有马丁福勒，adrian cockcroft 这样的架构牛人物，我辈需不断努力，期待中国 10~20 年后出现超过十个马丁福勒，adrian cockcroft 这样的大牛神级人物。我们必不可停止探索，而一切探索的尽头，就是重回起点，并对起点有首次般的认识。

 

 

参考资料：

1. https://zhuanlan.zhihu.com/p/359452953
2. https://www.infoq.cn/article/every-architect-should-study-conway-law
3. https://www.cnblogs.com/still-smile/p/11646609.html

 

标签：架构,沟通,康威,定律,系统,架构师,基本概念
来源： https://www.cnblogs.com/xuxh120/p/16138395.html