1 体系结构
服务体系结构如下图:
从接口方式分目前有2类服务:Java开发的Thrift服务,C++开发的HTTP服务
未来转向全部采用HTTP服务,全部采用Java开发,以Spring Cloud为服务体系。
新项目按新规定的体系结构开发。
对于现有的C++服务,Java Thrift服务,作为遗留系统保留和维护,包括重构,与SpringCloud集成。
服务向Eureka注册,Java REST服务器基于Spring Cloud,利用EurekaClient注册,Java-Thrift服务利用springcloud-register包注册,C++服务由SpringCloud插件注册。
遗留系统内的2类服务之间通过Thrfit方式相互调用。
Java REST服务之间采用Feign调用,通过Thrift调用遗留系统。
若需要,Java Thrift服务通过Feign调用新REST服务,C++服务通过HTTP调用 REST服务。
需要开发springcloud-register,实现以下功能:注册,健康检查,状态接口。
2 HTTP-Thrift网关
与应用无关的实现,即通用网关,不需要RPC的skeleton,stub代码,新增和维护都不需要编写代码和项目构建。
实现思路是建立以下映射:
l URI与Thrift服务接口映射
l HTTP请求QueryString,消息体报文与Thrift报文的映射
由于网关只是把客户端的HTTP请求,转换为对服务的调用,请求与服务接口之间简单的一一对应是可行的,在设计时约定,相同的结构和命名可以减少映射开销。
网关位于请求到服务的必经路径上,对性能敏感,减少映射过程的开销对性能的影响
消息编码:
l 消息体格式采用JSON.
l 方法的所有参数对应请求消息,返回对应响应消息.基本类型作为元素,容器类型作为对象数组
Thrift服务方法对应的uri:
1.http://host:port/{服务名}/{thrift方法名}
2.http://host:port/{服务名}/{thrift方法名}?p1=a&p2=sss
第1种无参数,所有thrift方法参数来自消息体
第2种有参数,部分或全部方法参数来自uri查询参数,可选的消息体
常见的thrift服务方法原型类型:
(1)一个结构体参数
(2)多个基本类型参数:如只有一个int参数
后者是为了简化服务定义,避免定义结构体.
这2种可满足所有应用,没有必要支持更多形式的原型。
json数据项名称与基本类型参数名,或结构体的域名称一致.
HTTP转Thrift调用
--根据uri确定服务名,方法名
--把uri查询参数+消息体表示的json数据,对应到方法参数上.
--调用thrift方法,获取返回结果
--转换thrift返回值为响应JSON消息
Thrift转HTTP请求
--根据方法生成uri:加上配置的host,port信息
--对于http方法:选择有(1)全部为POST(2)建立thrift方法与http方法的对应配置,并利用.默认:GET
--采用无参数uri
--调用HTTP
--把响应消息映射到返回值对象
Thrift调用实现参考Thrift编译生成的java代码。
3 springcloud-thrift-starter
负责:
l 向Eureka注册,提供ip,host,服务名信息,这些信息来自配置
l 提供healthCheckUrl(健康检查),statusPageUrl(服务状态)
服务引入此包,执行注册,提供健康检查和服务状态接口的实现。
4 服务间调用
遗留系统内服务之间采用Thrift调用方式:
l Java服务:
相互和调用C++,通过Eureka查找服务后执行thrift client调用,支持负载均衡。
l C++服务:
相互调用和调用Java, 现有的thrift客户端和服务端插件需要利用Eureka而非本地配置。
Java REST服务与遗留系统之间的的调用:
l Java REST服务通过Thrift调用遗留系统
l Java Thrift服务通过Feign调用Java REST服务
l C++服务通过HTTP调用Java REST服务,实现负载均衡