微服务架构中,服务之间都是独立数据库,如何做到高性能地数据关联展示?

微服务架构中,服务之间都是独立数据库,如何做到高性能地数据关联展示?

首先.微服务应当是隔离而独立的吗?.

是的，微服务架构的一个核心原则是每个微服务应该具有自己的独立数据库。这种独立性有助于实现微服务的解耦和可扩展性。

通过为每个微服务分配独立的数据库，可以实现以下好处：

解耦性：每个微服务都有自己的数据库，可以独立地进行数据模式设计和数据管理。这样，对一个微服务的数据库进行更改或优化时，不会对其他微服务产生影响。

可扩展性：独立的数据库使得每个微服务可以根据其自身的需求进行水平扩展。当某个微服务的负载增加时，可以单独扩展其数据库，而无需影响其他微服务。

性能优化：由于每个微服务具有自己的数据库，可以根据其特定的需求进行性能优化。针对每个微服务的查询和事务可以进行专门的优化，提高整体系统的性能。

数据隔离：微服务之间的数据是相互独立的，每个微服务只能访问其自己的数据库。这样可以确保数据的隔离性和安全性，防止一个微服务的故障对整个系统的数据产生影响。

需要注意的是，微服务之间的通信和数据同步可能会引入一定的复杂性和开销。在设计和实现微服务架构时，需要考虑好微服务之间的数据交互方式和一致性保证机制。

---

比如说商品服务,订单服务.

如果我们的订单列表的需求是:查询出订单,并且附带上该订单的商品名字和图片.
那么就需要这一件事情,多个服务共同参与,共同关联数据.
我们可以怎么做?

---

1.实时查询

我们可以在订单服务里面,实时查询

1.订单服务:查询出分页的一组订单列表,然后调用 商品服务提供的查询接口.
2.商品服务提供的查询接口的查询条件是商品id_list. 里面的具体查询也是 where id in (id_list),然后把商品信息返回给订单服务
3.订单服务拿到了一组商品,for循环塞入数据

优点:
简单操作,易于理解,不需要维护其他的东西,只需要在服务端进行组装数据即可.

缺点:
这种情况会导致 基础服务的压力很大,在高并发时候,基础服务容易造成雪崩效应.
另外,在考虑到调用服务时发生的熔断后,是直接报错,还是返回部分,也是值得考虑的问题.

2.数据库设计冗余

我们可以在订单表里添加 商品名称和商品图片 两个字段即可.

优点:
查询性能高，不需要跨服务查询，缓存策略简单

缺点:
冗余查询快,但就意味着增删改的时候麻烦.比如修改商品的时候,也要修改订单里面的商品字段.删除商品的时候,也要删除订单里面的商品字段.相当于业务又重做了一部分.在系统上,又感觉耦合了.如果某些字段变更速度很快,那就很麻烦.

3.搜索引擎

数据扔搜索引擎里面.所有服务共享该搜索引擎.

该方式可行,本质上是再创建一个大家公用的库.
优点:
性能优秀

缺点:
1.搜索引擎 应该只作为查询结果,而不要再根据查询结果 追加业务.
2.增加维护成本

4.同步部分其他服务的表

该方案是:订单服务里面添加个商品表,一直同步商品服务的商品表.订单服务里面的商品表不能乱修改.

可以找Canal、Debezium、DataX、Databus、Flinkx、Bifrost 这种中间件来操作

优点:代码层面比较简单,符合目的

缺点:
1.冗余表数据,需要同步中间件高可用
2.对于不同的数据库 就比较麻烦

5.构建查询数据库

重新建一个数据库,copy所有的表.该数据库用于查询.

优点:
1.总体构建比较简单,不管三七二十一,同步所有即可.
2.代码层面还可以

缺点:
性能不咋地,同步中间件需要高可用
对于不同的数据库 就比较麻烦
对于及时性不高的是可以的

6.数仓做数据汇聚

数据放数仓,从数仓查

7.数据内存查询

spark，flink 等重量级的内存计算引擎,内存中join