从Monolith到微服务:理论与实践 - Kent Beck

20-10-07 banq

我们如何才能快速地从整体变为微服务?

无法回答这个问题。首先,“迅速”就在窗外。你一个月都没弄糟。您将不会在一个月内修复它。其次,您希望从微服务中获得一些您目前无法获得的好处。那有什么好处?微服务不是重点。

拒绝了这个问题之后,我将继续回答。在我无法解释为什么无法快速更改微服务之前,如果强制转换是危险的,这是作用在软件设计上的基本力量。在20世纪70年代中期,Yourdon&Constantine在结构化设计中阐明了这些, 并且没有改变。

他们的论据是这样的:

  1. 我们设计软件以降低其成本。
  2. 软件成本等于≈更改软件的成本。
  3. 更改软件的成本≈昂贵的更改(电源定律等)的成本。
  4. 通过级联的变化所产生的昂贵变化的成本-如果我改变这个话,我必须改变的是和那个,如果我改变的是那么...
  5. 设计元素之间的耦合就是更改传播的倾向。
  6. 因此,设计≈成本≈变化≈大变化≈耦合。可传递地软件设计≈管理耦合。

(这跳过了很多有趣的东西,但是我只是试图建立一个论点,说明为什么将整体式快速分解为微服务会适得其反。)

 

管理联轴器

请注意,我并不是说“消除耦合”。去耦带有其自身的成本,既包括去耦本身的成本,也包括未预期到的变更的未来成本。设计越能完美地适应一组更改,就越有可能被新颖的更改所蒙蔽。在耦合、去耦和成本三者之间必须权衡。

您可以通过以下两种方式之一来管理耦合:

  • 消除耦合。具有硬编码的read()和write()函数的客户端和服务器就协议更改而耦合。更改一个write(),您将不得不更改read()。但是,引入一种接口定义语言,您可以在一个地方添加到协议中,并使更改自动传播到read()和write()。
  • 缩小耦合范围。如果更改一个元素意味着要更改另外十个元素,那么将这些元素放在一起比将它们分散在整个系统中更好-更少的导航,更少的检查,更少的测试。更改元素的数量相同,但是每次更改的成本较小。(这也被称为“一堆肥”原则,或芳香性较低的“内聚力”。)

 

无法很快

有两个因素会阻止快速去耦:

  • 技能
  • 知识

我看到有关软件设计的有用民俗知识-例如,使模型与视图和控制器分离-但很少明确承认或管理耦合。戴上耦合眼镜后,您将看不到耦合,但是过渡需要一段时间。识别耦合,寻找Emmenthal变化(奶酪之间有很多孔的变化),增加内聚力,在一个方向上减小内聚力,然后在另一个方向上增加内聚力,进行设计。

一旦可以进行抽象设计,就可以将这些技能应用于您的系统。系统的内部边界应该在哪里?发现它们需要一段时间和一些实验。最好先轻描淡写边界,然后再更牢固地绘制边界,然后再切除零件。素描错误是可逆的。服务提取并非永远都是永久的,但是当您发现两个服务耦合时,进行逆向操作的代价很高。

 

好消息

您如何快速将整体分解为微服务?不能,因为您需要学习方法,也需要学习什么。好消息是,您不必快速将整体分解为微服务即可快速获得所需的某些好处。

更改集群。如果您整理步行的街道,并且大部分时间都走同一条街道,那么稍微整理一下就会使您的街道大部分都保持整洁。进行更改之前,请先增加内聚力。在进行更改之前,请消除耦合。变革很快就会加速。

banq评:高聚合低耦合,寻找凝聚力,逻辑一致性体现了一种凝聚力;1+2=3加法汇总就是一种逻辑一致性,还有其他数学形式的算法,当然还有小的业务规则和业务约束等。包括在你的if/else中的业务逻辑。

 

                   

1
猜你喜欢