我正在开发一个新的实现，其中我对在微服务架构中使用共享数据库的利弊有一些疑问。
背景：
服务A监听来自Kafka的事件，并根据参数更新特定的表。此表完全由服务A拥有，不共享。此表中的某些数据需要由其他服务根据特定字段的值访问。
我的方法：
一旦表被更新，如果我们知道这个数据可能被其他服务所需要（通过检查字段的值），就把它写入ES索引。我想保持ES索引在服务之间共享。
其它服务将在需要时读取ES索引。这些服务将仅使用索引用于读取，而服务A是写入索引的唯一服务。
另外，我在服务A中添加了一个后备API，它会在ES关闭时访问表。请查看图表，我在下面添加了一个链接。
问题：
我能想到的一个问题是，如果ES完全关闭，那么服务A将无法写入ES，因此行更新将失败。
我还需要帮助找出基本的可伸缩性和部署问题，这些问题可能会通过引入共享ES索引对微服务架构产生反作用。我认为我已经通过为其他服务添加后备API来消除一些弹性问题，以防ES出现故障。
请批评我的设计。
1条答案
按热度按时间dfuffjeb1#
我看有三个选择：
**选项A：**服务A需要实现与two-phase commit protocol等效的东西，其中服务A从Kafka使用的事件在DB和ES都确认它们的写入之前不会被确认。这给您的服务带来了很大的负担，如果两个子系统（DB和/或ES）中的一个出现故障，将不得不花费时间重试，并且无法从Kafka使用更多的事件。事件将开始在主题中堆积。2 PC很难在分布式环境中正确实现。
**选项B：**服务A从Kafka主题A消费，在另一个Kafka主题B中完成它的事情并产生另一个事件。然后负责更新子系统的两个其他消费者组将消费来自主题B的那些事件，一个将保持更新DB，另一个将保持更新ES。服务A可以快速地完成它的工作，而不必担心或陷入更新。每个消费者组可以独立地重试每个更新，而不会影响上游事件消费。最终，一切将同步。
**选项C：**它是选项B的变体，更轻量级。服务A使用Kafka主题中的事件，完成其工作并像现在这样更新数据库。另一个进程（CDC、Logstash等）使用数据库中的更新并异步更新ES，还负责在ES关闭时重试。最终，所有内容也将同步。
还有其他选择，但这3个是最明显的我。