RPC框架的feign重试机制中的坑

					微服务远程调用rpc框架

feign的生产者,同是RPC框架的feign,与dubbo相比, 更加小.占用资源少.
feign在远程调用时,如果是post调用方式,传入实体有可能会出现参数丢失的问题,
解决办法: 一种是自定义自定义encoder类QueryPostMapEncoder，将参数全部拼进body里面去，不采用Content-Type: application/json 参数的形式
public class QueryPostMapEncoder implements Encoder {

private String secret;

public QueryPostMapEncoder(String secret) {
    this.secret = secret;
}

@Override
public void encode(Object o, Type type, RequestTemplate requestTemplate) throws EncodeException {
    try {
        Map<String,String> params = ObjectUtils.objectToMapString(o);;
        String sign = SignUtil.sign(params,this.secret);
        requestTemplate.query("sign",sign);

        StringBuilder sb = new StringBuilder();
        sb.append("sign=");
        sb.append(sign);
        for (Map.Entry<String,String> param:params.entrySet()){
            if (param.getValue()!=null) {
                sb.append("&");
                sb.append(param.getKey());
                sb.append("=");
                sb.append(param.getValue());
            }
        }
        requestTemplate.body(sb.toString());
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

}

第二种方式:实体前加入@RequestBody

feign的重试机制
1 超时,无法避免的痛
HTTP调用即通过HTTP协议执行一次网络请求。既然是网络请求，就有超时的可能性（可能你的网卡，也可能服务器所处网络卡），因此在开发中需要注意：
框架设置的默认超时时间是否合理
过短，请求还未处理完成，你就急不可待了！
过长，请求早已超出正常响应时间而挂了
考虑网络不稳定性，超时后可以通过定时任务请求重试
注意考虑服务端接口幂等性设计，即是否允许重试
考虑框架是否会像浏览器那样限制并发连接数，以免在高并发下，HTTP调用的并发数成为瓶颈
1.1 HTTP调用框架技术选型
Spring Cloud全家桶
使用Feign进行声明式的服务调用。
只使用Spring Boot
HTTP客户端Apache HttpClient进行服务调用。
1.2 连接超时配置 && 读取超时参数
虽然应用层是HTTP协议，但网络层始终是TCP/IP协议。TCP/IP是面向连接的协议，在传输数据之前需要建立连接。所以网络框架都会提供如下超时参数：

连接超时参数ConnectTimeout
可自定义配置的建立连接最长等待时间
读取超时参数ReadTimeout
控制从Socket上读取数据的最长等待时间。
1.3 常见踩坑点
连接超时配置过长
比如60s。TCP三次握手正常建立连接所需时间很短，在ms级最多到s级，不可能需要十几、几十秒，多半是网络或防火墙配置问题。这时如果几秒还连不上，那么可能永远也连不上。所以设置特别长的连接超时无意义，1~5秒即可。
如果是纯内网调用，还可以设更短，在下游服务无法连接时，快速失败
无脑排查连接超时问题
服务