我有一个整体应用程序，我正在考虑重写该应用程序以朝着微服务架构的方向发展，但是我仍在努力理解一些事情。
微服务是否需要拥有自己的Web API？我当时在想只有一个api网关，然后再引用类库。但是，注意到很多示例都具有Web api网关，然后还具有针对不同服务的Web api，我不理解为什么？
我的数据库有很多引用约束，因为很多表相互引用，不能分开。最好的做法是拥有一个公共的DB层并将依赖项注入到每个服务中吗？
答案 0 :(得分：5)
这是一个相当广泛的问题，无法解决。我将为您提供一些指导和链接，以获取更多详细信息。
微服务是否需要拥有自己的Web API？我在想 仅具有一个api网关，然后引用类库。 但是，注意到很多示例都有Web API网关，然后 有针对不同服务的Web API，我不明白为什么？
这称为API gateway pattern。请检查提供的链接，以了解其优势以及优势所在。这在微服务架构中非常普遍。
我的数据库有很多表的引用约束 彼此参照，不能分开。最好 实践是拥有一个通用的DB层并将其依赖项注入 每项服务？
取决于。如果您不能将数据管理层分为不同的垂直切片，则可以为所有服务共享同一数据库。
微服务架构中的数据管理可以有多种形式：
您可以选中shared database pattern。
更新
具有API网关的人如何设计自己的应用程序？ 他们是否有仅从api引用的类库 网关，这是否击败了“微服务”的概念？
API网关是面向公众的独立微服务，它处理来自客户端的所有请求/响应。这是一个薄层，负责客户端身份验证（针对客户端凭据提供身份验证令牌，证书验证等），并将调用（通过HTTP REST调用或某些RPC调用）委派给其他服务。它还可以通过快速失败在网关层上防止错误API调用的进一步传播。其他服务不是类库或此处的任何静态依赖项。它们是独立的独立微服务。
答案 1 :(得分：1)
微服务体系结构的主要好处是每个微服务都是松散耦合的。这种松散的耦合是可能的，因为每个微服务都可以维护自己的接口（通过Web API或其他接口）和状态（通过持久数据库或其他方式）。
我不确定我是否正确理解了您的示例，但这听起来像是您打算使用一个API接口来引用来自不同“微服务”的多个类库。在这种情况下，API接口和类库之间的耦合将阻止您在API接口或类库中进行独立更改。因此，您经常会看到具有各自独立的Web API的实现。
对于您的数据库设计，我建议使用Database per service模式。跨不同服务共享数据库被认为是一种反模式，因为它将在数据层耦合您的服务。