康威法则–微服务架构的理论基础

康威法则–微服务架构的理论基础

介绍

微服务架构是一个新的概念,已经非常流行,并成为最近研究的热门话题。然而,微服务的实施仍然是松散的,也没有理论上的证据证明其有效性。

你可能会惊讶地发现,微服务的概念是在五十多年前发表的一篇文章中首次提出的。此外,多年来,许多研究已经证明了那篇文章中提出的许多观点的准确性。

文章中介绍的一个基本概念是康威法则。虽然最初是为了指出分布式团队的缺陷,但许多组织已经应用康威法则来创建高效的微服务架构。

本文参照Mike Amundsen(《设计RESTful API》的作者)撰写的题为”远距离下的康威法则–分布式世界中的团队建设“的文章,探讨了康威法则的思想。

《康威法则》中最著名的一句话是:”。

“设计系统的组织被限制在生产设计上,这些设计是这些组织的通信结构的副本”。- Melvin Conway (1967)。

这意味着设计系统的组织被限制在生产复制组织的通信结构的设计上。下图说明了这个概念。

该图描述了组织的现有沟通结构,这与他们各自的产品开发过程相吻合。简单地说,组织结构等同于系统设计。

这里,作者提到的系统并不限于软件系统。还有人推测,《哈佛商业评论》最初拒绝了这篇文章。因此,康威把它提交给了一家编程杂志,这导致了人们误以为这篇文章是关于软件开发的。一开始,作者并没有把他的想法作为规律提出来,只是描述了他的发现和结论。当著名的《神话般的人月》一书介绍了布鲁克斯定律并引用了康威的一些观点后,康威的想法被普及为我们今天所熟知的康威定律。

康威法则解密

迈克-阿蒙森在他的文章中总结了一些核心观点,如下所述。

  • 法则1

1.沟通决定了设计

o 组织沟通的模式是通过系统设计来表达的

  • 法则2

1.永远没有足够的时间来做正确的事情,但总有足够的时间来重新做。

o 即使有无限的时间,也不可能完美地完成一项任务,但总是有时间来完成一项任务。

  • 法则3

1.从一个系统的线性图到其设计组织的线性图之间存在着同构关系

o 线性系统和线性组织结构之间存在同构关系

  • 法则4

1.大系统的结构在发展过程中往往会解体,在质量上比小系统更容易解体。

o 一个大的系统组织比一个小的组织更容易被分解

康威第一定律

“人类是复杂的社会动物”。

其他领域也提供了一些关于有组织的交流和系统设计之间紧密关系的说明。对于一个复杂的系统来说,设计主题总是涉及到人与人之间的交流。一个好的系统设计要解决关于这种交流的问题。1975年的经典时代《神话般的人月》中的许多观点与这一观点产生了共鸣。

神奇的人-月》中最令人难忘的一句话是。

“为一个晚期的软件项目增加人力会使它更晚”–Fred Brooks, (1975)

增加程序员的数量以跟上紧张的进度是许多组织的一个常见陷阱。虽然增加劳动力以提高产出是有道理的,但这并不适用于软件开发领域。

为什么会出现这种情况?神话般的人月提供了一个简单的答案。沟通成本随着项目或组织中人员数量的增加而呈指数级增长。沟通成本可以用公式n(n-1)/2来计算,其中项目管理算法的复杂性为O(n²)。下面的例子说明了沟通成本的概念。

  • 对于一个有五个成员的项目组,所需的沟通渠道数量为5*(5-1)/2=10。
  • 对于一个有15名成员的项目组,所需的沟通渠道数量为15*(15-1)/2=105。
  • 对于一个有50名成员的项目组,所需的沟通渠道数量为50*(50-1)/2=1225。
  • 对于一个有150名成员的项目组,所需的沟通渠道数量为150*(150-1)/2=11,175。

这也是互联网创业公司拥有小团队的主要原因。如果一家初创企业有太多的员工,那么在首席执行官向每个人介绍他/她的想法后,它将很快耗尽来自VC的投资。

