超级详细通信协议解析webservice和dubbo通信协议区别

　　简单说下接触webservice的背景吧，因为之前的接口对接更多的是成熟的接口品牌像是阿里巴巴、腾讯、聚合数据等，他们接口规范一般都是基于restful进行接口对接。什么是restful接口，可以通过这篇文章了解《简单易懂的restful接口规范》。言归正传，就是当下的项目中因为对接保险公司一些业务，所以对接的协议是通过web service进行对接，我认为，是很old的技术，但是对于我来说挺新的知识。正如简单描述可知，目前对于web service的通信协议其实越来越少了，不排除有一些比较喜欢老技术的公司，继续沿用这种方式，至于为什么，在下面文章中详细阐述。

　　什么是web service？怎么进行web service协议接口调用？web service和其他通信协议像是dubbo、hessian、RMI、thrif区别在哪里？下面标题解答：

一 什么是web service?

　　首先，web service是一种接口远程对接协议，通过这种协议编写的接口能跨平台和跨语言，跨项目，也就是一处编写部署，其他处处调用。对于项目开发中不建议使用，对外项目研发中，可以使用。早先的传输方式通过SOAP协议，然后通过WSDL（web service description language）web服务描述语言展示，这种方式就是我们公司才用的方式，比较old的一种方式，最新的方式是遵循RESTful规则，通过最简单的 http 协议传输数据 ( 包括 xml 或 json) ，既简化了设计，也减少了网络传输量（因为只传输代表数据的 xml 或 json ，没有额外的 xml 包装）。

web service相对http (post/get)有好处吗？

　　1.接口中实现的方法和要求参数一目了然,通过WSDL可以查询,具体想学习WSDL可以参考这篇文章《简单易懂的restful接口规范》如下图所示:

　　

　　　 调用测试WSDL的网址，可以通过 http://www.webxml.com.cn/zh_cn/web_services.aspx
        2.不用担心大小写问题（这里说的大小写问题，是对于输入的参数值，不需要注意大小写）

3.不用担心中文urlencode问题

4.代码中不用多次声明认证(账号,密码)参数

5.传递参数可以为数组，对象等...（因为是基于SOAP对象传输协议，所以XML能容纳一切）

web service相对http（post/get）快吗？

        由于要进行xml解析，速度可能会有所降低。调用接口时候，需要转换为XML对象，接收接口时候，需要通过把XML文件转为对象。

  XStreamUtils.xmltoBean(result, ReturnInfo.class);

web service 可以被http（post/get）替代吗？

        完全可以，而且现在的开放平台都是用的HTTP（post/get）实现的。

二 怎么进行web service协议接口调用？

　　1、对于web service接口的调用，传统代码调用方式：

			Call call = (Call) service.createCall();
			String path = bean.getPath();
			String nameSpace = bean.getNameSpace();
			call.setTargetEndpointAddress(path);
			QName qName = new QName(nameSpace, "testService");
			call.setOperationName(qName);
			call.setUseSOAPAction(true);
			call.addParameter("param1", XMLType.XSD_STRING, ParameterMode.IN);
			call.addParameter("param1", XMLType.XSD_STRING, ParameterMode.IN);
			call.setReturnType(XMLType.XSD_STRING);
			result = (String) call.invoke(new Object[] { "001001", xml });

　　2、推荐一个超级强大的工具类，https://hutool.cn/docs/#/

import cn.hutool.http.webservice.SoapClient;

/**
 * @author admin
 * @date 2019/11/29 13:55
 */
public class Test {

    public static final String url1 = "http://www.webxml.com.cn/WebServices/IpAddressSearchWebService.asmx";
    public static final String url2 = "http://ws.webxml.com.cn/WebServices/MobileCodeWS.asmx?wsdl";
    public static final String url3 = "http://ws.webxml.com.cn/WebServices/TrainTimeWebService.asmx?wsdl";
    public static final String url4 = "http://fy.webxml.com.cn/webservices/EnglishChinese.asmx?wsdl";

    public static void main(String[] args) {

        String message = "";
//        message = getMobileAddress();
        message = getChinese();
        System.out.println(message);
    }

    /**
     * 中文翻译
     */
    public static String getChinese() {

        // 新建客户端
        SoapClient client = SoapClient.create(url4)
                // 设置要请求的方法，此接口方法前缀为web，传入对应的命名空间
                .setMethod("web:TranslatorString", "http://WebXml.com.cn/")
                // 设置参数，此处自动添加方法的前缀：web
                .setParam("wordKey", "make MONEY");

        // 发送请求，参数true表示返回一个格式化后的XML内容
        // 返回内容为XML字符串，可以配合XmlUtil解析这个响应
        return client.send(true);
    }

}

三 web service和其他通信协议像是dubbo、hessian、RMI、thrif区别在哪里？

1、dubbo传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串

为什么要消费者比提供者个数多：
因dubbo协议采用单一长连接，
假设网络为千兆网卡(1024Mbit=128MByte)，
根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样，供参考)，
理论上1个服务提供者需要20个服务消费者才能压满网卡。

为什么不能传大包：
因dubbo协议采用单一长连接，
如果每次请求的数据包大小为500KByte，假设网络为千兆网卡(1024Mbit=128MByte)，每条连接最大7MByte(不同的环境可能不一样，供参考)，
单个服务提供者的TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。
单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14。
如果能接受，可以考虑使用，否则网络将成为瓶颈。

为什么采用异步单一长连接：
因为服务的现状大都是服务提供者少，通常只有几台机器，
而服务的消费者多，可能整个网站都在访问该服务，
比如Morgan的提供者只有6台提供者，却有上百台消费者，每天有1.5亿次调用，
如果采用常规的hessian服务，服务提供者很容易就被压跨，
通过单一连接，保证单一消费者不会压死提供者，
长连接，减少连接握手验证等，
并使用异步IO，复用线程池，防止C10K问题。

2、RMI

　　RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式

3、Hessian协议

　　Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现

4、http

　　采用Spring的HttpInvoker实现

5、thrif

　　Thrift是Facebook捐给Apache的一个RPC框架，当前 dubbo 支持的 thrift 协议是对 thrift 原生协议的扩展，在原生协议的基础上添加了一些额外的头信息，比如service name，magic number等。

参考文章
https://www.cnblogs.com/h-c-g/p/10870913.html
https://blog.csdn.net/zh521zh/article/details/76445520https://blog.csdn.net/f1ame1/article/details/80506929