微服务应用程序的最佳实践

KTO*_*TOV 2 microservices

我有一个整体应用程序,并且我正在考虑重写该应用程序以朝着微服务体系结构迈进,但是我仍在努力理解一些事情。

微服务是否需要拥有自己的Web API?我当时在想只有一个api网关,然后再引用类库。但是,注意到很多示例都具有Web api网关,然后还具有针对不同服务的Web api,我不理解为什么?

我的数据库有很多引用约束,因为很多表相互引用,不能分开。最佳实践是拥有一个公共数据库层并将其依赖项注入到每个服务中吗?

Kai*_*dul 6

这是一个非常广泛的问题,无法解决。我将为您提供一些指导和链接,以获取更多详细信息。

微服务是否需要拥有自己的Web API?我当时在想只有一个api网关,然后再引用类库。但是,注意到很多示例都具有Web api网关,然后还具有针对不同服务的Web api,我不理解为什么?

这称为API网关模式。请检查提供的链接,以了解其优势以及优势所在。这在微服务架构中非常常见。

我的数据库有很多引用约束,因为很多表相互引用,不能分开。最佳实践是拥有一个公共数据库层并将其依赖项注入到每个服务中吗?

要看。如果无法将数据管理层分为不同的垂直切片,则可以为所有服务共享同一数据库。

微服务架构中的数据管理可以有多种形式:

  • 每个服务的数据库
  • 共享数据库
  • 佐贺(编舞与编排)
  • API组成
  • CQRS
  • 活动采购
  • 应用事件

您可以检查共享数据库模式

更新资料

有了API网关,人们如何设计自己的应用程序?他们是否具有仅从api网关引用的类库,这是否击败了“微服务”的思想?

API网关是一个面向公众的独立微服务,可以处理来自客户端的所有请求/响应。这是一个薄层,负责客户端身份验证(针对客户端凭据提供身份验证令牌,证书验证等并终止TLS / SSL),并将调用(通过HTTP REST调用或某些RPC调用)委派给其他服务。通过在网关层上快速失败,它还可以防止错误API调用的进一步污染。其他服务不是类库或此处的任何静态依赖项。它们是单独的独立微服务。