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服务,实现负载均衡