生物学家罗宾-邓巴在1992年提出的另一个有趣的相关理论被称为 “邓巴数字”。起初,邓巴发现,一种灵长类动物的大脑容量与它的人口规模相关。然后他对一个人的大脑所能维持的关系数量进行了一些估计。例如,一个典型的人将有

  • 5个亲密的朋友
  • 15位值得信赖的朋友
  • 35位密友
  • 150位临时朋友

他们不是似乎与上述的沟通成本有关吗?是的,我们的大脑限制我们只能维持这么多的关系。(在一个开发团队中,这个数字可能更小)。

沟通问题会导致系统设计问题,影响整个系统的开发效率以及产品开发的最终结果。

康威第二定律

“罗马不是在一天之内建成的。先解决可以解决的问题。”

Erik Hollnagel,敏捷开发领域的巨头之一,在他的《效率-彻底的权衡》一书中解释了一些类似的观点。

“问题太复杂?忽略细节。没有足够的资源?放弃功能。”–Erik Hollnagel (2009)

系统的复杂性、功能的数量、市场竞争和投资者的期望都在增加,但人的智慧却始终不变。任何组织都不能确定是否能找到足够的人才,不管有多少能力和资金。对于一个极其复杂的系统,总会有一些东西被操作者忽视。埃里克认为,解决这个问题的最好办法就是 “顺其自然”。

在日常开发任务中,我们经常遇到这样的问题。产品经理提出的需求是否过于复杂?如果是这样,请忽略一些次要的需求,先关注主要的需求。产品经理的要求是否太多?如果是,就放弃一些功能。

报道指出,埃里克曾经收到一家航空公司的邀请,为一个飞行系统的稳定性和安全性提供咨询服务。埃里克认为,可以通过两种手段来确保安全。

  • 为了确保理想的安全,人们必须尽可能多地发现和消除错误。
  • 为确保弹性安全,人们必须及时处理发生的错误,以利于服务恢复。

对于像飞行系统这样复杂的系统,无论测试人员多么优秀,一些漏洞都有可能被忽略。因此,埃里克建议公司放弃建立一个完美系统的想法。相反,他建议相对的安全性和正确性,即承运人进行持续的飞行测试以发现问题,并确保系统在发生故障时能自动恢复。下图显示了对安全的不同解释。

这听起来很熟悉吗?这不是意味着持续集成和敏捷开发吗?绝对是的。

上述原则与适用于互联网公司所维护的分布式系统的弹性是一样的。即使单元测试覆盖了整个系统,也不可能识别和修复分布式系统中的所有bug。分布式系统很容易出现错误。最佳的解决方案不是消除所有的问题,而是容忍它们,并在发生故障时实施自动恢复。在一个由微服务组成的系统中,每个微服务都可能停止响应,这是完全正常的。我们只需要保证足够的冗余和备份,这也被称为弹性或高可用性设计。

康威第三定律

“创建独立的子系统以减少通信成本”。

这张图代表了根据康威第一定律,组织和系统设计之间内部关系的具体应用。简单地说,建立一个适合你想要的系统的团队。如果你有一个前端团队,一个Java后端开发团队,一个DBA团队,和一个O&M团队,你的系统就会是下面这个样子。

相反,如果业务边界在你的系统中产生了划分,所有成员将他们的模块变成小系统或产品,以解决相同的业务目标,你的大系统将看起来像一个微服务架构,如下所示。

团队之间的微服务的想法应该是 “相互操作,而不是整合”。互操作意味着定义系统的边界和接口,并为整个团队提供完整的堆栈,实现完全的自主性。如果一个团队的设置遵循这个猜想,就会产生系统内的通信成本,子系统会有更多的通信。这样的安排会使系统间的依赖性减少,系统间的通信成本降低。

康威第四定律

“分而治之”。

