启动其他微服务的微服务

Question

我目前有一个单体应用程序，它为每个客户运行一个线程。每次有新客户注册时，您都会启动一个新线程；每次他们发送信息（下订单、更改详细信息等）时，消息都会被路由到正确的线程；并且每次他们注销线程时都会自行关闭。

我有一个路由线程来管理线程和消息。

由于我对微服务的了解有限，这似乎是转换为微服务架构的主要候选者 - 我有一组独立的进程（客户线程）正在运行。

当我开始研究它时，我正在考虑创建一项相当于“客户线程”的服务 - customer microservice instance。

每次有新客户出现时，您会如何创建一个新的customer microservice instance？你可以有某种manager microservice，但考虑到这个想法是在“云端”分发customer microservice instances（即我们不应该关心它们在哪里？）这似乎不太适合我读过的关于微服务以及它们如何工作的内容。还是我误解了什么？分发此系统的最佳方法是什么？

我考虑过的一种方法是让manager microservice 联系“流程启动器”服务循环。 process starter 服务将在每个物理服务器（或每个容器中）上运行一个实例，然后启动本地 customer microservice instances - 但从我读到的内容来看，你不应该真的与多个微服务共享一个容器吗？

Answer 1

这对于 Stack Overflow 来说可能过于基于意见 - 但我会试一试。

我所知道的微服务架构最常见的定义是“一组在有限上下文中运行的小型、专注的服务，它们被组合成向业务流程提供端到端的功能。”您的“每个客户的线程”方法几乎与此相反 - 线程似乎知道有关客户的一切，他们做什么以及他们是如何做的。线程就是整体。

在微服务架构中，您将为业务领域中的特定上下文提供服务，例如CustomerProfile、Orders、Invoices、CustomerService 等。

在这个模型中，您仍然可以有一个“每个客户的线程”，但不是将如何下订单的知识烘焙到线程本身，而是线程调用微服务（可能通过 HTTP）。该线程负责状态管理和编排微服务以实现端到端的业务功能。

每个微服务都尽可能独立；每个微服务都有自己的容器和部署架构是很常见的。

同样，主要是基于意见的 - 如果您决定继续使用“每个客户的线程”，我不想为每个客户提供新服务 - 这将是非常浪费的。我想你的大部分线程在他们生命的绝大多数时间里都在沉睡。给他们自己的服务实例（和运行的容器）没有多大意义。

但是，“如何启动服务实例”的答案通常由负载平衡处理（负载平衡器知道哪些实例可用，并根据您选择的任何可用性启发式路由请求）。您可以在大多数云提供商上自动扩展，也可以使用 Kubernetes 等工具来管理容器和服务器的配置。