搜索API微服务如何适应事件驱动的体系结构？

Question

如果这听起来很奇怪我很抱歉。我是非常新的系统设计，并刚刚阅读事件驱动的系统。为了更好地理解和完善我的思维过程，我决定尝试设计一个非常简单的食品点菜/配送系统(比如优步饮食)。下面我所解释的只是整个系统的一个子集，并且只针对少数用户。

我最初的设计是在中间有一个像Kafka这样的消息经纪人，并且拥有订单、支付、餐厅、通知微服务--所有这些都是消费事件。餐厅微型服务将负责所有与餐厅相关的行为，如接受客户订单、更新客户订单等。我还希望这个微型服务负责诸如增加一家新餐厅、更新一家餐厅等业务。这里是我面临的一个问题。

当用户决定搜索“墨西哥”时，我希望将此查询指向搜索微服务，该服务将查询Restaurant数据库并返回结果。但是，由于其他的微服务使用事件相互通信，这个搜索微服务可以绕过Restaurant微服务，直接查询Restaurant数据库吗？这是一个可以接受的设计吗？还是我应该完全放弃message设计，设计一些通过REST调用进行通信的东西？

Answer 1

当用户决定搜索“墨西哥”时，我希望将此查询指向搜索微服务，该服务将查询Restaurant数据库并返回结果。

这种设计违背了微服务的原则，即每个服务只能访问自己的数据库。如果需要来自其他服务的信息，那么应该通过API请求这些信息，或者服务需要将信息镜像到自己的数据库中。

使用API从另一个服务请求信息并不意味着您也不能使用message来传递更合适的事件。

但是，如果这个Search服务总是需要从Restaurant服务获取信息(或者它需要几乎完全复制Restaurant数据库)才能完成它的工作，那么将它作为一个单独的服务的决定是非常值得怀疑的。它看起来更像是应该是Restaurant服务的一部分。