网站对接app,代码编程基础知识,备案 网站起名,网站建设和维护采购协议书微服务架构中#xff0c;每个服务都有自己的独立数据库。然而现在有个需求#xff0c;需要生成一张实时的报表#xff0c;该报表包含两个服务的数据。如服务A#xff0c;服务B。B中仅包含A的主键id作为关联。而此报表的搜索条件包含A服务实体中的字段也包含B服务实体中的字…微服务架构中每个服务都有自己的独立数据库。然而现在有个需求需要生成一张实时的报表该报表包含两个服务的数据。如服务A服务B。B中仅包含A的主键id作为关联。而此报表的搜索条件包含A服务实体中的字段也包含B服务实体中的字段。现有方案1、如果搜索条件中包含A的条件则先去服务A中搜索得到所有结果的主键在服务B中使用where A.id IN (ids) 再次查询想法当A.id数量庞大时这个查询极其缓慢 而A.id数量庞大的情况很多2、使用搜索引擎想法感觉杀鸡用牛刀请教各位大牛有更好的方案吗回答其实这种问题在微服务中很常见,比如说需要通过商品上的一些信息查询订单,订单和商品分别属于两个微服务,该类问题的解决方案除了你自己两种方案,还有将数据聚合放入数据仓库,实时聚合A和B中的数据放入另外一个库中(不一定是mysql,也可以是Hbase),报表拉的数据都从数据仓库中拉去表设计的时候适当冗余一些字段,就如你说的在B上可预见性的冗余一些A的字段方法1有一个很致命的缺点,一旦涉及到分页,这种方式必定不可行.具体采用哪种方案,还是需要根据你的数据对应的数量级来决定,如果对应的数据量不是很大,可以采用方法1,如果速度比较慢,可以多开几个线程分批捞相应的数据(id数量太多分批拉,批量查询都是可以减少超时情况和时间的有效解决方案);如果数据量很大,建议采用数据仓库的方式,采用数据仓库的主要好处是,对主库不会产生压力,因为聚合表的产生可以通过Binlog来获取;因为报表还是属于离线数据的范畴,如果真的需要像订单查询那样实时,效率很高期间还伴随着状态的该表,并且搜索条件巨多无比,那么搜索引擎是一个很好的选择所以,可以根据实际情况采用方法1和方法3泻药如果是线上业务数据(OLTP)那么方案一是微服务的标准做法。如果线上要频繁做这种关联的查询就说明两个服务(及其两个库)的耦合非常严重那当初何必要把它们拆开来呢如果是分析报表那就属于OLAP范畴了方案二确实是一种可取的方案。如果使用搜索引擎觉得杀鸡用牛刀的话不妨试试在从库上做各种报表分析操作比如线上的A库和B库都实时同步到一个只读库中然后在只读库里JOIN一下就搞定了。生成报表这样的需求就不应该放在业务数据库系统中你可以在后端做一套otter汇聚库实时同步多个服务的数据进来然后在这个汇聚库中你想怎么玩就怎么玩方案一采用in的方式很多接口都需要通过in的方式查询当碰到分页查询这种根本不好处理。方案二感觉还没到使用搜索引擎的地步。1、传统方式在业务系统A中存入要查询的B业务系统的冗余数据便于查询。至于这个冗余数据何时进入A系统要看业务。微服务的一个设计原则是业务没有关联的服务拆开成单独的服务你这个业务之间有交叉了。你好我这边也有类似的困扰请问你采用了什么方案呢
