我正在创建一个 Web 应用程序并决定使用微服务方法。请您告诉我，从所有 Web 服务（登录、cmets 等 Web 服务）组织对数据库的访问的最佳方法或至少常见的方法是什么。是否可以创建 DAO Web 服务并仅使用它来读取/写入应用程序数据库中的值。或者每个 Web 服务都应该有自己的 dao 层。
【问题讨论】：
标签： web-services rest database-design architecture microservices
每个微服务都应该是具有所有必要层的成熟应用程序（这并不意味着微服务之间不能共享代码，但它们必须在单独的进程中运行）。
此外，通常建议每个微服务都有自己的数据库。请参阅 http://microservices.io/patterns/data/database-per-service.html https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/ 因此，我真的不明白仅充当数据访问门面的 Web 服务的意义。
【讨论】：
拥有数据库服务是一种完全有效的模式。事实上，这是在Building Microservices book 中开始将单体应用程序的各个方面导出到微服务的关键示例之一。
如何围绕这样的想法组织代码是一个不同的问题。是的，从数据库客户端程序员的角度来看，在每个数据库客户端上拥有相同的 DAO 层非常有意义。
DAO 模式可能适合将您的数据库绑定到您使用的一种编程语言。但是，如果对数据库的所有访问都将由相同的 DAO 基础架构进行调解，那么您需要问自己为什么要将数据库公开为 Web 服务。还是要为每个客户端编程语言绑定创建一个 DAO 模式？
如果所有数据库客户端都将使用相同的编程语言编写，那么您确定真的需要将数据库包装为微服务吗？毕竟，数据库通常已经是一个远程服务，具有定义良好的网络协议，经过优化，可以快速可靠地传输数据。为什么要在上面添加 HTTP？您希望从增加这种复杂性中获得什么？
使用 DAO 模式的另一个问题是 DAO 结构不一定遵循 Web 服务的演变。 Web 服务可能会以一种不会使旧客户端不兼容的方式发展。您可能有不同的客户端使用微服务的不同功能。在这种情况下，您不会在每个客户端上共享相同的 DAO 层结构。
确保您没有在 Web 服务上使用 RPC 样式的编程，这没有多大意义。您基本上会抛弃微服务的关键优势之一，即服务和客户端之间的解耦。
【讨论】：
微服务很棒，但立即开始使用太多微服务并不好。如果您对如何在应用程序中定义微服务之间的边界存有疑问，请从整体式开始（始终保持代码干净，并通过精心设计的层和接口保持良好的面向对象）。当您的应用程序达到更成熟的状态时，您将更容易看到拆分为可独立部署的服务的正确位置。
关键是将真正应该耦合的事物保持在一起。当我们试图将一切与一切分离时，我们最终会创建太多的接口层，这会减慢我们的速度。
【讨论】：
我认为这不是一个好方法。 DB操作在任何流程中都是至关重要的，所以它必须在de微服务里面的DAO层。为什么你没有在里面实现什么。 使用服务，您会失去控制，如果您必须更改流程逻辑，则必须更改 DAO 服务（影响所有服务）。 在我看来，这不是一个好主意。
【讨论】：
我认为使用服务来公开数据库中的数据是理想的，因为它提供了灵活性。开发 REST 服务以将您的部分或全部数据公开为服务提供了灵活性，可以通过 AJAX 或其他可以处理数据并生成新信息的服务将数据直接使用到 UI。这些消费者不需要实现 DAO，可以使用任何语言。虽然整个数据库的 REST 服务可能不是微服务，但可以将其分解为只读学生、教授和班级以在学校网站上公开，并为创建提供不同的服务, 更新和删除 (CUD) 仅适用于 Registrars 办公室桌面应用程序。
例如，构建服务以公开数据的统计值将保护数据不被用户/程序检查，该用户/程序只需要统计值，而无需让服务为该统计的组件实现整个 DAO。 SQL Server 或 Oracle 等全功能数据库提供了许多应用程序开发人员可以使用的功能，包括复杂查询（使用索引）、统计数据集操作的应用程序。
【讨论】：