微服务间数据传输
serviceA传数据给serviceB,如上图：
数据载体有4种方式：
1. Feign调用
2. cache
3. mq
4. 操作serviceB DB
一、直接操作serviceB数据库不可取
根据服务化的原则，数据是私有的（本质也是解耦）：
（1）service层会向数据的需求方屏蔽下层存储引擎，分库，cache的复杂性；
（2）任何需求方不能绕过service读写其后端的数据；
（3）不符合DDD设计思想
所以直接操作serviceB数据库肯定不可取，而是通过RPC接口访问，如下图。
二、Feign调用适用场景：
- 适用于不要求数据实时性场景，Feign调用不实时，有时延。
- 数据量非常小的情况
cache和mq哪种比较适合传输数据
1. 你遇到过这种“服务之间通过缓存传递数据”的架构设计么？
（1）服务A将数据放入缓存；
（2）服务B从缓存里读取数据；
看起来没问题，我们细细分析下。
三、缓存作为数据存储载体
好处是：
(1) 缓存的读取和写入都非常快；
（2）服务A和服务B物理上解耦；
弊端是：
数据共管场景，两个(多个)service同时读写一个cache实例会导致耦合。
（1）大家要彼此协同约定key的格式，ip地址等，耦合；
（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发送数据失败，消费端幂等问题！
