在微服务设计过程中，经常出现的一个共同点和要求是共享共同数据。而这个问题在微服务之间的异步消息驱动通信（使用Kafka）中变得更加有趣了
例如，微服务1有一些数据。微服务2和3想要访问这些数据。
我看到了3个选项。
- 共同存储：微服务1的存储被存储在2和3中。
- 本地存储：2和3所需要的通用数据也存储在他们那里，可能不是全部的数据，但也是所需要的。
- 来自1的API暴露：2和3通过API向1询问这些数据。由于这是一个基于Kafka的通信。由于Kafka是异步的，所以通过Kafka来做是很困难的，这种情况最好通过HTTP REST调用来实现。
显然，没有银弹，解决方案取决于需求和现有架构。
网友观点：
1、我会选择2。因为我从来没有做过其他更基本的错误，如
- 在没有多个团队的情况下做微服务
- 为了性能而做ms
- 无视康威法则、团队动力等。
- 认为分布式系统比漂亮、干净的模块更简单
- 认为模块不能执行或横向扩展
- 认为在微服务中建立或修复领域边界比在模件中更容易。
- 认为我是Netflix，以壮大我的自我
记住：每一个微服务都应该是高可用的、模块化的、可随时独立部署的，否则你就真的是一个分布式的单体，和20年前的SOA没有什么区别。
记住：你做微服务是通过拆分你的漂亮、干净的单体，以便随着公司的发展为新团队腾出空间。
这意味着：微服务首先是一种组织模式。
2、在真正的微服务中，每个服务都处理自己的数据。数据可以跨服务传输（例如，服务 1 需要有关服务 2 的数据，但服务 2 仍然持有并提供它）
3、没有共享的数据。数据有所有者和消费者。“共享数据”的心智模型已经是对低效架构的承诺。