我们如何才能快速地从整体变为微服务？
无法回答这个问题。首先，“迅速”就在窗外。你一个月都没弄糟。您将不会在一个月内修复它。其次，您希望从微服务中获得一些您目前无法获得的好处。那有什么好处？微服务不是重点。
拒绝了这个问题之后，我将继续回答。在我无法解释为什么无法快速更改微服务之前，如果强制转换是危险的，这是作用在软件设计上的基本力量。在20世纪70年代中期，Yourdon＆Constantine在结构化设计中阐明了这些， 并且没有改变。
他们的论据是这样的：
- 我们设计软件以降低其成本。
- 软件成本等于≈更改软件的成本。
- 更改软件的成本≈昂贵的更改（电源定律等）的成本。
- 通过级联的变化所产生的昂贵变化的成本-如果我改变这个话，我必须改变的是和那个，如果我改变的是那么...
- 设计元素之间的耦合就是更改传播的倾向。
- 因此，设计≈成本≈变化≈大变化≈耦合。可传递地软件设计≈管理耦合。
（这跳过了很多有趣的东西，但是我只是试图建立一个论点，说明为什么将整体式快速分解为微服务会适得其反。）
管理联轴器
请注意，我并不是说“消除耦合”。去耦带有其自身的成本，既包括去耦本身的成本，也包括未预期到的变更的未来成本。设计越能完美地适应一组更改，就越有可能被新颖的更改所蒙蔽。在耦合、去耦和成本三者之间必须权衡。
您可以通过以下两种方式之一来管理耦合：
- 消除耦合。具有硬编码的read（）和write（）函数的客户端和服务器就协议更改而耦合。更改一个write（），您将不得不更改read（）。但是，引入一种接口定义语言，您可以在一个地方添加到协议中，并使更改自动传播到read（）和write（）。
- 缩小耦合范围。如果更改一个元素意味着要更改另外十个元素，那么将这些元素放在一起比将它们分散在整个系统中更好-更少的导航，更少的检查，更少的测试。更改元素的数量相同，但是每次更改的成本较小。（这也被称为“一堆肥”原则，或芳香性较低的“内聚力”。）
无法很快
有两个因素会阻止快速去耦：
- 技能
- 知识
我看到有关软件设计的有用民俗知识-例如，使模型与视图和控制器分离-但很少明确承认或管理耦合。戴上耦合眼镜后，您将看不到耦合，但是过渡需要一段时间。识别耦合，寻找Emmenthal变化（奶酪之间有很多孔的变化），增加内聚力，在一个方向上减小内聚力，然后在另一个方向上增加内聚力，进行设计。
一旦可以进行抽象设计，就可以将这些技能应用于您的系统。系统的内部边界应该在哪里？发现它们需要一段时间和一些实验。最好先轻描淡写边界，然后再更牢固地绘制边界，然后再切除零件。素描错误是可逆的。服务提取并非永远都是永久的，但是当您发现两个服务耦合时，进行逆向操作的代价很高。
好消息
您如何快速将整体分解为微服务？不能，因为您需要学习方法，也需要学习什么。好消息是，您不必快速将整体分解为微服务即可快速获得所需的某些好处。
更改集群。如果您整理步行的街道，并且大部分时间都走同一条街道，那么稍微整理一下就会使您的街道大部分都保持整洁。进行更改之前，请先增加内聚力。在进行更改之前，请消除耦合。变革很快就会加速。
banq评：高聚合低耦合，寻找凝聚力，逻辑一致性体现了一种凝聚力；1+2=3加法汇总就是一种逻辑一致性，还有其他数学形式的算法，当然还有小的业务规则和业务约束等。包括在你的if/else中的业务逻辑。