具有微服务架构的后端堆栈

Question

目前我正在将 CRM 迁移到微服务架构。这个拱门是否适合称为坚固坚固呢？ （预计未来会出现高负载）

这个架构的要点是一个服务 - 一个数据库（如微服务中所暗示的），所以我决定它看起来像这样。我想在迁移之前减轻未来可能出现的所有问题。

这里是带有 graphql 和 subgraph 的 api 网关，适用于每个服务，例如：任务、订单、客户端等。Subgraph 将向微服务发送查询并收集响应所需的所有数据。

想向社区询问此架构是否存在一些错误或缺点，或者改进它的建议，所以如果有的话请指出我。

Answer 1

未来预计会有高负荷

我认为微服务本身并不完全是关于性能。可以说，在很多情况下，整体方法有利于从性能角度出发（特别是如果您认为进程内通信比 RPC 更快）。

例如：

• Stackoverflow 本身是使用单体架构构建的，据我所知 - 案例研究：Stackoverflow 的单体架构如何击败微服务性能。

• Amazon Prime 将微服务迁移到 Monolith - Prime 视频技术文章：

  从分布式微服务架构到整体应用程序的转变有助于实现更高的规模、弹性并降低成本。

微服务架构的主要好处（恕我直言）：

• 组织性：当您拥有大型团队和/或功能非常丰富的应用程序时，将应用程序拆分为可以单独部署的松散耦合的组件非常有益。
• 您对系统的不同部分有不同的性能和/或技术要求。

一些注意事项：

• 微服务架构对服务分解高度敏感，如果做得错误，你很容易就会得到分布式单体
• 根据我的经验，从性能角度来看，数据重复（即服务在本地维护由其他服务管理的数据的“只读”副本）在微服务架构中非常重要
• 最终一致性

查看更多：

• 微服务的模式语言
• 避免微服务大灾难 - Jimmy Bogard（强烈推荐）