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