简介
应用程序架构最常见的两种方法是单体应用程序（其中功能由单个大型应用程序提供）和微服务架构（其中功能被拆分为相互协调的小单元）。这些设计选择会对开发体验、部署的难易程度和运营占用空间产生深远的影响。
应用程序架构影响您的环境的最重要方式之一是它如何影响您与数据库的交互方式。应用程序结构通常会影响数据结构，还会影响数据的存储位置以及如何对其进行操作。在本指南中，我们将讨论单体架构和微服务之间的差异，尤其是这些决策如何影响您的数据库。
查看 Prisma 数据平台，以在一个地方管理所有应用程序数据。
什么是单体架构和微服务？
在软件开发中，单体架构和微服务都描述了应用程序架构。
单体应用程序
单体应用程序 是传统的应用程序开发和部署风格。在单体设计中，执行有用工作所需的大部分处理、通信和协调都在单个应用程序内部进行。该应用程序与外部世界交互以接收来自用户的输入和命令（通常通过 Web 服务器端点公开）以及与数据库等其他服务交互。
单体架构之所以流行，是因为它们遵循人们熟知的开发模式，并且拥有大量可以帮助调试和排查问题的工具。单体应用程序的整合性质也使得在运营环境中相对容易部署和管理。虽然必须谨慎协调更改以确保与某些功能相关的所有代码保持同步，但活动部件的数量相对较少。
话虽如此，使用单个包罗万象的应用程序也可能存在许多缺点。应用程序开发必须紧密协调，以确保与某些功能相关的所有代码都与彼此保持同步。当必须扩展整个应用程序以满足不同的需求时，扩展也可能极具挑战性，尤其是当应用程序可能不具备扩展多个副本所需的接口或逻辑进行协调时。
微服务
微服务 是一种构建应用程序的替代方法，它涉及将应用程序的功能拆分为许多独立的“服务”。这些服务各自具有明确定义的职责，并通过网络相互协调以完成有用的工作。从某种意义上说，微服务是一种将应用程序分解并重新实现内部通信为网络通信的开发风格。
人们选择微服务而不是单体应用程序有很多原因。微服务允许您根据各个性能和负载特征独立地扩展服务。除了可扩展性本身的优势之外，在不同主机上运行多个小型组件副本还能提高应用程序的弹性，以帮助确保硬件故障不会导致停机。
这种灵活性不仅可以让您分离各个组件的扩展，还可以分离开发本身。不同的服务可以使用完全不同的语言构建，只要它们提供其他组件可以与其通信的接口即可。这会对团队对组件的“所有权”体验产生深远的影响，并带来快速迭代甚至无需影响其他领域即可完全重写服务的优势。
微服务也带来了自己的挑战。例如，部署和管理大量服务的运营复杂性可能非常大，尤其是当您的团队没有强大的运营背景时。服务间通信的重要性增加了网络层所承受的需求复杂性和流量。同时，调试和测试变得更加困难，因为传统的工具通常不适用于分布式环境。
微服务如何影响数据库架构？
上面讨论的架构选项对开发过程和生产环境中的应用程序操作有重大影响。数据库可能是受影响最大的组件之一。
单体应用程序通常部署在集中式数据库上。应用程序可能会将读取操作传递给副本以更均匀地分配负载，但总的来说，所有数据都位于同一个位置。在这种情况下，集中式数据库负责管理与许多不同应用程序上下文和功能相关的信息。
然而，微服务通常与更复杂的数据环境相结合。单个微服务经常与自己的数据库实例一起部署，这些实例负责管理该特定服务的数据库，仅此而已。
使用特定服务数据库的利弊
这种模式很受欢迎，因为它允许开发人员独立地迭代和部署每个微服务。开发中最大的协调点之一是修改数据库的代码，因为更改会影响应用程序的许多不同部分。如果一个团队更改了数据库模式，可能会破坏为预期旧模式编写的功能。
为每个微服务提供自己的数据库可以消除这种级联效应，从而使开发人员能够在更少的协调和更高的置信度下进行必要的更改。它进一步实现了将服务管理为离散的、专注的组件的目标，这些组件仅通过定义明确的接口相互交互。
然而，每个微服务一个数据库模式并非没有其挑战。随着微服务数量的增加，单个数据存储的数量也随之增加。运营需求成倍增加，因为团队现在必须管理每个新服务的数据库部署、备份、故障转移和其他问题。如果没有完善的工具和专业知识，这很快就会变得难以管理。
开发人员还必须弄清楚如何协调可能涉及多个微服务的查询和更新。例如，如果正在下订单，则客户数据、库存数据和订单信息本身可能由不同的微服务管理。
结论
微服务模式可以帮助您扩展应用程序，并可以使某些开发和部署任务更易于在组织内协调。它可以帮助您更快地迭代和发布更改，同时限制新代码对应用程序其他部分的影响。
了解您选择的架构将如何影响您的开发过程、基础设施和运营需求的不同部分非常重要。在微服务的情况下，数据库环境通常看起来与单体部署有很大不同。了解预期会发生哪些变化以及如何管理挑战以保持生产力非常重要。
查看 Prisma 数据平台，以在一个地方管理所有应用程序数据。
