在微服务世界中，通常一个微服务需要以同步或异步方式调用另一种微服务。
在同步通信方式的情况下，我理解它会影响服务的可用性，因为两个服务都需要在调用期间可用。
为了尽量减少这种同步通信方式，一种可能的解决方案是在客户端服务中进行数据复制。客户端服务还通过侦听服务发布的事件来更新数据。
在我看来，这不是一个好的选择，因为我们正在复制数据，它可能会变得陈旧，而且还会产生数据库开销。
当上述模式最适合时，最适合的场景是什么？
【问题讨论】：
标签： microservices
微服务是分布式系统。这意味着它们受到 CAP 定理的约束，这基本上意味着您可以选择：
牺牲可用性以保持一致性：这将（除其他外）导致一个服务以同步方式在另一个服务中调用功能。如果其他服务不可用，则该服务中依赖于该服务功能的所有功能也将不可用。
牺牲一致性以保持可用性：您将服务构建为自治的，而不依赖于其他正在运行的服务。这会在相当短的时间内导致服务不共享数据库和数据的异步复制（因为如果服务 A 已从服务 B 同步复制数据，那么服务 B 停机不会影响 A 的可用性，但 A 停机会影响 B 的可用性） : 使用异步复制，您所能期望的最好结果就是最终的一致性。
这两者之间的选择（如果您碰巧有能力在存在网络分区的情况下冻结整个宇宙，那么您可能会为了一致性和可用性而牺牲分区容限）最终是一个业务问题（值得注意的是在这些极端之间有一个连续的方法）。您在存储和设计（可以说）更复杂的系统上花费了多少，而您因不可用而损失了多少？
应该注意的是，宇宙本质上是最终一致的：太阳可能在几分钟前就变成了超新星，而我们再过几分钟就无法知道了。
关于重复数据的担忧：数据可能已经重复（备份），并且在任何值得使用的数据库中数据都是重复的（预写日志）。
至于情况，很难想到以强一致性为目标的情况是最合适的选择。
但是，以连锁咖啡店为例。我们有收银服务和忠诚度/奖励服务。收银机需要来自忠诚度/奖励服务的数据（如果客户正在兑换“拿铁 50% 折扣”的奖励，您希望收银机知道它是有效的），以及每笔交易（至少那些有奖励服务应该知道登记处的忠诚度 ID。
如果我们希望奖励兑换保持一致，则意味着如果无法从注册表访问忠诚度/奖励服务，则无法兑换奖励。无法兑换奖励的顾客直接离开的可能性非零（而且他们再也不会从您那里得到咖啡的可能性也非零）。
相反，如果我们希望两种服务具有一致的视图，那么我们要求如果任何商店断电，我们无法确定新的奖励，或者如果忠诚度/奖励服务无法从注册表中访问，则不可以进行新的销售。
解决方案是让两个服务都维护它们运行所需的数据，即使另一个服务控制对该数据的更新。他们最终会赶上的。在奖励兑换的情况下，假设不可用的情况很少发生，甚至可能需要让收银机执行初步验证，如果通过，则假设奖励有效并稍后将其提交给忠诚度/奖励服务。
【讨论】：