我目前有一个Monolith应用程序，每个应用程序都有一个运行的线程。每次有新客户注册时，您都会启动一个新线程。他们每次发送信息（下订单，更改详细信息等）时，消息都会路由到正确的线程；并且每次注销时，线程都会自行关闭。
我有一个路由线程来执行线程和消息管理。
在我对微服务的了解有限的情况下，这似乎是转换为微服务架构的主要候选人-我有一组正在运行的独立进程（客户线程）。
当我开始研究它时，我正在考虑创建一种相当于“客户线程”-customer microservice instance的服务。
每次有新客户出现时，您将如何发展新的customer microservice instance？您可能有某种manager microservice，但考虑到其想法是将“ customer microservice instance”分布在“云中”（即，我们不应该在意它们在哪里？）似乎与我所读过的有关微服务及其工作方式的内容相吻合。还是我误会了什么？分发此系统的最佳方法是什么？
我考虑过的一种方法是让manager microservice与“流程启动器”服务联系。 process starter服务将在每个物理服务器（或每个容器）中运行一个实例，然后该实例启动本地customer microservice instance-但是，根据我的阅读，您实际上不应与多个容器共享一个容器微服务？
答案 0 :(得分：2)
对于Stack Overflow来说，这可能太基于观点了-但我会尝试一下。
我知道的最常见的微服务架构定义是“一组在有限的上下文中运行的小型，集中的服务，这些服务旨在为业务流程提供端到端功能。”您的“每位客户线程”方法几乎与此完全相反-线程似乎了解有关客户的所有信息，他们做什么以及如何做。线程是整体。
在微服务架构中，您将为业务域中的特定上下文提供服务，例如CustomerProfile，Orders，Invoices，CustomerService等。
在此模型中，您仍然可以有一个“每个客户线程”，但是该线程不会调用关于如何在线程本身中下订单的知识，而是调用微服务（可能通过HTTP）。该线程负责状态管理和协调微服务以实现端到端业务功能。
每个微服务将尽可能独立。每个微服务通常都有自己的容器和部署架构。
同样，主要是基于意见的-如果您决定保留“每位客户的线程数”，那么我不想为每位客户提供新服务-这将非常浪费。我想象您的大部分线程在他们的一生中都处于睡眠状态；给他们自己的服务实例（和要运行的容器）没有多大意义。
但是，“如何启动服务实例”的答案通常由负载平衡处理（负载平衡器知道哪些实例可用，并根据您选择的任何可用性启发式路由请求）。您可以在大多数云提供商上自动扩展，也可以使用Kubernetes之类的工具来管理容器和服务器的配置。