整体式->服务：粗略的方法

我不能回答这个问题。首先，“速战速决”就在窗外。你不会在一个月内弄得一团糟；你也不会在一个月内把它修好。其次，你想要一些你目前没有从微服务中获得的好处。那是什么好处？微服务不是重点。

在拒绝了这个问题之后，我将继续回答它。在我可以解释为什么快速改变到微服务是不可能的，如果是强迫的，也是危险的，在我解释之前，这里是作用于软件设计的基本力量。这些在70年代中期由Yourdon&；Constantine in Structure Design阐明，至今没有改变。

更改软件的成本是≈，即昂贵更改的成本(幂律等等)。

昂贵更改的成本是由级联更改产生的-如果我更改这个，那么我必须更改那个，如果我更改那个，则…。

因此，设计≈Cost≈Change≈大变化≈联轴器。过渡性的，管理耦合的软件设计≈。

(这跳过了很多有趣的东西，但我只是想提出一个论点，为什么快速将一块巨石分解成微服务会适得其反。)。

注我不是说“消除耦合”。脱钩有其自身的成本，既有脱钩本身的成本，也有意想不到的变化的未来成本。一个设计越完美地适应一组变化，它就越有可能被新奇的变化蒙蔽。因此我们得到了经典的权衡曲线：

消除耦合。具有硬编码的read()和write()函数的客户端和服务器关于协议改变而耦合。更改write()，您必须更改read()。不过，引入接口定义语言后，您可以在一个位置添加到协议中，并让更改自动传播到read()和write()。

缩小联轴器的范围。如果更改一个元素意味着更改其他十个元素，那么这些元素放在一起要比分散在整个系统中要好-导航、检查和测试都更少。要更改的元素数量相同，但每次更改的成本较小。(这也被称为“一堆肥料”原则，或不那么芳香的“凝聚力”。)。

我看到了关于软件设计的有用的民间传说--把你的模型与你的视图和控制器分开，比如&&控制器--但是很少明确地承认或管理耦合。一旦你戴上耦合眼镜，你就不会看不到耦合，但过渡需要一段时间。识别耦合，寻找本质上的变化(奶酪之间有很多洞的变化)，增加凝聚力，降低一个方向的凝聚力，然后在另一个方向上增加凝聚力，玩弄设计。

一旦您可以进行抽象设计，就可以将这些技能应用到您的系统中。您的系统的内部边界应该在哪里？这需要一段时间和一些实验才能发现它们。在裁剪零件之前，最好先轻轻地画出边界，然后再更牢固地画出来。草图错误是可逆的。服务提取并不完全是永久的，但是当您发现两个服务耦合时，反转的代价很高。

怎样才能将一个整体快速分解成微服务呢？你做不到，因为你需要学习如何和你需要学习什么。好消息是，你不必迅速将一块巨石分解成微服务，就能迅速获得你想要的一些好处。

更改群集。如果你整理你走过的街道，而且你们大多走在同一条街道上，那么稍微整理一下就会让你大部分时间走在整洁的街道上。在做出改变之前，稍微提高一下凝聚力。在进行更改之前，稍微消除一下耦合。很快，变化就会加速。