JavaEE相关知识和技巧概括

REST

REST详解：

• REST，表示性状态转移（representation statetransfer）。简单来说，就是用URI表示资源，用HTTP方法(GET, POST, PUT, DELETE)表征对这些资源的操作。
  ①Resource: 资源，即数据，存在互联网上的可被访问的实体
  ②Representation： 数据的某种表现形式，如HTML, JSON。
  ③State Transfer：状态变化，HTTP方法实现
• RESTful API 就是REST风格的API。现在终端平台多样，移动、平板、PC等许多媒介向服务端发送请求后，如果不适用RESTfulAPI，需要为每个平台的数据请求定义相应的返回格式，以适应前端显示。但是RESTful API要求前端以一种预定义的语法格式发送请求，那么服务端就只需要定义一个统一的响应接口，不必像之前那样解析各色各式的请求。
• RESTful 是典型的基于HTTP的协议。它有哪些设计原则和规范呢？
  ①资源。首先要明确资源就是网络上的一个实体，可以是文本、图片、音频、视频。资源总是以一定的格式来表现自己。文本用txt、html；图片用JPG、JPEG等等。而JSON是RESTful API中最常用的资源表现格式。
  ②统一接口。对于业务数据的CRUD，RESTful 用HTTP方法与之对应
  
  ③URI。统一资源标识符，它可以唯一标识一个资源。注意到，URL(统一资源定位符)是一种URI，因为它可以唯一标志资源。但URL != URI。应该说URL 是URI的子集。因为URL使用路径来唯一标识资源，这只是唯一标识资源的一种方式。还可以用一个唯一编号来标识资源，如example.html.fuce2da23。只不过这种方式并不被广泛使用。总之，要在概念上对URL和URI有所区分。
  ④无状态。 所谓无状态是指所有资源都可以用URI定位，而且这个定位与其他资源无关，不会因为其他资源的变动而变化。这里引入一个幂等性的概念：无论一个操作被执行一次还是多次，执行后的效果都相同。比如对某资源发送GET请求，如果访问一次和访问十次获得的数据一样，那么就说这个请求具有幂等性。
  ⑤URL中只能有名词，不能出现动词。这是因为在REST要求对资源的操作由HTTP 方法给出，而方法是由HTTP 请求报文头部给出的，自然不需要在URL中暴露操作方式。

RPC

RPC是什么？

• RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。
• 即程序员无论是调用本地的还是远程的，本质上编写的调用代码基本相同。
• 简单：RPC 概念的语义十分清晰和简单，这样建立分布式计算就更容易。
• 高效：过程调用看起来十分简单而且高效。
• 通用：在单机计算中过程往往是不同算法部分间最重要的通信机制。
• 通俗一点说，就是一般程序员对于本地的过程调用很熟悉，那么我们把 RPC 作成和本地调用完全类似，那么就更容易被接受，使用起来毫无障碍。
• 使用RPC的优点是不需要了解底层网络技术的协议，为通信程序之间携带信息数据。在网络通信模型中，RPC 跨越了传输层和应用层。RPC 使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC框架或方案：

• RMI（JDK自带）
  ①JDK自带的RPC
• Dubbo/ Dubbox
  ①阿里巴巴公司开源的一个Java高性能优秀的服务框架，可以和Spring框架无缝集成，相关资料很丰富。
  ②遗憾的是已经停止维护了，相关的依赖类比如Spring，Netty还是很老的版本。倒是当当网之类的再继续维维护，即Dubbox，并且实现了REST的支持。
  ③Dubbo主要实现了服务治理，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现。
  ④所以，如果选择Dubbo请务必在各个环节做好整套解决方案的准备，不然很可能随着服务数量的增长，整个团队都将疲于应付各种架构上不足引起的困难，不能让各环节人员真正的专注于业务逻辑。
  ⑤Dubbo建议使用Zookeeper作为服务的注册中心：
  <1>Zookeeper的作用：zookeeper用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是ip地址和服务名称的对应关系。
  <2>dubbo：是管理中间层的工具，在业务层到数据仓库间有非常多服务的接入和服务提供者需要调度，dubbo提供一个框架解决这个问题。
  <3>zookeeper和dubbo的关系：Dubbo的将注册中心进行抽象，是得它可以外接不同的存储媒介给注册中心提供服务，有ZooKeeper，Memcached，Redis等。
• Hessian
  ①Hessian是一个轻量级的remotingonhttp工具，使用简单的方法提供了RMI的功能。相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。
• Thrift
  ① Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。
• Motan
  ①新浪微博的服务治理框架，2016年5月开源，Motan是一个小而精的 RPC 框架，它的特点是简单、易用，是一个轻量级 RPC框架。
  ②与Dubbo相比，Motan在功能方面并没有那么全面，也没有实现特别多的扩展。用的人比较少，功能和稳定性有待观望。对跨语言调用支持较差，主要支持java。
• Spring Cloud（推荐）
  ①Spring Cloud 完全基于Spring Boot，是一个非常新的项目，2016年才 1.0 release。版本提升非常迅速，发展势头良好。
  ②Spring Cloud依然发扬了Spring Source整合一切的作风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特点，让原本复杂的架构工作变得相对容易上手一些。服务调用方式是基于REST API的。
  ③缺点是项目很年轻，很少见到国内业界有人在生产上成套使用，一般都是只有其中一两个组件。相关的技术文档大部分是英文的，案例也相对较少，使用的话需要摸索的时间会长一些。
  ④下图是Spring Cloud和Dubbo的对比：
