如果一个微服务是公共，同时内部

作者
其中有选择的能力和CRUD实体“作者”

书籍
它具有SELECT和CRUD实体的能力“book”

移动应用主机
专门为移动客户端构建，可以响应请求的完整数据模型，以便移动应用程序不会在其末尾“丰富”数据。

例：API“MobileHost.getAllBooksOfGivenAuthor”将与这两个作者姓名和书名回应，通过调用“Authors.getAuthorData（的AuthorID）”，并合并其数据“Books.getBooksByAuthorIds（AUTHORID）”所获得的结构像这样：

{ 
    "author" : { 
    "name" : "Winner", 
    "id" : 1 
    }, 
    "books" : [ 
    { 
     "name" : "Book A", 
     "id" : "13231231" 
    } 
    ] 
}

我问题是：
如果移动客户端读取通过“移动应用主机”的数据应该是做“添加作者”到“移动应用主机”还，还是确定以直接联系“作者”服务？在这种情况下CRUD应该被代理吗？

来源

2017-02-08 user3765648

这取决于你的目标。

根据我的经验，这样的“主机”或“代理”服务往往会变得越来越大，没有任何真正的责任。将多个班级，功能和责任结合在一个地方肯定是一个糟糕的主意 - 随着时间的推移维护这种服务将很困难。

此外，如果仅需要扩大作者服务范围，则可能非常困难且资源无法扩展此类服务的实例。因此，如果您要分别扩展不同的服务和活动，那么当然，您不需要仅使用一个服务代理请求。例如，您可以拥有多个代理服务，以便单独扩展它们或直接调用作者服务，并且扩展它们而不是代理服务器。

但是，如果您没有看到提及的机会，那么尽可能简单 - 当您需要做到这一点时，您可以将服务及其代理分开，只需将所有内容分开即可。

来源

2017-02-08 16:33:05 cassandrad

感谢您的详细回复。对你来说还有一个问题：除了'主机'服务，你是否创建内部和外部的API？如果你这样做，你能否说出你为什么这样做的原因？谢谢。 – user3765648

由于缓存，我们对API服务有混合策略。 API缓存一些非常频繁的数据，并从查询中的缓存中返回数据。它还处理分页和从服务只提取特定的“页面”数据。如果存在不需要任何缓存系统的服务，我们直接调用它，因为它减少了在高负载下可能相当昂贵的服务间通信量。但是我们的API服务在任何时候都被设计成分离的，他们遵循门面设计模式。如果我们注意到API服务的一小部分存在巨大的负载，我们会把它拿出来。 – cassandrad

谢谢，现在我有一个清晰的视野。 – user3765648

如果一个微服务是公共，同时内部

回答

相关问题