：微服务体系结构的可行性？

Question

我知道这个问题已经问过了，但我找不到令人满意的答案。我开始更深入地构建一个真正的restful，我喜欢它与使用链接进行解耦的对比。因此，我构建了我的第一个服务(使用java / spring )，它运行得很好(尽管我在找到正确的格式方面有些困难，但这是另一个问题)。在这第一步之后，我想到了我的真实世界用例。美光服务。高度解耦的单个服务。因此，我做了我的前一个场景，我遇到了一些问题或怀疑。

场景：

我的设置包括一个反向代理( Traefik，作为服务发现和api网关)和2个Microservices。此外，还有一个openid连接安全层。我的服务是球员服务和团队服务。

因此，在auth之后，我可以使用userId来访问令牌，我可以调用player/userId来获取玩家的信息，调用teams?playerId=userId来获取球员的所有团队。

在我看来，我会在两个答复中将相反的服务联系起来。player/userId将链接到teams?playerId=userId，反之亦然。

问题：

除了通过硬编码的url链接之外，我还没有找到解决方案。但是这带来了很多的失败，我无法想象这是一个在现实应用中使用的解决方案。我的意思是，假设您的api更高级一些，您必须链接到10个资源。如果发生了一些变化，您就必须重构并重新部署它们。除了同步问题外，在这种情况下如何处理状态。我是说，休息都是为了国家的转移。所以我不会提供球员的链接到球队的服务，如果球员是在没有团队。当然，我可以向玩家添加团队I作为属性来决定是否包含链接。但这再次增加了服务之间的耦合。

我越潜越深，我发现的障碍越多，我就会和我的春季休息医生呆在一起，而忽视休息的核心，这对我来说是一件遗憾的事。

Answer 1

对于微服务架构来说是可行的？

菲尔丁，2000年

REST接口被设计成能够有效地进行大型超媒体数据传输，为Web的常见情况进行优化，但最终导致的接口对于其他形式的体系结构交互并不是最优的。

2008年实地考察

REST适用于跨越多个组织的基于网络的长寿命应用程序。

我还不清楚“微服务”是否会落入“网络”的甜蜜地带。我们通常不会与另一家公司控制的微服务进行通信，我们通常不会从缓存、按需编写代码或其他rest体系结构约束中获得很多好处。在我们的解决方案中，使用通用组件在不同的微服务之间交换信息对我们来说有多重要？诸若此类。

如果发生了一些变化，您就必须重构并重新部署它们。

是的，如果这对我们来说是个问题，那么我们需要预先投入更多的工作来定义一个稳定的界面。(在这方面，我们使用的“链接”并不特殊-如果这两种语言相互交流，那么它们就需要说一种共同语言；如果这种共同语言需要随着时间的推移而演变(很可能)，那么你就需要将这些功能融入其中)。

如果你想随着时间的推移而改变，那你就得计划好了。

如果您想要向后/向前兼容，那么您必须对其进行计划。

您的标识符不需要是静态的--有很多可能的方法推迟对标识符的定义；最明显的是您可以使用另一个标识符来查找您想要的标识符，或者计算它的公式，或者轮询程序。

想想Google是如何工作的--他们使用的链接一直在变化，但这并不重要，因为协议(刷新您的书签搜索表单，在“一个”字段中输入文本，单击按钮)已经20年没有改变了。接口是稳定的(即使标识符的底层拼写不稳定)，这就足够了。