直接访问对方DB

缺点是显而易见的，直接访问对方DB了，那还分什么服务呢？这种方法是绝对禁止的。生产环境中的许多程序错误和性能问题都是通过这种方式产生的。以上三种方法都是新建的本地只读数据库表，导致数据库的物理隔离，这样数据库的性能问题不会影响另一种。此外，当主库中的表格结构发生变化时，您可以暂时保持从库中的表格不变，这样程序就可以运行。如果直接访问他人的库，主库一旦修改，其他微服务程序将立即报错。

调用服务API

不同的微服务之间需要进行数据共享；目前微服务之间，大多数采用调用服务API的方式，进行数据共享或通信。这种方式，对于数据量比较小、使用不频繁的场景，比较适用；一旦交互数据量较大，则会严重影响业务处理性能，甚至会造成系统阻塞。

使用消息队列

使用消息队列，如当 Payment Service 有新数据是就发布，Customer Service 进行订阅，这样只需要在Customer Service中保留需要的前5条数据即可。

共享Session

session域是存储在服务器端的内存中，但是现在使用微服务，各个功能模块之间拆分成不同的服务，每个服务负责某种功能，每个服务都是一个进程，所有每个服务中的内存数据是不共享的，故存储在每个服务中的session对象不可以被所有的微服务共享。Session对象，就是客户端浏览器与服务器之间建立的互动信息状态。每一个不同的用户连接将得到不同的Session，也就是说Session与用户之间是一种一对一的关系。Session在用户进入网站时由服务器自动产生，并在用户正常离开站点时释放.，现在项目是微服务项目，有多个服务，每个服务之间的内存是不共享的，所有session存储在某个服务的内存中其他服务是获取不到的。

将各个服务之间需要共享的数据，保存到一个公共的地方(主流方案就是 Redis)：

当所有 Tomcat 需要往 Session 中写数据时，都往 Redis 中写，当所有 Tomcat 需要读数据时，都从 Redis 中读。这样，不同的服务就可以使用相同的 Session 数据了。此时，开发者可以手动往redis中进行读写操作，或直接使用spring提供的Spring-session，Spring Session 就是使用 Spring 中的代理过滤器，将所有的 Session 操作拦截下来，自动的将数据 同步到 Redis 中，或者自动的从 Redis 中读取数据。对于开发者来说，所有关于 Session 同步的操作都是透明的，开发者使用 Spring Session，一旦配置完成后，具体的用法就像使用一个普通的 Session 一样。

session对象：用户访问某个微服务的时候，创建了session对象，为这个对象生成一个唯一的jessionid，这个jessionid是存储在cookie对象中，返回给浏览器端，以后客户端每次给服务器发送请求的时候都会带这个存储jessionid的cookie。服务器端如果使用这个jessionid找到了对应的session,那么就可以直接获取session域中存储的数据，如果服务器端没有找到这个jessionid对应的session，那么服务器端会新创建一个session对象，给这个对象在行创建一个sessionid去存储到cookie中返回给浏览器，这样也就修改了jessionid导致即使他访问原来的服务，由于jessionid修改了也会找不到原来的session数据

所以把session存储到内存中这样的方法不适应于微服务，解决方法：把session对象存储到redis中，只要所以的服务绑定同一个redis就可以获取到redis中的存储的session数据。

spring:
  redis:
    host: 127.0.0.1
    port: 6379
    jedis:
      pool:
        max-active: 8
        max-wait: -1
        max-idle: 500
        min-idle: 0
    lettuce:
      shutdown-timeout: 0
  session:
    store-type: redis

配置好上面后，项目中创建的session都存储到redis中

总结

以上方法是我总结的，但微服务通信没有最佳的解决方案。每种方法都有利弊。记住，选用最适合自己业务的解决方案，就是最好的。