如上所述,人类是复杂的社会动物,人与人之间的沟通是非常复杂的。当涉及到一个系统时,我们往往选择增加人力来减少其复杂性。对于我们的组织来说,我们如何解决这样的沟通问题?分而治之。看看你的公司,在你的公司里,一个一线经理管理不到15个人,一个二线经理管理的人比一线经理少,一个三线经理管理的人比二线经理更少,等等,难道不是这样吗?(我并不是在暗示管理开发经理比管理程序员更难)。

因此,一个大型组织通常有小的团队部门,以减少沟通成本/管理问题。这里有一些情况供你考虑。

  • 创业的想法是如此之好。让我们招募更多的程序员。总之,风险投资公司给了我们一大笔钱。
  • 有太多的人需要管理。我需要找几个经理来帮忙,并向我报告。

康威法则还告诉我们,我们可以从系统设计中看到组织沟通模式。每个经理人都对一个大系统的一小部分负责某种职责。这样一来,他们和大系统之间就有了沟通的界限。因此,大系统包含了负责小系统的小部门团队(微服务很好地满足了这一点)。

康威法则和微服务

让我们来看看半个世纪前康威定律是如何为微服务提供理论基础的。

  • 人与人之间的沟通是复杂的,每个人用于沟通的精力是有限的。因此,当一个问题很复杂,需要协同解决的时候,我们需要对组织进行分工,以提高沟通效率。
  • 一个组织的成员在其中工作的系统设计,取决于成员之间的沟通。管理者可以调整分工模式,实现团队之间不同的沟通方式,这将影响系统的设计。
  • 如果一个子系统是通信的,并且有明确的外部通信边界,那么我们就可以有效地降低通信成本,相应的设计也会更加合适和高效。
  • 需要在容错性和弹性的帮助下不断优化一个复杂的系统。不要期待大而全的设计或架构,因为它们的发展是以迭代的方式进行的。

这里有一些实用的建议。

  • 充分利用所有可能的手段来提高沟通效率,如Slack、Github和Wiki。只与相关人员进行沟通。每个人和每个系统都必须有明确的职责。你必须知道在出现问题时应该向谁求助,以确保责任。
  • 在MVP模式下设计一个系统,以迭代的方式验证和优化系统,并确保系统具有弹性。
  • 采用一个与你的系统设计相一致的团队,如果可能的话,精简团队。一个似是而非的建议是,只要有可能,就按部门设立团队,这样每个团队都是自主的、沟通的。明确部门的界限,以减少外部的沟通成本。每个小团队必须在整个模块生命周期内对其模块负责。防止界限模糊和推卸责任。在各团队之间建立 “相互操作,而不是整合 “的关系。
  • 培养小型高效的团队,因为当团队成员数量增加时,成本会增加,效率会降低。亚马逊的首席执行官杰夫-贝索斯(Jeff Bezos)有一个有趣的经验法则:如果两个披萨不够一个团队吃,那么这个团队就过大了。通常情况下,一个互联网公司的小型产品团队由7至8人组成。(这些人包括负责前端和后端测试、交互和用户研究的人)。有些人可能有多项任务分配)。

当看到下面的微服务标准时,我们可以很容易地看到微服务和康威法则之间的密切关系。

  • 由分布式服务组成的系统
  • 按业务线划分的组织机构
  • 开发优秀的产品,而不是项目
  • 智能端点和哑巴管道(这指的是能力强的个人和轻度的通信工作)
  • 自动运行和管理(DevOps)。
  • 误差容限
  • 迅速演变

结论

本文介绍了康威定律,并探讨了它们是否为微服务的概念提供了理论上的解释。它详细讨论了四个定律以及每个定律的应用。第一条定律谈到了通信和系统设计之间的联系。第二条定律谈到了有效地完成任务,完美不是一个可实现的目标,因此不应该成为延迟完成任务的理由。相反,人们应该专注于按时完成任务,并定期改进。第三条定律谈到了线性系统和线性组织结构之间存在的同构性。最后,第四条定律讨论了人们可以利用 “分而治之 “的方法来减少大型企业内部沟通的复杂性和成本。

参考文献

原文

发表评论

邮箱地址不会被公开。 必填项已用*标注