【发布时间】：2021-05-12 11:55:12
【问题描述】：
微服务架构的好处之一是可以扩展应用程序的大量使用部分，而无需扩展其他部分。据说这会带来成本方面的好处。
但是，我的问题是，如果一个被大量使用的微服务依赖于其他微服务来完成它的工作，那么您是否也必须扩展其他服务，这似乎违背了目的。如果一个微服务在实时调用其他微服务来完成它的工作，是否意味着微服务边界没有正确建立。
【问题讨论】：
标签： microservices
【发布时间】：2021-05-12 11:55:12
【问题描述】：
没有经验法则。
扩展通常取决于某些指标，当达到某些阈值时，就会创建新实例。不再需要它们的情况也是如此。
一些服务正在执行简单、快速的任务，例如接受输入并将其写入数据库，而其他服务可能是运行时间较长的任务，可能需要任何时间。
如果需要扩展的服务正在调用可以以可靠方式轻松处理繁重负载的服务，则无需扩展该服务。
扩展背后的想法是在需要时扩大规模以支持负载，然后在负载达到常规指标范围时缩小规模以降低成本。
【讨论】：
-
但是您会同意，当您有相互依赖关系时，您还必须扩展系统/应用程序的其他部分。
-
我将根据负载而不是发射器系统对其进行缩放。在像 Kubernetes 这样的编排系统中，您无需查看发射器即可确定调用者的数量。 Kubernetes 只是查看 pod 的 CPU/RAM 并说“它比 X 高吗？”如果是，则扩大规模。 kubernetes.io/docs/tasks/run-application/…所以你的问题的答案是：如果呼叫者系统扩大，那么接收者只会在必要时扩大
-
但是如果微服务需要 15 个微服务来完成它的工作，那么它甚至应该是这样的微服务吗？我认为将它们组合成一个资产可能是更好的选择。你同意吗？
-
有很多事情需要考虑。当您迁移到微服务时，您会失去单体架构的许多优势。就像一位智者所说，微服务只会“为您购买选项”（您必须自己评估和实施的潜在解决方案）。他们没有解决你的问题。我要做的就是从单一服务开始，只有在我发现问题之后，我才会考虑拆分它。
这里有两个话题要讨论。 首先，通常情况下，同步通信两个微服务不是一个好习惯，因为你及时耦合它们，我的意思是，一个服务必须等待另一个服务完成它的任务。所以通常使用一些消息队列来解耦生产者和消费者是一种更好的方法，这样一个服务的负载不会影响另一个服务。
但是，在某些情况下，两个服务之间必须进行同步通信，但这并不意味着两者必须以相同的方式扩展，例如：如果一个服务必须多次调用另一个服务服务、对数据库的查询或其他类型的繁重计算任务，并且其中一个服务只进行数组排序，可能第一个服务必须比第二个服务扩展更多才能处理相同数量的请求，因为线程在第一个服务中将比第二个服务占用更长的时间
【讨论】：