时间戳

首页 > 解决方案 > 微服务应用程序的最佳实践

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

问题描述

我有一个单体应用程序，我正在考虑重写应用程序以转向微服务架构，但是有一些事情我很难理解。

微服务是否需要有自己的 web api？我在想只有一个 api 网关，然后引用类库。但是注意到很多示例都有一个 web api 网关，然后还有用于不同服务的 web api，我不明白为什么？

我的数据库有很多引用约束，因为很多表相互引用，不能分开。最好的做法是让一个通用的数据库层和依赖项将它们注入到每个服务中吗？

标签： microservices

解决方案

这是一个相当广泛的问题，超出了答案。我将为您提供一些进一步挖掘的方向和链接。

微服务是否需要有自己的 web api？我在想只有一个 api 网关，然后引用类库。但是注意到很多示例都有一个 web api 网关，然后还有用于不同服务的 web api，我不明白为什么？

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

我的数据库有很多引用约束，因为很多表相互引用，不能分开。最好的做法是让一个通用的数据库层和依赖项将它们注入到每个服务中吗？

依靠。如果不能将数据管理层拆分为不同的垂直切片，则可以为所有服务共享同一个数据库。

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

  • 每个服务的数据库
  • 共享数据库
  • 佐贺（编舞和配器）
  • API 组成
  • CQRS
  • 事件溯源
  • 应用事件

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

更新

拥有 API 网关，人们倾向于如何设计他们的应用程序？他们是否有他们只是从 api 网关引用的类库，这不是违背“微服务”的想法吗？

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

推荐阅读