关于微服务通信基础知识可先行参考文章：
中文连接：http://dockone.io/article/549
英文连接：https://www.nginx.com/blog/building-microservices-inter-process-communication/
接口调用如果是远程调用，那么就构成了简单的分布式。最简单的远程接口实现方式是web service或rest。当然一个合理的分布式应用不仅仅是远程接口调用这么简单。还需要有负载均衡、缓存等功能。最简单实现分布式的技术是Rest接口，因为Rest接口可以使用现存的各种服务器，比如负载均衡服务器和缓存服务器来实现负载均衡和缓存功能。
使用负载均衡服务器后Rest接口的应用就可以进行集群部署形成分布式。但Rest接口通常用于对外发布的服务，也就是外网服务。内网服务往往要求更高的性能，比如采用netty来进行通信，这种情况下如何做到负载均衡呢？这个时候就需要一个第三方的组件来管理和进行负载均衡。这个第三方组件最常用的就是Zookeeper。
Zookeeper通过维护接口的列表及活动状态从而实现了负载均衡。因此除rest接口外其它的接口访问方式，如thrift、netty等，都需要zookeeper来提供负载均衡。如果需要缓存，那么还需要引入memcache或Redis等分布式缓存来实现。
连接文档的例子中，提到一个打车软件接口交互的场景，如下图。交互方式是这样的，乘客发起请求调用出行管理模块，出行管理模块通过一个“请求转发”模块分别再次调用乘客管理模块和司机模块进行处理，处理该乘客的打车请求，处理完后通过“通知”模块通知乘客。
这里主要关注“请求转发”模块。在孢子框架中，在开发初期建议所有接口都使用Rest接口。所以项目初期，“请求分发”模块在孢子框架中我们使用Nginx来实现。到了后期，如果要提升内部调用接口的效率，内部接口如果用thrift等实现，那么这个模块是通过Zookeeper来实现。
这个模块在业界还有一种典型的做法叫做“API Gateway”，API Gateway是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个API Gateway架构。如下图：
API Gateway介绍原文连接：https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
孢子框架不提倡API Gateway的方式，这看上去就是一个传统的ESB服务总线，这岂不是又回到了传统SOA。虽然不提倡，但并不否定传统ESB强大和优点。如果一个企业肯花大力气来完成这个当然是好，这种宏观的东西对于大公司复杂业务处理还是有帮助的。从社会经济体制发展来看，虽然从生产公社制度（传统SOA）转变为个体承包责任制（微服务），但一些宏观的管理机构还是需要的，比如工商局、税务局，所有个体户都需要到工商局备案，并向税务局交税。ESB能完成类似功能、API Gateway也是。社会上工商局主要完成登记功能，不会去干涉个体经营，而ESB和API Gateway就有点过了，它们有些功能干涉了个体应用的执行，比如上面提到的缓存、静态响应处理等，这些都是个体应用关注的。所以这里我们还是提倡不去做ESB和API Gateway。没有ESB和API Gateway，那么负载均衡是怎么做，上文已经说明了，就是nginx和zookeeper。当然接口还是需要一些宏观功能需要处理，比如审计、监控。个体经营也需要审计，审计由审计局执行，也会被监控，警察局就是监控机构。那么分布式如果没有ESB和API Gateway，由谁来执行审计和监控呢，在孢子框架是这样完成的：
在孢子框架中所有宏观功能都是如此处理：前端发起请求，请求会先被“接口访问模块”处理，注意这个模块是请求方的功能模块。“接口访问模块”以独立jar包的方式提供给接口调用方使用，一般由接口使用团队开发，就是我们前面提到的框架里的org.spore.store.idl，这个模块不仅仅是封装接口调用统一视图，在里面还可以扩展审计、日志监控等宏观功能。它们可以发出的审计和日志监控请求，由专门的审计系统和日志监控系统处理。孢子框架使用nginx+接口访问层，或者zookeeper+接口访问层来实现宏观功能，代替传统ESB。之所以这样，因为我们认为个性化才是微服务的本质，要让每个服务都发挥出最大的主观能动性。