微服务架构中，每个服务都有自己的独立数据库。
然而现在有个需求，需要生成一张实时的报表，该报表包含两个服务的数据。
如服务A，服务B。B中仅包含A的主键id作为关联。
而此报表的搜索条件包含A服务实体中的字段也包含B服务实体中的字段。
现有方案
1、如果搜索条件中包含A的条件，则先去服务A中搜索，得到所有结果的主键，在服务B中使用where A.id IN （ids） 再次查询
想法：当A.id数量庞大时，这个查询极其缓慢！ 而A.id数量庞大的情况很多
2、使用搜索引擎
想法：感觉杀鸡用牛刀
请教各位大牛有更好的方案吗
瀉藥
如果是線上業務資料(OLTP)，那麼方案一是微服務的標準做法。如果線上要經常做這種關聯的查詢，就表示兩個服務(及其兩個函式庫)的耦合非常嚴重，那當初何必要把它們拆開來呢？
如果是分析報表，就屬於OLAP範疇了，方案二確實是一種可取的方案。如果使用搜尋引擎覺得殺雞用牛刀的話，不妨試試在從庫上做各種報表分析操作，例如線上的A庫和B庫都即時同步到一個唯讀庫中，然後在只讀庫裡JOIN一下就搞定了。
微服務的一個設計原則是業務沒有關聯的服務拆開成單獨的服務，你這個業務之間有交叉了。
其實這種問題在微服務中很常見,比如說需要透過商品上的一些資訊查詢訂單,訂單和商品分別屬於兩個微服務,該類問題的解決方案除了你自己兩種方案,還有
將資料聚合放入資料倉儲,即時聚合A和B中的資料放入另外一個庫中(不一定是mysql,也可以是Hbase),報表拉的資料都從資料倉儲中拉去
表設計的時候適當冗餘一些字段,就如你說的在B上可預見性的冗餘一些A的字段
方法1有一個很致命的缺點,一旦涉及到分頁,這種方式必定不可行.具體採用哪種方案,還是需要根據你的數據對應的數量級來決定,如果對應的數據量不是很大,可以採用方法1,如果速度比較慢,可以多開幾個線程分批撈相應的數據(id數量太多分批拉,批量查詢都是可以減少超時情況和時間的有效解決方案);如果數據量很大,建議採用資料倉儲的方式,採用資料倉儲的主要好處是,對主庫不會產生壓力,因為聚合表的產生可以透過Binlog來取得;因為報表還是屬於離線資料的範疇,如果真的需要像訂單查詢那樣實時,效率很高期間還伴隨著狀態的該表,並且搜索條件巨多無比,那麼搜索引擎是一個很好的選擇
所以,可以根據實際情況採用方法1和方法3
產生報表這樣的需求就不應該放在業務資料庫系統中，你可以在後端做一套otter匯聚庫，即時同步多個服務的資料進來，然後在這個匯聚庫中你想怎麼玩就怎麼玩