在单体架构中,不同模块之间可以通过项目引用的方式直接使用接口调用,单次请求在同一台机器的同一个进程内进行,这种调用方式称为本地调用,但是在微服务架构中,每个服务都是独立的进程,并且通常部署在不同的服务器,无法简单的使用本地调用的方式,而是需要远程服务调用来实现服务间的通信。
目前有很多种进程间通信的技术供开发者选择,可以使用基于同步请求/响应的通信机制,例如:http Restful和 grpc。也可以使用异步的基于消息的通信机制,例如,AMQT,MQTT等。从服务端和客户端的交互方式上,可以将通信模式按两种维度划分。第一个维度关注的是一对一和一对多:
第二个维度关注的同步和异步:
在实际的项目中,同步请求/响应模式是被应用最频繁的模式,底层的通信机制可以使用http协议或grpc。
由于http协议的简单,灵活,可靠,易于扩展等特性,被广泛应用于前/后端和服务间的通信,服务端通过http协议对外暴露API,RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。REST中的一个关键概念是资源,它通常表示一个业务对象,REST使用http动词来操作资源,使用URL引用这些资源。关于Resulful风格API的详细内容可以参考我转载的阮一峰老师的文章:Restful API设计规范
由于http动词的限制,Restful API并不能总是满足实际的业务需求,在需要支持多种更新操作的场景时,Rest无法通过有限的动词实现,避免此问题的进程间通信技术是使用RPC框架,对于RPC框架一个通俗的描述是:客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端应用的方法。gRPC就是众多RPC框架中的一种,它是一个高性能、开源和通用的 RPC 框架,基于ProtoBuf(Protocol Buffers) 序列化协议开发,且支持众多开发语言。面向服务端和移动端,基于 HTTP/2 设计,带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特。这些特性使得其在移动设备上表现更好,更省电和节省空间占用。
想象一个会员注册的场景,会员注册成功后,平台需要给会员发送注册成功的短信,增加注册积分,推送会员指引消息等等。这些对实时性要求不高,并且一对多的场景,就可以采用消息发布/订阅的模式来实现服务间的解耦,同时提升服务的响应速度。消息队列是实现消息发布/订阅的模式的通用解决方案。
从本质上说消息队列就是一个队列结构的中间件,通过它可以实现服务间的解耦、流量的削峰填谷、系统整体吞吐量的提升。
当会员注册成功后,应用不直接调用发送短信、发送积分,推送指引消息的接口,而是向消息队列中推送一条会员注册成功的消息(其中包含会员Id,会员名字,注册时间等重要信息),然后直接返回,由于不需要等待其他几个服务的执行结果,大大减少了会员注册接口的响应时间。同时下游的短信、积分、消息服务向消息队列订阅会员注册成功的消息,当收到新的消息时,再根据消息内容执行具体的业务的逻辑,这样就实现了服务间的解耦。后面会员注册成功需要增加新的需求时,只需要增加一个新的服务订阅该消息,实现具体的业务逻辑即可,而不需要修改会员注册的代码,这样就大大的提升了系统的封闭性和扩展性。
在分布式环境中,由于网络错误,服务不可用等原因,网络请求无法做到百分百的有效,在使用消息发布/订阅模式时,为了保证系统间数据一致性,需要注意以下几点: