微服务架构的理论基础 - 康威定律

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证,这就是康威定律。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》在InfoQ上的一个分

概述

关于微服务的介绍,可以参考微服务那点事

微服务是最近非常火热的新概念,大家都在追,也都觉得很对,但是似乎没有很充足的理论基础说明这是正确的,给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》(是Design RESTful API的作者)在InfoQ上的一个分享,觉得很有帮助,结合自己的一些思考,整理了该演讲的内容。

可能出乎很多人意料之外的一个事实是,微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了,而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证,这就是康威定律(Conway's Law)

screenshotscreenshot

在康威的这篇文章中,最有名的一句话就是:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

中文直译大概的意思就是:设计系统的组织,其产生的设计等同于组织之内、组织之间的沟通结构。看看下面的图片(来源于互联网,侵删),再想想Apple的产品、微软的产品设计,就能形象生动的理解这句话。
screenshot

用通俗的说法就是:组织形式等同系统设计。

这里的系统按原作者的意思并不局限于软件系统。据说这篇文章最初投的哈佛商业评论,结果程序员屌丝的文章不入商业人士的法眼,无情被拒,康威就投到了一个编程相关的杂志,所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律(law),只是描述了作者自己的发现和总结。后来,在Brooks Law著名的人月神话中,引用这个论点,并将其“吹捧”成了现在我们熟知“康威定律”。

康威定律详细介绍

Mike从他的角度归纳这篇论文中的其他一些核心观点,如下:

  • 第一定律

    • Communication dictates design
    • 组织沟通方式会通过系统设计表达出来
  • 第二定律

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

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

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

人是复杂社会动物

  • 第一定律

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

组织的沟通和系统设计之间的紧密联系,在很多别的领域有类似的阐述。对于复杂的系统,聊设计就离不开聊人与人的沟通,解决好人与人的沟通问题,才能有一个好的系统设计。相信几乎每个程序员都读过的《人月神话》(1975年,感觉都是老古董了,经典的就是经得起时间考验)里面许多观点都和这句话有异曲同工之妙。

screenshotscreenshot

比如《人月神话》中最著名的一句话就是

Adding manpower to a late software project makes it later --Fred Brooks, (1975)

Boss们都听到了吗?为了赶进度加程序员就像用水去灭油锅里的火一样(无奈大家还是前赴后继)。

为什么?人月神话也给出了很简洁的答案:沟通成本 = n(n-1)/2,沟通成本随着项目或者组织的人员增加呈指数级增长。是的,项目管理这个算法的复杂度是O(n^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

所以知道为什么互联网创业公司都这么小了吧,必须小啊,不然等CEO和所有人讲一遍创业的想法后,风投的钱都烧完了。

Mike还举了一个非常有意思的理论,叫“Dunbar Number”,这是一个叫Dunbar(废话)生物学家在1992年最早提出来的。最初,他发现灵长类的大脑容量和其对应的族群大小有一定关联,进而推断出人类的大脑能维系的关系的一些有趣估计。举例来说

  • 亲密(intimate)朋友: 5
  • 信任(trusted)朋友: 15
  • 酒肉(close)朋友: 35
  • 照面(casual)朋友: 150

screenshot

是不是和上面的沟通成本的数字很貌似有关联?是的,我们的大脑智力只能支持我们维系这么多的关系。(大家都知道这不是程序猿擅长的领域,在开发团队里,这个值应该更小,估计和猿差不多 -_-凸 )

沟通的问题,会带来系统设计的问题,进而影响整个系统的开发效率和最终产品结果。

一口气吃不成胖子,先搞定能搞定的

  • 第二定律:

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

Eric Hollnagel是敏捷开发社区的泰斗之一,在他《Efficiency-Effectiveness Trade Offs》 一书中解释了类似的论点。

Problem too complicated? Ignore details.
Not enough resources?Give up features.

      --Eric Hollnagel (2009)

screenshotscreenshot

系统越做越复杂,功能越来越多,外部市场的竞争越来越剧烈,投资人的期待越来越高。但人的智力是有上限的,即使再牛逼的人,融到钱再多也不一定招到足够多合适的人。对于一个巨复杂的系统,我们永远无法考虑周全。Eric认为,这个时候最好的解决办法竟然是——“破罐子破摔”。

其实我们在日常开发中也经常碰到。产品经理的需求太复杂了?适当忽略一些细节,先抓主线。产品经理的需求太多了?放弃一些功能。

据说Eric被一家航空公司请去做安全咨询顾问,复杂保证飞机飞行系统的稳定性和安全性。Eric认为做到安全有两种方式:

  • 常规的安全指的是尽可能多的发现并消除错误的部分,达到绝对安全,这是理想。
  • 另一种则是弹性安全,即使发生错误,只要及时恢复,也能正常工作,这是现实。

对于飞机这样的复杂系统,再牛逼的人也无法考虑到漏洞的方方面面,所以Eric建议放弃打造完美系统的想法,而是通过不断的试飞,发现问题,确保问题发生时,系统能自动复原即可,而不追求飞行系统的绝对正确和安全。

下面的图很好的解释了这个过程:
screenshot
听着很耳熟不是吗?这不就是 持续集成 和敏捷开发吗?的确就是。

另一方面,这和互联网公司维护的分布式系统的弹性设计也是一个道理。对于一个分布式系统,我们几乎永远不可能找到并修复所有的bug,单元测试覆盖1000%也没有用,错误流淌在分布式系统的血液里。解决方法不是消灭这些问题,而是容忍这些问题,在问题发生时,能自动回复,微服务组成的系统,每一个微服务都可能挂掉,这是常态,我们只有有足够的冗余和备份即可。即所谓的 弹性设计(Resilience) 或者叫高可用设计(High Availability)。

种瓜得瓜,做独立自治的字系统减少沟通成本

  • 第三定律

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

screenshot

这是康威第一定律组织和设计间内在关系的一个具体应用。更直白的说,你想要什么样的系统,就搭建什么样的团队。如果你的团队分成前端团队,Java后台开发团队,DBA团队,运维团队,你的系统就会长成下面的样子:
screenshot

相反,如果你的系统是按照业务边界划分的,大家按照一个业务目标去把自己的模块做出小系统,小产品的话,你的大系统就会长成下面的样子,即微服务的架构
screenshot

微服务的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口,在一个团队内全栈,让团队自治,原因就是因为如果团队按照这样的方式组建,将沟通的成本维持在系统内部,每个子系统就会更加内聚,彼此的依赖耦合能变弱,跨系统的沟通成本也就能降低。

合久必分,分而治之

  • 第四定律

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

前面说了,人是复杂的社会动物,人与人的通过非常复杂。但是当我们面对复杂系统时,又往往只能通过增加人力来解决。这时,我们的组织一般是如何解决这个沟通问题的呢?Divide and conquer,分而治之。大家看看自己的公司的组织,是不是一个一线经理一般都是管理15个人以下的?二线经理再管理更少的一线?三线再管理更少的,以此类推。(这里完全没有暗示开发经理比程序猿更难管理)

所以,一个大的组织因为沟通成本/管理问题,总为被拆分成一个个小团队。

  • 创业的想法太好了,反正风投钱多,多招点程序猿
  • 人多管不过来啊,找几个经理帮我管,我管经理
  • 最后, 康威定律 告诉我们组织沟通的方式会在系统设计上有所表达,每个经理都被赋予一定的职责去做大系统的某一小部分,他们和大系统便有了沟通的边界,所以大的系统也会因此被拆分成一个个小团队负责的小系统(微服务是一种好的模式)

康威定律如何解释微服务的合理性

了解了康威定律是什么,再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。

  • 人与人的沟通是非常复杂的,一个人的沟通精力是有限的,所以当问题太复杂需要很多人解决的时候,我们需要做拆分组织来达成对沟通效率的管理
  • 组织内人与人的沟通方式决定了他们参与的系统设计,管理者可以通过不同的拆分方式带来不同的团队间沟通方式,从而影响系统设计
  • 如果子系统是内聚的,和外部的沟通边界是明确的,能降低沟通成本,对应的设计也会更合理高效
  • 复杂的系统需要通过容错弹性的方式持续优化,不要指望一个大而全的设计或架构,好的架构和设计都是慢慢迭代出来的

带来的具体的实践建议是:

  • 我们要用一切手段提升沟通效率,比如slack,github,wiki。能2个人讲清楚的事情,就不要拉更多人,每个人每个系统都有明确的分工,出了问题知道马上找谁,避免踢皮球的问题。
  • 通过MVP的方式来设计系统,通过不断的迭代来验证优化,系统应该是弹性设计的。
  • 你想要什么样的系统设计,就架构什么样的团队,能扁平化就扁平化。最好按业务来划分团队,这样能让团队自然的自治内聚,明确的业务边界会减少和外部的沟通成本,每个小团队都对自己的模块的整个生命周期负责,没有边界不清,没有无效的扯皮,inter-operate, not integrate。
  • 做小而美的团队,人多会带来沟通的成本,让效率下降。亚马逊的Bezos有个逗趣的比喻,如果2个披萨不够一个团队吃的,那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7,8人左右(包含前后端测试交互用研等,可能身兼数职)。

再对应下衡量微服务的标准,我们很容易会发现他们之间的密切关系:

  • 分布式服务组成的系统
  • 按照业务而不是技术来划分组织
  • 做有生命的产品而不是项目
  • Smart endpoints and dumb pipes(我的理解是强服务个体和弱通信)
  • 自动化运维(DevOps)
  • 容错
  • 快速演化

参考资料

目录
相关文章
|
3天前
|
消息中间件 设计模式 数据库
深入探讨后端微服务架构中的分布式事务处理
【2月更文挑战第6天】在当今互联网应用开发领域,后端微服务架构已经成为一种常见的设计模式。本文将深入探讨在后端微服务架构中如何有效处理分布式事务,包括事务管理、一致性保障和异常处理策略,帮助开发者更好地应对复杂的业务场景。
92 4
|
6天前
|
监控 数据可视化 关系型数据库
微服务架构+Java+Spring Cloud +UniApp +MySql智慧工地系统源码
项目管理:项目名称、施工单位名称、项目地址、项目地址、总造价、总面积、施工准可证、开工日期、计划竣工日期、项目状态等。
139 6
|
9天前
|
人工智能 监控 安全
java基于微服务架构的智慧工地监管平台源码带APP
劳务管理: 工种管理、分包商管理、信息采集、班组管理、花名册、零工采集、 现场统计、考勤管理、考勤明细、工资管理、零工签证
199 4
|
1天前
|
Java API 调度
从Spring Cloud 开始,聊一聊微服务架构的设计与实战
随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。
22 1
从Spring Cloud 开始,聊一聊微服务架构的设计与实战
|
5天前
|
存储 监控 持续交付
探讨后端微服务架构的演进与优化
【2月更文挑战第4天】随着互联网应用的快速发展,后端微服务架构作为一种灵活、可扩展的架构模式,逐渐成为各大企业和组织的首选。本文将从微服务架构的定义和特点入手,探讨其在实际应用中的演进过程以及优化策略,帮助读者更好地理解并应用后端微服务架构。
32 2
|
22天前
|
开发者 Docker 微服务
深入浅出:使用Docker容器化部署微服务架构
在当今快速迭代的软件开发环境中,微服务架构因其高度解耦和独立性而成为企业首选。然而,微服务的管理和部署可能会变得复杂和繁琐。本文将探讨如何利用Docker,一个轻量级的容器化技术,来简化和加速微服务的部署。我们将从Docker的基础概念入手,详细介绍如何创建、配置和运行微服务容器,最后讨论Docker在微服务架构中的优势和挑战。本文旨在为开发者提供一条清晰的路径,通过容器化技术实现微服务架构的高效部署和管理。
62 0
|
22天前
|
Kubernetes 开发者 Docker
深入浅出:使用Docker容器化部署微服务架构
在当今快速演进的软件开发领域,微服务架构因其高度的模块化和可伸缩性而受到广泛欢迎。然而,微服务的部署和管理也带来了新的挑战。本文旨在通过深入浅出的方式,探讨如何利用Docker容器技术有效地部署和管理微服务架构。我们将从Docker的基本概念出发,逐步深入到如何构建、部署微服务,并讨论在此过程中可能遇到的常见问题及其解决策略。本文不仅适合刚接触Docker和微服务的新手,也为有经验的开发者提供了实用的参考。
44 1
|
22天前
|
JSON JavaScript Docker
深入浅出:使用Docker容器化部署微服务架构
本文旨在向读者展示如何利用Docker技术高效地构建和部署微服务架构。通过深入浅出的方式,我们将探索Docker的基本概念、容器化的优势以及如何将其应用于微服务架构中。此外,文章还将提供一个简单的示例,指导读者实践如何使用Docker将一个现有的后端应用容器化,并部署到本地开发环境中。不同于传统的摘要,这里我们强调实践操作的重要性,鼓励读者通过实际操作来加深对Docker和微服务架构的理解。
39 1
|
22天前
|
Java 开发者 Docker
深入浅出:使用Docker容器化部署微服务架构
在本文中,我们将探索Docker容器技术如何革新微服务架构的部署方式,提高开发效率和应用的可扩展性。不同于传统摘要的概述风格,我们将通过一个实际案例,步骤明晰地展示如何将一个简单的微服务应用容器化,并在Docker环境中部署运行。本文旨在为开发者提供一个清晰、易懂的指南,帮助他们理解容器化技术的基本原理和操作流程,无论是初学者还是有经验的开发人员都能从中获益。
|
22天前
|
存储 Kubernetes Docker
深入浅出:使用Docker容器化部署微服务架构
在当今快速迭代的软件开发周期中,微服务架构凭借其高度的模块化和灵活性成为了众多企业的首选。然而,随之而来的是对环境一致性和服务部署效率的挑战。本文将探讨如何利用Docker这一轻量级容器技术,实现微服务的快速、一致和可靠部署。通过深入浅出的方式,我们将介绍Docker的基本概念、容器化微服务的优势以及步骤详解,旨在为读者提供一个清晰的实践指南,帮助他们在微服务架构的部署过程中提升效率和可靠性。
16 0

相关产品

  • 微服务引擎
  • 服务网格