本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

使用数据库包装器服务模式控制访问

封装服务是充当数据库外观的服务层。当您需要在为将来的分解做准备的同时维护现有功能时，这种方法特别有用。这种模式遵循一个简单的原则——当某些东西太混乱时，首先要控制混乱局面。包装服务成为访问数据库的唯一授权方式，它提供了一个受控的接口，同时隐藏了底层的复杂性。

当由于架构复杂而无法立即进行数据库分解时，或者当多个服务需要持续的数据访问时，请使用此模式。它在过渡期间特别有价值，因为它为谨慎的重构提供了时间，同时保持了系统的稳定性。在将数据所有权整合到特定团队或新应用程序需要跨多个表的聚合视图时，这种模式效果很好。

例如，在以下情况下应用此模式：

数据库包装器服务模式的优点和局限性

以下是数据库封装模式的优点：

以下是数据库包装模式的局限性。

实现数据库包装器服务模式

实现数据库包装器服务模式分为两个阶段。首先，创建数据库包装器服务。然后，您可以通过它指挥所有访问权限并记录访问模式。

第 1 阶段：创建数据库包装器服务

创建一个充当数据库看门人的轻量级服务层。最初，它应该反映所有现有功能。此封装服务成为所有数据库操作的必备访问点，它将直接的数据库依赖关系转换为服务级别的依赖关系。在此层实施详细的日志记录和监控，以跟踪使用模式、性能指标和访问频率。保留现有的存储过程，但要确保只能通过这个新的服务接口访问它们。

第 2 阶段：实施访问控制

通过封装服务系统地重定向所有数据库访问权限，然后撤消直接访问数据库的外部系统的直接数据库权限。在迁移服务时记录每种访问模式和依赖关系。这种受控访问允许在不中断外部使用者的情况下对数据库组件进行内部重构。例如，从低风险的只读操作开始，而不是复杂的事务性工作流程。

第 3 阶段：监控数据库性能

使用包装器服务作为数据库性能的集中监控点。跟踪关键指标，包括查询响应时间、使用模式、错误率和资源利用率。为性能阈值和异常模式设置警报。例如，监控运行缓慢的查询、连接池利用率和事务吞吐量，以主动识别潜在问题。

使用此统一视图可通过查询调整、资源分配调整和使用模式分析来优化数据库性能。包装服务的集中化性质使得在保持一致的性能标准的同时，可以更轻松地实施改进并验证其对所有消费者的影响。

实现数据库包装器服务的最佳实践

以下最佳实践可以帮助您实现数据库包装器服务：

基于场景的示例

本节介绍了一个名为B AnyCompany ook s的虚构公司如何使用数据库包装模式来控制对其整体数据库系统的访问的示例。 AnyCompany Books提供三项关键服务：调度、财务和订单处理。这些服务共享对中央数据库的访问权限。每项服务都由不同的团队维护。随着时间的推移，他们会独立修改数据库架构以满足其特定需求。这导致了相互依存关系错综复杂的网络和日益复杂的数据库结构。

该公司的应用程序或企业架构师意识到需要分解这个单体数据库。他们的目标是为每项服务提供自己的专用数据库，以提高可维护性并减少跨团队的依赖性。但是，他们面临着重大挑战——在所有三个团队都继续为正在进行的项目积极修改数据库的同时，几乎不可能分解数据库。不断的架构变化和团队之间缺乏协调使得尝试任何重大重组都极具风险。

架构师使用数据库包装器服务模式开始控制对单体数据库的访问。首先，他们为一个名为 Order 服务的特定模块设置了数据库封装服务。然后，他们将订单处理服务重定向到访问包装服务，而不是直接访问数据库。下图显示了修改后的基础架构。