vlambda博客
学习文章列表

微服务间数据传输

serviceA传数据给serviceB,如上图：

数据载体有4种方式：

1. Feign调用

2. cache

3. mq

4. 操作serviceB DB

一、直接操作serviceB数据库不可取

根据服务化的原则，数据是私有的（本质也是解耦）：

（1）service层会向数据的需求方屏蔽下层存储引擎，分库，cache的复杂性；

（2）任何需求方不能绕过service读写其后端的数据；

（3）不符合DDD设计思想

所以直接操作serviceB数据库肯定不可取，而是通过RPC接口访问，如下图。

二、Feign调用适用场景：

1. 适用于不要求数据实时性场景，Feign调用不实时，有时延。

2. 数据量非常小的情况

cache和mq哪种比较适合传输数据

1. 你遇到过这种“服务之间通过缓存传递数据”的架构设计么？

（1）服务A将数据放入缓存；

（2）服务B从缓存里读取数据；

看起来没问题，我们细细分析下。

三、缓存作为数据存储载体

好处是：

  (1)   缓存的读取和写入都非常快；

（2）服务A和服务B物理上解耦；

弊端是：

数据共管场景，两个(多个)service同时读写一个cache实例会导致耦合。

（2）约定好同一个key，可能会产生数据覆盖，导致数据不一致；

（3）不同服务业务模式，数据量，并发量不一样，会因为一个cache相互影响，例如serviceA数据量大，占用了cache的绝大部分内存，会导致serviceB的热数据全部被挤出cache，导致cache失效；又例如serviceA并发量高，占用了cache的绝大部分连接，会导致serviceB拿不到cache的连接，从而服务异常；

（4）不实时，有时延

（5）cache具备将数据存在内存里，具有“易失”性。

综上，数据共管场景，多个service耦合在一个cache实例里，也是不推荐的

四、数据管道场景，MQ比cache更加适合

服务A生产数据，服务B（当然，可能有服务C/服务D等）订阅数据，MQ比cache更加合适：

（1）MQ是互联网常见的逻辑解耦，物理解耦组件，支持1对1，1对多各种模式，非常成熟的数据通道

（2）MQ能够支持push，数据是实时

（3）MQ天然支持集群，支持高可用

（4）MQ能支持数据落地，数据放在磁盘。专业的事情应该让专业的技术来干。nginx做反向代理，db做固化，cache做缓存，mq做通道

 （5）可扩展，业务V2.0,新增服务，或者定制化功能。可以直接订阅服务A,进行自身的业务处理。

综上，数据管道场景，MQ比cache更加适合。

五、综上所述

（1）数据管道场景，MQ比cache更合适

（2）服务化架构，不应该绕过service读取其后端的cache/db，而应该通过RPC接口访问

六、MQ注意问题：

MQ发送数据失败，消费端幂等问题！

原创不易，喜欢，点赞、在看，感谢