我们目前在自己的数据库中拥有2个微服务。这些微服务是Tier-2服务，在某些CRON触发器处以异步方式填充其数据库。我们当前的要求是建立一个独立于Tier-1的可部署服务单元，该服务单元能够以较高的RPM，可用性和可接受的延迟通过API将这些数据提供给重要的客户端。
需要此服务才能将这两个数据库中的数据聚合到一个对象中，以便在某些字段上使用简单的聚合（例如SUM）进行服务。
例如：DB-1 => cars（由服务，S1拥有）和DB-2 => buses（由S2拥有）
要投放的对象：DTO(List<Car> cars, List<Bus> buses)，DTO(long carCount, long busCount)等。
我们不想创建一个API聚合器，因为我们不想维护Tier-2服务的正常运行时间只是为了提供其拥有的数据，还有延迟问题。我们正在考虑采用共享数据库体系结构，其中Aggregator服务连接到DB-1和DB-2并直接为其提供服务。这违背了所关注的微服务架构。同样，这意味着Aggregator服务还需要为相应的表创建Entity类。
背景知识：实际上，这实际上是Java Monolith，这是我们正在探索的可分为独立微服务的3个模块。数据库写入后的S1's数据也将通过Kafka被其他不同的服务使用（数据库写入后的Kafka Push，随后是其他服务对其他任务的处理）
从业务理解的角度来看，连接的数据库数量不会增加，并且Aggregator与2个数据具有关联性
在这样的情况下，通常需要处理通过高吞吐量API进行的数据服务，即该服务需要使用较小的聚合来提供多个负责的服务的数据，基本上是它不拥有的DB中的数据？任何见解将不胜感激。