Web services DAO微服务是微服务体系结构中的好方法吗？

我正在创建一个web应用程序，并决定使用微服务方法。请您告诉我，组织从所有web服务（登录、评论等web服务）访问数据库的最佳方法是什么，或者至少是常见的方法是什么。创建DAOWeb服务并仅使用它读取/写入应用程序数据库中的值是否合适。或者每个web服务都应该有自己的dao层。

每个微服务都应该是一个具有所有必要层的成熟应用程序（这并不意味着微服务之间不能共享代码，但它们必须在单独的进程中运行）

---

此外，通常建议每个微服务都有自己的数据库。因此，我看不出web服务只充当数据访问门面的意义。

拥有数据库服务是完全有效的模式。事实上，这是一个关键的例子，说明了如何开始将巨石的各个方面导出到未来的微服务中

如何围绕这种想法组织代码是另一个问题。是的，从db客户机程序员的角度来看，在每个db客户机上使用相同的DAO层非常有意义

DAO模式可能适合将DB绑定到您使用的一种编程语言。但是，如果对数据库的所有访问都是由相同的DAO基础设施进行中介的，那么您需要问问自己，为什么要将数据库作为web服务公开。还是要为每个客户端编程语言绑定创建一个DAO模式

如果所有数据库客户机都将使用同一种编程语言编写，那么您确定您真的需要将数据库包装为一种微服务吗？毕竟，数据库通常已经是一个远程服务，它有一个定义良好的网络协议，经过优化，可以快速可靠地传输数据。为什么要在上面添加HTTP？您希望从增加这种复杂性中获得什么

使用DAO模式的另一个问题是DAO结构不一定遵循web服务的演变。web服务可能以一种不会使旧客户端不兼容的方式发展。您可能有使用micro服务不同功能的不同客户端。在这种情况下，每个客户机上都不共享相同的DAO层结构

---

确保您没有在web服务上使用RPC风格的编程，这没有多大意义。基本上，您将放弃微服务的一个关键优势，即服务和客户端之间的脱钩。

微服务很好，但立即开始使用太多的微服务并不好。如果您对如何在应用程序中定义微服务之间的边界有疑问，请从一个整体开始（始终保持代码干净，并使用设计良好的层和接口实现良好的面向对象）。当您达到应用程序更成熟的状态时，您将更容易看到拆分为独立部署服务的正确位置

---

关键是把真正应该耦合的东西放在一起。当我们试图将所有内容与所有内容分离时，我们最终会创建太多的接口层，这会降低我们的速度。

我认为这不是一个好方法。 DB操作在任何进程中都是至关重要的，因此它必须位于de microservice内部的DAO层。为什么你不知道该在里面实现什么。 使用服务时，您会失去控制，如果必须更改流程逻辑，则必须更改DAO服务（影响所有服务）。

---

我认为这不是个好主意

我认为使用服务公开数据库中的数据是理想的，因为它提供了灵活性。开发REST服务以将部分或全部数据作为服务公开，从而提供了通过AJAX或其他可以处理数据并生成新信息的服务直接向UI使用数据的灵活性。这些使用者不需要实现DAO，可以使用任何语言。虽然您的整个数据库的REST服务可能不是一项微服务，但可以将其分解为学生、教授和班级的只读服务，以便在学校网站上公开，并提供创建、更新和删除（CUD）的不同服务，这些服务仅适用于注册者的office桌面应用程序

---

例如，构建一个服务来公开数据的统计值将保护数据不受只需要统计值的用户/程序的检查，而无需让服务为该统计的组件实现整个DAO。像SQL Server或Oracle这样的全功能数据库提供了应用程序开发人员可以使用的许多功能，包括复杂查询（使用索引）、统计以及对数据的集合操作的应用

你能引用《Building Microservices》一书中提到的数据库服务是一种完全有效的模式吗？你混淆了RPC技术（Java RMI、CORBA），它确实在服务器和客户端之间引入了耦合，并引入了RPC风格的编程，这与你设计API的方式有关。您可以使用开放协议（HTTP）创建一个RESTWeb服务，该服务不在客户端上强制任何耦合，而是设计为强制RPC风格的编程（Richardson成熟度模型中的0级）。