• gRPC
  ①Google发布的开源RPC框架，高性能、开源、将移动和HTTP/2放在首位的通用的RPC框架，基于HTTP/2, netty4.1, proto3, 拥有非常丰富而实用的特性，堪称RPC 框架的典范。
  ②但它本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

实现 RPC 的程序包括 5 个部分：

• 这里 user 就是 client 端，当 user 想发起一个远程调用时，它实际是通过本地调用 user-stub。 user-stub负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPCRuntime 实例传输到远端的实例。 远端RPCRuntime 实例收到请求后交给 server-stub 进行解码后发起本地端调用，调用结果再返回给 user 端。
  ①User
  ②User-stub
  ③RPCRuntime
  ④Server-stub
  ⑤Server
  

RPC如何实现？

• RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。
• 为实现该目标，RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用， 在前文中给出了一种实现结构，基于 stub的结构来实现。
• 下面我们将具体细化 stub 结构的实现，RPC 调用分以下两种：
  ①同步调用：客户方等待调用执行完成并返回结果。
  ②异步调用：客户方调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。 若客户方不关心调用返回结果，则变成单向异步调用，单向调用不用返回结果。
  ③异步和同步的区分在于是否等待服务端执行完成并返回结果。
  

具体调用细节：

• RPC服务方通过 RpcServer 去导出（export）远程接口方法，而客户方通过RpcClient去引(import)远程接口方法。 客户方像调用本地方法一样去调用远程接口方法，RPC 框架提供接口的代理实现，实际的调用将委托给代理 RpcProxy 。代理封装调用信息并将调用转交给 RpcInvoker 去实际执行。 在客户端的 RpcInvoker 通过连接器RpcConnector 去维持与服务端的通道 RpcChannel， 并使用 RpcProtocol执行协议编码（encode）并将编码后的请求消息通过通道发送给服务方。
• RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，同样使用 RpcProtocol 执行协议解码(decode)。解码后的调用信息传递给 RpcProcessor 去控制处理调用过程，最后再委托调用给 RpcInvoker 去实际执行并返回调用结果。

总结所有角色：

1、RpcServer
负责导出（export）远程接口
2、RpcClient
负责导入（import）远程接口的代理实现
3、RpcProxy
远程接口的代理实现
4、RpcInvoker
客户方实现：负责编码调用信息和发送调用请求到服务方并等待调用结果返回
服务方实现：负责调用服务端接口的具体实现并返回调用结果
5、RpcProtocol
负责协议编/解码
6、RpcConnector
负责维持客户方和服务方的连接通道和发送数据到服务方
7、RpcAcceptor
负责接收客户方请求并返回请求结果
8、RpcProcessor
负责在服务方控制调用过程，包括管理调用线程池、超时时间等
9、RpcChannel
数据传输通道

RPC框架要做到的最基本的三件事：

• 服务端如何确定客户端要调用的函数；
  ①在远程调用中，客户端和服务端分别维护一个【ID->函数】的对应表， ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
• 如何进行序列化和反序列化；
  ①客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化，序列化和反序列化的速度也会影响远程调用的效率。
• 如何进行网络传输（选择何种网络协议）；
  ①多数RPC框架选择TCP作为传输协议，也有部分选择HTTP。如gRPC使用HTTP2。不同的协议各有利弊。TCP更加高效，而HTTP在实际应用中更加的灵活。
  

webservice和soap

webservice简述：

• 准确的来说，webservice不是一种技术，而是一种规范。是一种跨平台，跨语言的规范，用于不同平台，不同语言开发的应用之间的交互。
• WebService是个很重型的规范，它的应用协议是SOAP（简单对象访问协议）。
• 例子：
  ①比如在Windows Server服务器上有个C#.Net开发的应用A，在Linux上有个Java语言开发的应用B，现在B应用要调用A应用，或者是互相调用，用于查看对方的业务数据，就需要webservice的规范。
  ②天气预报接口。无数的应用需要获取天气预报信息，这些应用可能是各种平台，各种技术实现，而气象局的项目，估计也就一两种，要对外提供天气预报信息，这个时候，如何解决呢？webservice就是出于以上类似需求而定义出来的规范。
• 我们一般就是在具体平台开发webservice接口，以及调用webservice接口，每种开发语言都有自己的webservice实现框架。
  ①比如Java就有 Apache Axis1、Apache Axis2、Codehaus XFire、Apache CXF、Apache Wink、Jboss RESTEasyd等等。其中Apache CXF用的比较多，它也可以和Spring整合。
• 链接：为什么现在流行resultful,webservice无人问津?

SOAP协议：

• SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在WebService中把远程调用和返回封装成机器可读的格式化数据。
• 事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。
• 另一方面，各个服务器都可以基于这个协议推出自己的API，即使它们提供的服务及其相似，定义的API也不尽相同，这又导致了WSDL的诞生。
• WSDL (Web Service Description Language)也遵循XML格式，用来描述哪个服务器提供什么服务，怎样找到它，以及该服务使用怎样的接口规范，简言之，服务发现。现在，使用WebService的过程变成，获得该服务的WSDL描述，根据WSDL构造一条格式化的SOAP请求发送给服务器，然后接收一条同样SOAP格式的应答，最后根据先前的WSDL解码数据。绝大多数情况下，请求和应答使用HTTP协议传输，那么发送请求就使用HTTP的POST方法。

REST与RPC与SOAP

REST与RPC区别：

• REST与RPC都是网络交互的协议规范。通常用于多个微服务之间的通信协议。

协议规范	通信协议	性能	灵活度
REST	HTTP	低	高
RPC	一般使用TCP	高	低

• HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。
  ①我们通过浏览器访问网站&