轻量级微服务框架的通信架构

关于微服务通信基础知识可先行参考文章：

中文连接：http://dockone.io/article/549

英文连接：https://www.nginx.com/blog/building-microservices-inter-process-communication/

接口调用如果是远程调用，那么就构成了简单的分布式。最简单的远程接口实现方式是web service或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/

从社会经济体制发展来看，虽然从生产公社制度（传统SOA）转变为个体承包责任制（微服务），但一些宏观的管理机构还是需要的，比如工商局、税务局，所有个体户都需要到工商局备案，并向税务局交税。ESB能完成类似功能、API Gateway也是。当然接口还是需要一些宏观功能需要处理，比如审计、监控。个体经营也需要审计，审计由审计局执行，也会被监控，警察局就是监控机构。对于软件系统来讲，谁来完成监控和审计？可以这样完成的：

前端发起请求，请求会先被“接口访问模块”处理，注意这个模块是请求方的功能模块。“接口访问模块”以独立jar包的方式提供给接口调用方使用，一般由接口使用团队开发，这个模块不仅仅是封装接口调用统一视图，在里面还可以扩展审计、日志监控等宏观功能。它们可以发出的审计和日志监控请求，由专门的审计系统和日志监控系统处理。使用nginx+接口访问层，或者zookeeper+接口访问层来实现宏观功能。之所以这样，因为我们认为个性化才是微服务的本质，要让每个服务都发挥出最大的主观能动性。