数据库管理

微服务和单体应用如何影响数据库

应用程序架构最常见的两种方法是单体应用架构（功能由一个大型应用程序提供）和微服务架构（功能被拆分为相互协调的小单元）。这些设计选择在开发体验、部署便利性和运营足迹方面都会产生深远的影响。

应用程序架构影响您的环境的最重要方式之一是它如何影响您使用数据库的方式。应用程序结构通常会影响数据结构，还会影响数据的存储位置和操作方式。在本指南中，我们将讨论单体应用和微服务之间的区别，特别是这些决策如何影响您的数据库。

在软件开发中，单体应用和微服务都描述了应用程序架构。

单体应用是传统的应用程序开发和部署方式。在单体设计中，执行有用工作所需的大部分处理、通信和协调都在单个应用程序内部发生。应用程序与外部世界交互，接收来自用户的输入和命令（很多时候通过 Web 服务器端点公开），并与数据库等其他服务交互。

单体应用之所以流行，是因为它们遵循成熟的开发模式，并拥有大量的工具集，可以帮助进行调试和故障排除。单体应用的整合性也使得在运营环境中部署和管理相对简单。尽管不同团队在同一个应用程序上工作时必须谨慎协调更改，但涉及的组件数量相对较少。

话虽如此，使用一个单一的、包罗万象的应用程序也可能有很多缺点。应用程序开发必须紧密协调，以确保与特定功能相关的所有代码保持一致。当整个应用程序必须扩展以满足不同需求时，扩展也可能极具挑战性，特别是在需要运行多个副本时，应用程序可能不具备协调所需的接口或逻辑。

微服务是一种替代的应用程序架构方法，它涉及将应用程序的功能拆分为许多离散的“服务”。这些服务各自拥有明确定义的职责，并通过网络相互协调以完成有用的工作。从某种意义上说，微服务是一种开发风格，它分解应用程序并将内部通信重新实现为网络通信。

人们选择微服务而非单体应用有诸多原因。微服务允许您根据单个服务的性能和负载特性独立扩展服务。除了可伸缩性本身的好处之外，在不同主机上运行小型组件的多个副本可以提高应用程序的弹性，有助于确保硬件故障不会导致停机。

这种灵活性使您能够解耦不仅是各个组件的扩展，还有开发本身。不同的服务可以使用完全不同的语言构建，只要它们提供其他组件可以通信的接口。这会对团队对组件的“所有权”体验产生深远影响，并带来快速迭代甚至完全重写服务而不影响其他领域的好处。

微服务也带来了自身的挑战。例如，部署和管理大量服务的操作复杂性可能令人难以承受，特别是如果您的团队没有强大的运维背景。服务间通信的重要性增加了网络层面临的需求复杂性和流量。同时，由于传统工具在分布式环境中通常不适用，调试和测试也变得更加困难。

上述架构选项对开发过程以及在生产环境中操作应用程序的体验产生了深远影响。其中一个特别受影响的组件是数据库。

单体应用通常部署有集中式数据库。应用程序可能会将读取操作传递给副本以更均匀地分配负载，但通常情况下，所有数据都集中在一个地方。在这种情况下，集中式数据库负责管理与许多不同应用程序上下文和功能相关联的信息。

然而，微服务通常与更复杂的数据环境相结合。单个微服务通常与自己的数据库实例一起部署，这些实例仅负责管理该特定服务的数据，别无他求。

这种模式之所以流行，是因为它允许开发人员独立迭代和部署每个微服务。开发中最大的协调点之一是修改数据库的代码，因为更改可能会影响应用程序的许多不同部分。如果一个团队更改了数据库模式，它可能会破坏旨在预期先前模式的功能。

为每个微服务配备自己的数据库可以解耦这种级联效应，这样开发人员可以在更少的协调下，更有信心地进行所需的更改。这进一步实现了将服务作为离散的、专注的组件进行管理的目标，这些组件仅通过明确定义的接口相互交互。

然而，每个微服务一个数据库的模式并非没有自身的挑战。随着微服务数量的增加，单个数据存储的数量也随之增加。操作要求也成倍增加，因为团队现在必须为每个新服务管理数据库部署、备份、故障转移和其他问题。如果没有完善的工具和专业知识，这会很快变得难以管理。

开发人员还必须弄清楚如何协调可能涉及多个微服务的查询和更新。例如，如果正在下订单，客户数据、库存数据和订单信息本身可能由不同的微服务管理。

微服务模式可以帮助您扩展应用程序，并使作为组织的某些开发和部署任务更易于协调。它可以帮助您更快地迭代和发布更改，同时限制新代码对应用程序其他部分的影响。

重要的是要了解您的架构选择将如何影响开发过程、基础设施和运营要求的不同部分。在微服务的情况下，数据库环境通常与单体部署大相径庭。重要的是要了解要预期的变化以及如何管理挑战以保持生产力。

Justin 自 2013 年以来一直撰写有关数据库、Linux、基础设施和开发者工具的文章。他目前和妻子以及两只兔子住在柏林。他通常不必使用第三人称写作，这对所有相关方来说都是一种解脱。