如果一个实用程序微服务不能在没有实用程序微服务的情况下运行，那么应该/可以将一个实用程序微服务与所有受抚养人合并吗？

Question

如果您正在分析任何给定的微服务体系结构，并且您将服务A和服务B合并在一起，以避免由于B崩溃而导致A无法工作（因为它严重依赖于B，并且根据项目规范，如果B有故障，A就无法完成请求），如果进行了足够的迭代，您不是最终会得到一个整体体系结构吗？

这是我们公司最近提出的一个问题，恐怕他们正在做一个短视的决定。

体系结构摘要:
-这是我们第一个使用微服务体系结构的系统
-我们有一个n数量的微服务（具体地说，每个微服务都是在集群中的kubernetes pod中运行的JAR)
-每个JAR公开单个服务（例如。auth、users、images...)通过HTTP API
-99%的服务需要用户授权，但不需要身份验证（这是在另一层完成的，我们的服务假定如果请求到达它，请求头包含有效的用户令牌
-为了将用户令牌转换为有形的东西（例如用户信息），我们向users
服务发出请求-目前，每个服务都这样做是为了验证用户是否满足某些特定于服务的条件。

现在，在一次会议上，几位高级开发人员提出了他们的担忧，即如果用户由于某种原因（不一定是与软件相关的原因，我们假设为这些服务分配的机器有故障）而失败，一切都将停止工作，这使得（在他们看来）这是一个带有额外步骤的准整体架构。为了避免这种情况，他们建议将users服务转换为静态库，并将其作为依赖项添加到所有需要它的服务中，因此每个服务本身都包含此功能，而不是依赖于远程API。

但这不是更多的规范问题而不是架构问题吗？这并不像ImagesAPI（从技术上讲）没有Users就不能工作，只是根据当前的项目规范，它没有指定在这种情况下它应该做什么，因此它只是失败，就像服务本身有缺陷一样。

我个人之所以认为这是一个短视的决定，是因为人们可以争辩说微服务之间的任何通信都可以被视为这种风险。这种情况只是一个非常明显的潜在失败点，也是“什么能打破”分析的第一次迭代。如果有足够的考虑，那么如果没有指定“计划B”（例如，如果无法从image服务获取图像，请使用预定义的占位符图像），那么许多服务使用的任何endpoint都可以以相同的方式处理

Answer 1

我对你的话题有两点评论：

>

re:规范。当一件特定的事情失败时，您定义了一种“替代”行为。

示例：images服务向users服务请求作者信息，以显示有关谁上载了图像的信息。

如果您开始将其用作库，那么您将陷入这样的境地：一旦更改了“用户服务”库，您就必须在所有服务中对其进行升级，否则模式或业务逻辑的差异将随着时间的推移而显现出来。在最坏的情况下，为升级创建顺序依赖项······

我认为您只需要接受您的用户服务是体系结构的关键部分，并真正努力使其高度可用，即确保它至少部署在几个不同的主机上（如果您支持它，甚至可以部署在地区上）