拆分还是整合：单体和微服务的技术抉择( 三 ) _微服务

你不必人为地将自己对准频谱的任意一端。你甚至不必将自己固定在其中任意的特定位置。尽管一些人想让你这样认为，但并不存在所谓的正确的立场。你选择的位置应该与你的团队、业务、项目或客户对齐。只有你可以决定应该处在频谱的哪个位置。
投资回报递减
随着你在频谱的右侧移动，你将获得微服务的好处，但向右移动也伴随着成本和困难的增加。我们需要确保转向微服务的成本是我们愿意承担的。
如果你不是为了管理复杂性，不需要微服务的其他好处，或者在管理单体的自动化和技术方面存在困难，那么你应该尽量留在频谱的左侧。随着你需要微服务的程度的增加，应该朝着频谱的右侧靠近。

文章插图
随着投资回报递减，一直迈向完美的微服务乌托邦可能是不值得的，但只走其中的一部分道路可能会带来高回报。
此时我们要清楚地认识到，我们不需要达到（我喜欢称之为）微服务乌托邦的程度才能开始享受无服务的好处。无论我们是否达到了频谱的另一侧，我们只要朝着频谱的右侧移动一定程度，都会得到切实的好处！
有很多原因使我们不想迈向完美的微服务。（首先，谁来决定完美的定义？）当我们开始向右侧推进时，将看到巨大的回报。但随着继续向前推进，投资回报开始递减。我们越是朝着更小的服务前进，成本就会超过好处。在杂乱复杂的现实世界中，实现完美的微服务是很困难的，更不用说这其实是不必要的。但这并不意味着朝着那个方向前进不会有所裨益。
混合模型
如果不需要一直推进到微服务一侧，那应该在哪里停下来呢？答案是在中间的某个位置，在这个位置有一些权衡可以提高我们的开发速度和能力，但成本不会超过好处。
我喜欢将在中间的某个位置看作是两全其美。是的，我们可以拥有单体（或多个单体），单体周围环绕着一些微服务。持有这种务实立场的我是否成了某种异教徒？这种架构的实际好处在于我们可以将单体的好处与微服务的好处混合起来。单体代码库的便利性和简单性，加上在必要时可以利用的微服务的灵活性、可伸缩性和其他好处，使得这种架构成为一个理想的选择。如果有必要，我还可以逐步从单体拆分出单独的微服务，让某些功能或任务可以从中受益。

文章插图
混合模型并不是什么新想法，这就是现实世界通常的样子（在中间的某个位置），尽管人们在网络上继续争论不休。
David Heinemeier Hansson（单体支持者）似乎很喜欢这个想法，他将其称为城堡架构。
大小真的重要吗？

"也许‘Micro’是一个具有误导性的前缀。它并不一定是‘小’的意思。大小实际上并不重要。"
—— Ben Morris (source)

服务越?。?驮?Micro，作用就越小，我们就需要越多的服务。随着我们减小服务的大小并增加服务的数量，困难程度也会提升。
或许，我们应该停止专注于微服务“Micro”的部分。我认为这会导致人们将自己的服务变得过于?。??庖欢ɑ岬贾略谑褂梦⒎?袷庇龅嚼??。
我甚至不确定我们是如何如此专注于使它们变得尽可能小的。我们的意图是将软件拆分成不同的部分，分离责任，让每个部分都比整体简单，从而更容易管理系统的复杂性。但如果服务过于小，我们可能会被复杂性淹没，无法管理好它们。
尽管每个人似乎都有自己关于微服务大小的看法，但现实是，微服务的大小没有固定标准。
所以，我们应该停止争论服务的大?。?我们应该谈论的是“合适大小”的服务，也就是适合实际情况的适当的大小——单体或者是频谱较小的一端。我们的服务，无论大小如何，都应该根据业务和领域来决定。微服务大小只是后话，整体的组织更为重要。
问题不在于使服务变得尽可能?。?服务小到超过某个程度就会适得其反。它们越小，就必须与系统的其余部分进行更多的交互才能完成任务。交互越多，我们就需要付出更高的网络传输成本，更不用说这会使得它们之间的交互变得更加难以理解。我们需要在服务大小和服务有多喋喋不休（Chatty）之间取得良好的平衡（感谢 Damian maclennan 提供了"喋喋不休"一词）。