我们有一个应用程序，它有用React编写的UI组件和每天保存事务的服务A。到目前为止，UI应用程序调用服务a上的REST API来获取事务数据并在UI上显示。UI层不拥有任何业务逻辑，所有业务逻辑都在服务A中。
现在我们有一个即将发生的更改，在中我们必须从服务B获取数据，服务B保存每个商店的库存详细信息，并且这些数据也需要显示在UI上。服务B目前每3小时发布一次关于卡夫卡主题的库存详细信息。
因此，建议的设计之一是：服务A使用Kafka主题中的库存详细信息(服务B正在发布(，并将本地副本存储在其数据库中，每天更新它，并公开一个RESTneneneba API来在UI上显示数据。在我个人看来，在这种情况下，服务A只是服务B拥有/发布的数据的传递，我们没有任何需要应用的业务逻辑——我们不生成这些数据。
另一个设计选项是，我们强制服务B公开一个REST端点来公开数据。
我有点困惑，什么应该是正确的方法？寻找一些指针。
第一个提案肯定不是想要的，原因有很多：
- 服务A成为这些流的瓶颈，如果它中断，UI中就不会有来自服务A和B的数据
- 通过将来自服务B的数据存储在服务A的存储中，您将在它们之间获得更多的耦合(如果服务B的消息模式发生变化，则需要将其与服务A的存储器同步(
- 如果将来添加新服务(C(，会发生什么情况？如果数据通过服务A，体系结构肯定不会扩展
第二个建议更好，因为可以避免上述一些担忧。然而，在UI层上，您仍然需要知道服务B的端点以及与该服务相关的一些特定信息(例如，它接受的标头、特定的请求参数、连接超时等(
现在，如果我们从进化的角度思考——在未来添加更多的服务，并且每个服务都有特定的端点、连接细节等，我们很快就会注意到，UI层将变得充斥着关于如何单独连接到这些服务的特定信息。
解决这一问题的一种方法是使用网关聚合模式，该模式是UI和后端服务之间的一个薄层，用于调解它们之间的通信。通过这种方式，您可以在UI上获得更多的一致性(它只需要与单个端点通信(，同时保持后端服务的独立性。
当然，这也有利弊，它不是银弹，但似乎很适合这个特定的用例。