microservices - 启动其他微服务的微服务

Question

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

我有一个执行线程和消息管理的路由线程。

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

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

customer microservice instance每次有新客户出现时，您将如何启动新产品？你可以有某种manager microservice，但考虑到这个想法是customer microservice instance在“云”中分发 s（即我们不应该关心它们在哪里？）这似乎不太符合我所读到的内容微服务及其工作方式。还是我误解了什么？分发此系统的最佳方法是什么？

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

标签： microservices

Answer 1

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

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

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

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

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

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

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