架构之:微服务和单体服务之争

简介

微服务和单体服务的各自好处之前的文章中已经讲的很明白了。本篇文章不是探讨到底应该用哪种服务架构。而是假设项目最终会采用微服务架构，那么就会有两种情况，第一种情况下项目一开始的时候，是先使用单体服务然后在项目发展过程中逐渐转换成微服务，另外一种就是一开始就采用微服务的架构。

本文将会讨论一下采用这两种方式的原因。

先单体再微服务

微服务是一种有用的架构，但即使是他们的拥护者也表示，使用微服务只对更复杂的系统有用。

因为使用微服务本身是有一个管理上的服务成本，这个成本会减慢团队的开发速度。所以对于更简单的应用程序来说，使用单体服务更加简单。所以该方式的支持者认为应该在最初将新应用程序构建为单体应用，即使最后很有可能转换为微服务。

第一个原因是在系统的初期，我们并不知道它到底会有多少用户，并且在软件的第一个阶段，我们通常考虑的是软件开发的速度，所以大家可能更加倾向于使用单体应用。如果使用了微服务，如果该微服务的设计比较糟糕，那么会导致后续系统无法扩展，只能重新设计。

第二个原因是，只有在服务之间提出良好、稳定的边界时，它们才能很好地工作，服务之间的任何功能重构都比单体应用困难得多。但即使是在熟悉领域工作的经验丰富的架构师，在一开始就很难确定边界。通过首先构建一个单体服务，您可以弄清楚正确的边界是什么，从而在边界之上再进行微服务的转换。

一种将单体服务转换为微服务的做法是，将单体服务经过合理的设计，比如注意软件内部的模块化，包括 API 边界和数据存储方式。如果能够做好这一点，那么后续转向微服务是一件相对简单的事情。

另一种方法是从单体应用开始，逐渐剥离边缘的微服务。这种方法可以在微服务架构的核心留下一个庞大的单体，但大多数新的开发使用微服务，而单体应用不再进行扩展。

还有一种是完全替代单体应用。这样可以完全抛弃单体带来的架构负担，重新开始。代价就是需要多花人力和时间。

所以，如果你不能构建一个结构良好的单体应用，那么是什么让你认为你可以构建一组结构良好的微服务？

直接从微服务开始

当然，也有人持有不同的意见，因为他们认为：

如果你确实能够构建结构良好的单体应用，那么您可能一开始就不需要微服务。

也就是说，不管是单体服务还是微服务，在构建之前都需要进行详细的需求分析，经过了透彻的分析，那么是否需要使用微服务一键很了解了，各个服务的边界也被界定出来了，那么为什么不直接使用微服务呢？

微服务的主要好处就是在不同的服务之间建立了一个边界。这样我们很难弄错一些事情，比如连接不应该连接的部分，并耦合那些不应该被耦合的部分。

在理论上，如果你的程序遵循了特定的规则，并在整体应用程序中建立明确的界限，那么您不需要微服务，但是在实际的工作中，这个界限总是会被跨域。

你可能会假设有许多可以被很好地分离的微服务隐藏在你的单个项目中，等待被提取。但实际上，很难进行这样的划分。

如果你从一个整体开始，各个部分将变得非常紧密地相互耦合。这就是单体应用的定义。这些部件将依赖于它们都使用的平台的特性。它们将基于共享的抽象进行通信，因为它们都使用相同的库。他们将使用仅当它们托管在同一进程中时才可用的方式进行通信。更糟糕的是，这些部分将（几乎）自由地共享域对象，依赖相同的共享持久性模型，假设数据库事务随时可用，因此无需补偿……从而使得再次分割事务变得非常困难。所以将现有的单体拆分成单独的部分非常困难。

所以当你开始时，就应该考虑你构建的子系统，并尽可能独立地构建它们。当然，只有在您认为您的系统大到足以保证这一点时才应该这样做。如果只有您和您的一位同事在几周内构建了一些东西，那么您完全不需要使用微服务。

总结

软件架构的世界总是很有趣，我们在探索的过程中也会学到很多不一样的视角。

本文已收录于 http://www.flydean.com/10-microservices-monolith/

最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！