为什么你总是选择微服务？（一体化架构有疑问）

有没有想过为什么像苹果，eBay和Netflix这样的公司非常关心微服务？是什么让这个简单的架构变得如此特别以至于它被过度炒作？将整个正在运行的应用程序从一体化转移到微服务架构是否值得付出的努力和痛苦？当我们开始在项目中使用微服务时出现了很多类似的问题。在本博客中，我们将尝试回答这些问题并深入研究微服务架构，并将其与一体化架构进行比较。

什么是微服务？它与一体化有何不同？

微服务是小型自主服务工作的集合。让我们再简化一下这个定义。

微服务 - 也被称为微服务体系结构 - 是一种架构风格，它将应用程序构建为一系列松散且互联的实现各自业务功能的服务。微服务架构支持大型复杂应用的持续交付/部署。

随着我们编写代码以便于添加新功能，代码库不断增加。随着时间的推移，因为代码库非常大，我们可能很难知道哪些地方需要修改。

在一体化系统中，我们努力确保代码属于一体化系统以便于与解决这些问题，我们通常采用创建抽象对象或模块的方法来确保我们的代码更内聚以便于应对这些问题。微服务采用独立服务的方法。我们将服务边界集中在业务边界上，明确了代码在什么地方具有什么功能。

为什么不采用一体化架构？

有个主要问题是，如果我们有一个功能完整的一体化应用程序正在运行，为什么要转换？为什么要增加开销并付出额外的努力？此外，转换是否值得付出的努力和得到的痛苦？

我们需要理解的第一件事是一体化应用程序并不是一无是处的。变化和进化是生活的一部分。虽然一体化应用程序的确解决了许多经典架构问题，例如如部署（因为它是作为一个单元部署）和测试很容易，但与优点相比，它有很多缺点。我们在使用一体化应用程序时遇到的主要问题包括：

• 可扩展性 - 扩展应用程序有可能很困难 - 一体化架构只能在一个维度上进行扩展。一方面，它可以通过运行更多的应用程序副本来扩大交易量。使用一体化架构，我们无法独立扩展每个组件，因此即使大多数组件可能不需要扩展，整个应用程序也需要进行扩展。
• 可靠性 - 一体化应用的另一个问题是可靠性。任何模块中的一个错误（例如内存泄漏）都可能导致整个过程失败。而且由于应用程序的所有实例都是相同的，因此该错误将影响整个应用程序的可用性。
• 可用性 - 即使一个服务失败，整个应用程序也必须关闭。由于所有服务都是作为一个单元部署的，因此每次服务失败或出现错误时，都会牵累整个应用程序。
• 敏捷性 - 在一体化应用程序中，即使应用程序中的小型组件需要更改，整个应用程序也需要重新打包并组装在一起。因为重建整个应用程序需要相当长的时间，我们可以很确定这降低了应用程序的敏捷性。
• 持续部署 -如果您持续部署，那么它在这方面会表现会很差，因为即使应用程序发生小的变化，构建时间也会大大增加，并且会明显减少部署频率。而且即使是微笑的更改，您也必须在每次更新时重新部署整个应用程序。
• 独立软件栈 -一体化应用程序很难适应不同的软件栈。由于框架或语言的变化会影响整个应用程序，因此付出的时间和成本很大。

除了这些问题之外，程序员在处理一体化应用程序时还面临着许多其他问题。因此考虑到这些问题，似乎需要一个不同的架构至少可以解决其中一些问题。这就是微服务。

微服务 - 救世主？

现在我们已经遇到了在使用一体化应用程序时可能会遇到的一些问题。那么微服务能解决这些问题吗？他们是否做的更好或者只是另一个被炒作的架构？

正如我们已经看到的，微服务的主要思想是将您的应用程序分解为一组较小的互连服务，而不是构建一个单一的一体化应用程序。每个微服务都是一个小型应用程序，它有自己由业务逻辑组成的体系结构。

现在我们对微服务有了一个大概的概念，让我们来看看微服务提供给我们哪些一体化结构没有的优点：

• 可扩展性：每个微服务可以独立扩展而不会影响其他微服务，因此它明显优于一体化应用程序，因为它们都被整合到同一个部署单元中，所以一体化应用程序大量的资源被浪费在扩展不需要的服务上。
• 可靠性：微服务的故障仅影响自身及其使用者，而在一体化模型中，一个服务故障可能会导致整个一体化服务失败。即使一个微服务失败，其他微服务也可用，并且可以很快修正错误的微服务。
• 可用性：推出新版本的微服务只需要很少的停机时间，而在一体化服务中推出新版本的服务需要整个服务重启并且速度较慢。一个失败的微服务可以在很短的停机时间内迅速被纠正。
• 敏捷性：特定微服务的变化可以非常迅速地完成，并且可以非常迅速地进行部署，这使其成为非常适合不断变化业务需求的体系结构，这里意味着非常敏捷的环境。
• 持续部署：微服务体系结构可以使每个微服务独立部署，因此它可以为复杂应用程序进行持续部署。此外，与一体化应用程序不同，微服务中的代码可以非常迅速地完成更改来跟踪业务需求的变化，从而缩短开发周期。
• 独立软件栈：对于微服务，每个服务都是独立的，每个服务都是一个新项目; 每项服务都可以用符合要求的任何语言进行开发。因此，不同的软件栈可以用于不同的微服务。

除此之外，微服务还为我们提供了更多优势：

• 管理：应用程序开发工作可以分为小型和独立的团队。
• 数据分散：没有集中的数据库。每个模块都有自己的数据库，所以数据是分散的。您可以使用NoSQL或关系数据库，这取决于模块。
• 更好的可理解性：分布式服务使新开发人员更容易理解服务的功能。此外，由于特定模块专用于特定服务，因此它有助于开发人员更好地了解该服务，而不是尝试弄清楚整个应用程序。

类似的例子不胜枚举...

但等等，没有人是完美的，对吧？微服务也不例外

仅仅因为这个行业很火并不意味着它没有缺点。相信与否，微服务并不完美。他们确实存在不同类型的缺点。我们来看看其中的一些：

• 运营复杂性：您需要一个成熟的运营团队来管理大量需要定期重新部署的服务。
• 测试：测试微服务应用程序也比一体化的Web应用程序更复杂。对于服务进行类似的测试，您需要启动该服务以及它所依赖的任何服务。
• 部署：在分布式系统的情况下，部署微服务变得更加复杂，因为有许多工作，脚本，传输区域和配置文件需要部署。
• 多个数据库和事务管理：微服务具有分布数据库体系结构。在微服务的应用程序中更新多个业务实体的事务需要更新不同服务拥有的多个数据库。
• 通信：在微服务中，每种服务都通过API /远程调用进行通信，这比一体化软件的进程间通信调用花费更多。
• 分布式系统的复杂性：作为一个分布式系统，微服务具有一定程度的复杂性以及需要处理的几个问题，如网络延迟，容错率，消息序列化，不可靠的网络，异步性，版本控制，应用程序层内的各种负载等等。

现在我们对一体化和微服务是什么以及他们的优缺点有一个大概的认识。

总而言之，一体化架构更适合简单轻量级的应用。微服务架构模式适用于复杂的，不断变化的应用程序，尽管在缺点和实施方面的具有一定的挑战。

在开始使用任何一种架构之前，需要明智地做出选择，并考虑您从一体化转换或迁移到微服务所付出的努力是否值得随之而来的痛苦和复杂性。

在下一篇博客中，我们希望讨论在转向微服务架构时一些好的实践经验。请持续关注。

希望这篇文章可以有所帮助。祝您编程愉快！