传统模式：
比如说拿一个商城来举例子，就是我的添加购物车，下单，支付，扣减优惠卷，增加积分等一系列操作全部在一个系统上，那么当我并发超过负载，那么就全崩了。还有啊，比如我要修改下单的某个bug，那么我就需要把整个系统拿过来修改然后重新部署。
随着业务的发展和并发量的发展，要求越来越高，那么为了我们开发轻便，所以产生了分布式。
分布式模式：
商城系统在分布式模式中，那么添加购物车，下单，支付，扣减优惠卷，增加积分这些操作都可以分为单应用。当我们一个应用down掉，那么不会导致全部崩掉，我们快速拿去有问题的应用进行修复，然后重启就可以恢复。
把应用弄成分布式以后呢，那么就有问题了，我的应用调用原来直接调本地方法就好了呀，分开了怎么调呢？
其实我理解的这个问题就好像操作系统中的多进程通信，我们怎么协调这些进程为我干事呢？
方案一:直接接口调用
当然只是这样肯定不行，我们还要考虑心跳监听呀，熔断，负载均衡等。
可能也没画全，大概是这样一个架构。
然后其实调用的实质：
这个调用过程的主要是是在建立连接的时候，使用什么协议建立连接，长连接还是短链接，怎么进行重试，容错机制怎么做。
方案二：共享内存（更多的使用mq的订阅模式）
其实这种方式我以前很少见到，最近发现我新的公司大部分都是用的事件驱动的。但这种方式有个缺点就是没办法返回数据。
具体实现：
这样的好处就是耦合度特别低，而且业务逻辑比较清晰，加入了中间件让成本增加了。