Question

假设我有一个微服务架构，我有一个Book微服务，其中包含所有书籍详细信息，而作者微服务则包含所有作者详细信息，例如

Book Service
GET /     get all books
GET /id   get book details, including author_ids
POST /    create new book
etc.

Author Service
GET /     get all authors
GET /id   get author details, including book_ids
POST /    create new author
etc.

真正的服务更具企业级别，我只选择具有自己的数据存储选项的书籍和作者作为一个易于理解的例子。

假设将有数百万次调用服务，我必须维护系统的特定可用性和吞吐量。如何有效地搜索名称以＆＃39; A＆＃39;以及作者写的所有书籍，其中书名以＆＃39; B＆＃39;？

开头

我看到以下选项，这些选项都不完美：

我在作者服务中创建一个搜索端点，获取符合搜索条件的所有作者，按照每个book_id并过滤书籍。 - ＆GT;这需要对Book服务进行大量调用。
与1.相同，但我在Book服务中创建了一个搜索端点，获取符合搜索条件的所有书籍，按照每个author_id并过滤作者。 - ＆GT;这需要对作者服务进行大量调用。在最坏的情况下，与1中的负载相同。
我创建了一个新的微服务搜索。搜索将拥有自己的数据库，该数据库针对搜索进搜索将返回书籍和作者，并可以通过一个电话给我搜索结果。 - ＆GT;这要求Search经常与Book and Author服务同步。
我将Book and Author合并到一个服务中，这违背了mircroservices的目的？

也许有更多微服务经验的人可以帮助我如何最好地设计这个。

Answer 1

你应该不再担心将微服务正常化了。这是微服务的难点之一，就是不再考虑它们，就像它们是完全规范化的数据库表一样。

我会将您的作者姓名与您的书籍一起存储。您可以在作者服务中具有扩展的作者属性，并且您仍然可以使用作者ID链接这两者，但保留足够的非规范化作者信息以在该书籍服务中执行搜索。

然后对搜索的调用很简单......潜在的缺点是，作者信息在书上已经过时了，可能没问题......如果有人更改作者姓名，则必须有一个过程从作者服务更新它，但这是一个比每个调用查找作者更可扩展的进程。

Answer 2

嗯，如果你选择使用选项1或2，你会有很多电话是正确的。如果你选择3，你可以使用像ElasticSearch这样的搜索技术（可以用作搜索技术）以及作为文档的数据存储）或者您可以使用由您选择的数据库支持的SOLR技术。每当您向Books Microservice添加Book时，引发一个包含有关书籍数据的事件，您的搜索服务会将此事件数据反规范化为JSON文档并将其存储在Elasticsearch中。同样，收听来自Author Microservice的事件并将它们反规范化为数据库。

为了避免大量调用，您还可以做的是维护有关Books Microservice中Books的所有数据（以及有关Author的数据）以及Books Microservice中有关作者的所有数据（以及有关Books的数据）。会有很多冗余（并且会出现数据同步等问题），但至少现在你不必进行任何跨服务调用。

在微服务架构中搜索查询

2 个答案: