12.5. REST 支持

附注：我们将这个功能称之为REST风格的远程调用，即RESTFul Remoting（抽象的远程处理或者调用），而不是叫RESTFul RPC（具体的远程“过程”调用），是因为REST和RPC本身可以被认为是两种不同的风格。在dubbo的REST实现中，可以说有两个面向，其一是提供或消费正常的REST服务，其二是将REST作为dubbo RPC体系中一种协议实现，而RESTFul Remoting同时涵盖了这两个面向。

• 可更高效利用缓存来提高响应速度
• 通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
• 浏览器即可作为客户端，简化软件需求
• 相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
• 不需要额外的资源发现机制
• 在软件技术演进中的长期的兼容性更好

1. 显著简化企业内部的异构系统之间的（跨语言）调用。此处主要针对这种场景：dubbo的系统做服务提供端，其他语言的系统（也包括某些不基于dubbo的Java系统）做服务消费端，两者通过HTTP和文本消息进行通信。即使相比Thrift、Protobuf等二进制跨语言调用方案，REST也有自己独特的优势（详见后面讨论）
2. 显著简化对外Open API（开放平台）的开发。既可以用dubbo来开发专门的Open API应用，也可以将原内部使用的dubbo service直接“透明”发布为对外的Open REST API（当然dubbo本身未来最好可以较透明的提供诸如权限控制、频次控制、计费等诸多功能）
3. 显著简化手机（平板）APP或者PC桌面客户端开发。类似于2，既可以用dubbo来开发专门针对无线或者桌面的服务器端，也可以将原内部使用的dubbo service直接”透明“的暴露给手机APP或桌面程序。当然在有些项目中，手机或桌面程序也可以直接访问以上场景2中所述的Open API。
4. 显著简化浏览器AJAX应用的开发。类似于2，既可以用dubbo来开发专门的AJAX服务器端，也可以将原内部使用的dubbo service直接”透明“的暴露给浏览器中JavaScript。当然，很多AJAX应用更适合与Web框架协同工作，所以直接访问dubbo service在很多Web项目中未必是一种非常优雅的架构。
5. 为企业内部的dubbo系统之间（即服务提供端和消费端都是基于dubbo的系统）提供一种基于文本的、易读的远程调用方式。
6. 一定程度简化dubbo系统对其它异构系统的调用。可以用类似dubbo的简便方式“透明”的调用非dubbo系统提供的REST服务（不管服务提供端是在企业内部还是外部）

• 首先，开发服务的接口：

  public interface UserService {  
     void registerUser(User user);
  }
  

• 然后，开发服务的实现：

  @Path("users")
  public class UserServiceImpl implements UserService {
      @POST
      @Path("register")
      @Consumes({MediaType.APPLICATION_JSON})
      public void registerUser(User user) {
          // save the user...
      }
  }
  

• 上面的服务实现代码非常简单，但是由于REST服务是要被发布到特定HTTP URL，供任意语言客户端甚至浏览器来访问，所以这里要额外添加了几个JAX-RS的标准annotation来做相关的配置：
• @Path(“users”)：指定访问UserService的URL相对路径是/users，即http://localhost:8080/users
• @Path(“register”)：指定访问registerUser()方法的URL相对路径是/register，再结合上一个@Path为UserService指定的路径，则调用UserService.register()的完整路径为http://localhost:8080/users/register
• @POST：指定访问registerUser()用HTTP POST方法
• @Consumes({MediaType.APPLICATION_JSON})：指定registerUser()接收JSON格式的数据。REST框架会自动将JSON数据反序列化为User对象
• 最后，在Spring配置文件中添加此服务，即完成所有服务开发工作：

  <!-- 用rest协议在8080端口暴露服务 -->
  <dubbo:protocol name="rest" port="8080"/>
  <!-- 声明需要暴露的服务接口 -->
  <dubbo:service interface="xxx.UserService" ref="userService"/>
  <!-- 和本地bean一样实现服务 -->
  <bean id="userService" class="xxx.UserServiceImpl" />
  

• Oracle官方的tutorial：http://docs.oracle.com/javaee/7/tutorial/doc/jaxrs.htm
• IBM developerWorks中国站文章：http://www.ibm.com/developerworks/cn/java/j-lo-jaxrs/

注意：dubbo是基于JAX-RS 2.0版本的，有时候需要注意一下资料或REST实现所涉及的版本。

http://localhost:8080/users/1001
http://localhost:8080/users/1002
http://localhost:8080/users/1003

@GET
@Path("{id : \\d+}")
@Produces({MediaType.APPLICATION_JSON})
public User getUser(@PathParam("id") Long id) {
    // ...
}

• @GET：指定用HTTP GET方法访问
• @Path(“{id : \d+}”)：根据上面的功能需求，访问getUser()的URL应当是“http://localhost:8080/users/ + 任意数字”，并且这个数字要被做为参数传入getUser()方法。 这里的annotation配置中，@Path中间的{id: xxx}指定URL相对路径中包含了名为id参数，而它的值也将被自动传递给下面用@PathParam(“id”)修饰的方法参数id。{id:后面紧跟的\d+是一个正则表达式，指定了id参数必须是数字。
• @Produces({MediaType.APPLICATION_JSON})：指定getUser()输出JSON格式的数据。框架会自动将User对象序列化为JSON数据。

@Path("users")
public interface UserService {
    @GET
    @Path("{id : \\d+}")
    @Produces({MediaType.APPLICATION_JSON})
    User getUser(@PathParam("id") Long id);
}

@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
User getUser(@PathParam("id") Long id);

@Produces({"application/json", "text/xml"})
User getUser(@PathParam("id") Long id);

@Path("users")
@Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
public class UserServiceImpl implements UserService {
    // ...
}

注意：这里要支持XML格式数据，在annotation中既可以用MediaType.TEXT_XML，也可以用MediaType.APPLICATION_XML，但是TEXT_XML是更常用的，并且如果要利用上述的URL后缀方式来指定数据格式，只能配置为TEXT_XML才能生效。

@Produces({"application/json; charset=UTF-8", "text/xml; charset=UTF-8"})
User getUser(@PathParam("id") Long id);

@Produces({ContentType.APPLICATION_JSON_UTF_8, ContentType.TEXT_XML_UTF_8})
User getUser(@PathParam("id") Long id);

@XmlRootElement
public class User implements Serializable {
    // ...
}

• 由于primitive类型不被JAXB序列化支持，所以添加一个wrapper对象：

  @XmlRootElement
  public class RegistrationResult implements Serializable {
      private Long id;
      public RegistrationResult() {
      }
      public RegistrationResult(Long id) {
          this.id = id;
      }
      public Long getId() {
          return id;
      }
      public void setId(Long id) {
          this.id = id;
      }
  }
  

• 并修改service方法：

  RegistrationResult registerUser(User user);
  

• 这样不但能够解决XML序列化的问题，而且使得返回的数据都符合XML和JSON的规范。例如，在JSON中，返回的将是如下形式：

  {"id": 1001}
  

• 如果不加wrapper，JSON返回值将直接是 1001
• 而在XML中，加wrapper后返回值将是：

  <registrationResult>
      <id>1002</id>
  </registrationResult>
  

• 例如，定制对象属性映射到XML元素的名字：

  @XmlRootElement
  @XmlAccessorType(XmlAccessType.FIELD)
  public class User implements Serializable {
      @XmlElement(name="username") 
      private String name;  
  }
  

• 定制对象属性映射到JSON字段的名字：

  public class User implements Serializable {
      @JsonProperty("username")
      private String name;
  }
  

<dubbo:protocol name="rest" server="jetty"/>

<dubbo:protocol name="rest" server="tomcat"/>

<dubbo:protocol name="rest" server="netty"/>

<dubbo:protocol name="rest" server="tjws"/> (tjws is now deprecated)
<dubbo:protocol name="rest" server="sunhttp"/>

• 如果你的dubbo系统不是单独启动的进程，而是部署到了Java应用服务器中，则建议你采用以下配置：

  <dubbo:protocol name="rest" server="servlet"/>
  

• 通过将server设置为servlet，dubbo将采用外部应用服务器的servlet容器来做rest server。同时，还要在dubbo系统的web.xml中添加如下配置：

  <web-app>
      <context-param>
          <param-name>contextConfigLocation</param-name>
          <param-value>/WEB-INF/classes/META-INF/spring/dubbo-demo-provider.xml</param-value>
      </context-param>
      <listener>
          <listener-class>org.apache.dubbo.remoting.http.servlet.BootstrapListener</listener-class>
      </listener>
      <listener>
          <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
      </listener>
      <servlet>
          <servlet-name>dispatcher</servlet-name>
          <servlet-class>org.apache.dubbo.remoting.http.servlet.DispatcherServlet</servlet-class>
          <load-on-startup>1</load-on-startup>
      </servlet>
      <servlet-mapping>
          <servlet-name>dispatcher</servlet-name>
          <url-pattern>/*</url-pattern>
      </servlet-mapping>
  </web-app>
  

注意：如果你是用Spring的ContextLoaderListener来加载Spring，则必须保证BootstrapListener配置在ContextLoaderListener之前，否则dubbo初始化会出错。

• 第一种方式，用JAX-RS标准的@Context annotation：

  public User getUser(@PathParam("id") Long id, @Context HttpServletRequest request) {
      System.out.println("Client address is " + request.getRemoteAddr());
  }
  

• 用Context修饰getUser()的一个方法参数后，就可以将当前的HttpServletRequest注入进来，然后直接调用servlet API获取IP。

• 注意：这种方式只能在设置server=“tjws”或者server=“Tomcat”或者server=“Jetty”或者server=“servlet”的时候才能工作，因为只有这几种REST server的实现才提供了servlet容器。另外，标准的JAX-RS还支持用@Context修饰service类的一个实例字段来获取HttpServletRequest，但在dubbo中我们没有对此作出支持。

• 第二种方式，用dubbo中常用的RpcContext：

  public User getUser(@PathParam("id") Long id) {
      System.out.println("Client address is " + RpcContext.getContext().getRemoteAddressString());
  }
  

• 注意：这种方式只能在设置server=“Jetty”或者server=“Tomcat”或者server=“servlet”或者server=“tjws”的时候才能工作。另外，目前dubbo的RpcContext是一种比较有侵入性的用法，未来我们很可能会做出重构。

if (RpcContext.getContext().getRequest() != null && RpcContext.getContext().getRequest() instanceof HttpServletRequest) {
    System.out.println("Client address is " + ((HttpServletRequest) RpcContext.getContext().getRequest()).getRemoteAddr());
}
if (RpcContext.getContext().getResponse() != null && RpcContext.getContext().getResponse() instanceof HttpServletResponse) {
    System.out.println("Response object from RpcContext: " + RpcContext.getContext().getResponse());
}

注意：为了保持协议的中立性，RpcContext.getRequest()和RpcContext.getResponse()返回的仅仅是一个Object类，而且可能为null。所以，你必须自己做null和类型的检查。

注意：只有在设置server=“Jetty”或者server=“Tomcat”或者server=“servlet”的时候，你才能通过以上方法正确的得到HttpServletRequest和HttpServletResponse，因为只有这几种server实现了servlet容器。

if (RpcContext.getContext().getRequest(HttpServletRequest.class) != null) {
    System.out.println("Client address is " + RpcContext.getContext().getRequest(HttpServletRequest.class).getRemoteAddr());
}
if (RpcContext.getContext().getResponse(HttpServletResponse.class) != null) {
    System.out.println("Response object from RpcContext: " + RpcContext.getContext().getResponse(HttpServletResponse.class));
}

• dubbo中的rest协议默认将采用80端口，如果想修改端口，直接配置：

  <dubbo:protocol name="rest" port="8888"/>
  

• 只需要添加如下contextpath属性即可：

  <dubbo:protocol name="rest" port="8888" contextpath="services"/>
  

• 以前面代码为例：

  @Path("users")
  public class UserServiceImpl implements UserService {
      @POST
      @Path("register")
      @Consumes({MediaType.APPLICATION_JSON})
      public void registerUser(User user) {
          // save the user...
      }  
  }
  

• 现在registerUser()的完整访问路径为：http://localhost:8888/services/users/register
• 注意：如果你是选用外部应用服务器做rest server，即配置:

  <dubbo:protocol name="rest" port="8888" contextpath="services" server="servlet"/>
  

• 则必须保证这里设置的port、contextpath，与外部应用服务器的端口、DispatcherServlet的上下文路径（即webapp path加上servlet url pattern）保持一致。例如，对于部署为Tomcat ROOT路径的应用，这里的contextpath必须与web.xml中DispacherServlet的<url-pattern/>完全一致：

  <servlet-mapping>
       <servlet-name>dispatcher</servlet-name>
       <url-pattern>/services/*</url-pattern>
  </servlet-mapping>
  

• 可以为rest服务配置线程池大小：

  <dubbo:protocol name="rest" threads="500"/>
  

• 注意：目前线程池的设置只有当server=“Netty”或者server=“Jetty”或者server=“Tomcat”的时候才能生效。另外，如果server=“servlet”，由于这时候启用的是外部应用服务器做rest server，不受dubbo控制，所以这里的线程池设置也无效。

• 如果是选用Netty server，还可以配置Netty的IO worker线程数：

  <dubbo:protocol name="rest" iothreads="5" threads="100"/>
  

• Dubbo中的rest服务默认都是采用http长连接来访问，如果想切换为短连接，直接配置：

  <dubbo:protocol name="rest" keepalive="false"/>
  

• 注意：这个配置目前只对server=“Netty”和server=“Tomcat”才能生效。

• 可以配置服务器提供端所能同时接收的最大HTTP连接数，防止REST server被过多连接撑爆，以作为一种最基本的自我保护机制：

  <dubbo:protocol name="rest" accepts="500" server="tomcat/>
  

• 注意：这个配置目前只对server=“Tomcat”才能生效。

• 如果rest服务的消费端也是dubbo系统，可以像其他dubbo RPC机制一样，配置消费端调用此rest服务的最大超时时间以及每个消费端所能启动的最大HTTP连接数。

  <dubbo:service interface="xxx" ref="xxx" protocol="rest" timeout="2000" connections="10"/>
  

• 当然，由于这个配置针对消费端生效的，所以也可以在消费端配置：

  <dubbo:reference id="xxx" interface="xxx" timeout="2000" connections="10"/>
  

注意：如果dubbo的REST服务是发布给非dubbo的客户端使用，则这里<dubbo:service/>上的配置完全无效，因为这种客户端不受dubbo控制。

@Service(protocol = "rest")
@Path("users")
public class UserServiceImpl implements UserService {
    @Autowired
    private UserRepository userRepository;
    @POST
    @Path("register")
    @Consumes({MediaType.APPLICATION_JSON})
    public void registerUser(User user) {
        // save the user
        userRepository.save(user);
    }  
}

• 其中，Filter主要用于访问和设置HTTP请求和响应的参数、URI等等。例如，设置HTTP响应的cache header：

  public class CacheControlFilter implements ContainerResponseFilter {
      public void filter(ContainerRequestContext req, ContainerResponseContext res) {
          if (req.getMethod().equals("GET")) {
              res.getHeaders().add("Cache-Control", "someValue");
          }
      }
  }
  

• Interceptor主要用于访问和修改输入与输出字节流，例如，手动添加GZIP压缩：

  public class GZIPWriterInterceptor implements WriterInterceptor {
      @Override
      public void aroundWriteTo(WriterInterceptorContext context)
                      throws IOException, WebApplicationException {
          OutputStream outputStream = context.getOutputStream();
          context.setOutputStream(new GZIPOutputStream(outputStream));
          context.proceed();
      }
  }
  

• 在标准JAX-RS应用中，我们一般是为Filter和Interceptor添加@Provider annotation，然后JAX-RS runtime会自动发现并启用它们。而在dubbo中，我们是通过添加XML配置的方式来注册Filter和Interceptor：

  <dubbo:protocol name="rest" port="8888" extension="xxx.TraceInterceptor, xxx.TraceFilter"/>
  

注：这里的XML属性叫extension，而不是叫interceptor或者filter，是因为除了Interceptor和Filter，未来我们还会添加更多的扩展类型。

public class LoggingFilter implements ClientResponseFilter {
    public void filter(ClientRequestContext reqCtx, ClientResponseContext resCtx) throws IOException {
        System.out.println("status: " + resCtx.getStatus());
        System.out.println("date: " + resCtx.getDate());
        System.out.println("last-modified: " + resCtx.getLastModified());
        System.out.println("location: " + resCtx.getLocation());
        System.out.println("headers:");
        for (Entry<String, List<String>> header : resCtx.getHeaders().entrySet()) {
             System.out.print("\t" + header.getKey() + " :");
            for (String value : header.getValue()) {
                System.out.print(value + ", ");
            }
            System.out.print("\n");
        }
        System.out.println("media-type: " + resCtx.getMediaType().getType());
    } 
}

public class CustomExceptionMapper implements ExceptionMapper<NotFoundException> {
    public Response toResponse(NotFoundException e) {   
        return Response.status(Response.Status.NOT_FOUND).entity("Oops! the requested resource is not found!").type("text/plain").build();
    }
}

• 和Interceptor、Filter类似，将其添加到XML配置文件中即可启用：

  <dubbo:protocol name="rest" port="8888" extension="xxx.CustomExceptionMapper"/>
  

• 在XML配置中添加如下自带的REST filter：

  <dubbo:protocol name="rest" port="8888" extension="org.apache.dubbo.rpc.protocol.rest.support.LoggingFilter"/>
  

• 然后在logging配置中至少为org.apache.dubbo.rpc.protocol.rest.support打开INFO级别日志输出 ，例如，在log4j.xml中配置：

  <logger name="org.apache.dubbo.rpc.protocol.rest.support">
      <level value="INFO"/>
      <appender-ref ref="CONSOLE"/>
  </logger>
  

• 当然，你也可以直接在ROOT logger打开INFO级别日志输出：

  <root>
      <level value="INFO" />
      <appender-ref ref="CONSOLE"/>
  </root>
  

• 然后在日志中会有类似如下的内容输出：

  The HTTP headers are: 
  accept: application/json;charset=UTF-8
  accept-encoding: gzip, deflate
  connection: Keep-Alive
  content-length: 22
  content-type: application/json
  host: 192.168.1.100:8888
  user-agent: Apache-HttpClient/4.2.1 (java 1.5)
  

  The contents of request body is: 
  {"id":1,"name":"dang"}
  

• 为了和其他dubbo远程调用协议保持一致，在rest中作校验的annotation必须放在服务的接口上，例如：

  public interface UserService {
      User getUser(@Min(value=1L, message="User ID must be greater than 1") Long id);
  }
  

• 然后按照dubbo的标准方式在XML配置中打开验证：

  <dubbo:service interface=xxx.UserService" ref="userService" protocol="rest" validation="true"/>
  

• 在dubbo的其他很多远程调用协议中，如果输入验证出错，是直接将RpcException抛向客户端，而在rest中由于客户端经常是非dubbo，甚至非Java的系统，所以不便直接抛出Java异常。因此，目前我们将校验错误以XML的格式返回：

  <violationReport>
      <constraintViolations>
          <path>getUserArgument0</path>
          <message>User ID must be greater than 1</message>
          <value>0</value>
      </constraintViolations>
  </violationReport>
  

public class MyValidationExceptionMapper extends RpcExceptionMapper {
    protected Response handleConstraintViolationException(ConstraintViolationException cve) {
        ViolationReport report = new ViolationReport();
        for (ConstraintViolation cv : cve.getConstraintViolations()) {
            report.addConstraintViolation(new RestConstraintViolation(
                    cv.getPropertyPath().toString(),
                    cv.getMessage(),
                    cv.getInvalidValue() == null ? "null" : cv.getInvalidValue().toString()));
        }
        // 采用json输出代替xml输出
        return Response.status(Response.Status.INTERNAL_SERVER_ERROR).entity(report).type(ContentType.APPLICATION_JSON_UTF_8).build();
    }
}

• 然后将这个ExceptionMapper添加到XML配置中即可：

  <dubbo:protocol name="rest" port="8888" extension="xxx.MyValidationExceptionMapper"/>
  

• Dubbo通过RpcContextFilter将header取出分解之后设置到RpcContext的attachments，所以在提供端可以直接从RpcContext的attachments中获取到消费端设置的header信息：

      RpcContext.getContext().getAttachment(key1)
      RpcContext.getContext().getAttachment(key2)
  

1. 非dubbo的消费端调用dubbo的REST服务（non-dubbo –> dubbo）
2. dubbo消费端调用dubbo的REST服务 （dubbo –> dubbo）
3. dubbo的消费端调用非dubbo的REST服务 （dubbo –> non-dubbo）

User user = new User();
user.setName("Larry");
Client client = ClientBuilder.newClient();
WebTarget target = client.target("http://localhost:8080/services/users/register.json");
Response response = target.request().post(Entity.entity(user, MediaType.APPLICATION_JSON_TYPE));
try {
    if (response.getStatus() != 200) {
        throw new RuntimeException("Failed with HTTP error code : " + response.getStatus());
    }
    System.out.println("The generated id is " + response.readEntity(RegistrationResult.class).getId());
} finally {
    response.close();
    client.close(); // 在真正开发中不要每次关闭client，比如HTTP长连接是由client持有的
}

<dubbo:reference id="userService" interface="xxx.UserService"/>

@Path("users")
public interface UserService {
    @GET
    @Path("{id : \\d+}")
    @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
    User getUser(@PathParam("id") Long id);
}

• 例如，我们要调用如下的外部服务

  http://api.foo.com/services/users/1001
  http://api.foo.com/services/users/1002
  

• 获取不同ID的用户资料，返回格式是JSON

  {
      "id": 1001,
      "name": "Larry"
  }
  

• 我们可根据这些信息，编写服务接口和参数类即可：

  @Path("users")
  public interface UserService {
      @GET
      @Path("{id : \\d+}")
      @Produces({MediaType.APPLICATION_JSON})
      User getUser(@PathParam("id") Long id);
  }
  

  public class User implements Serializable {
      private Long id;
      private String name;
      // …
  }
  

<dubbo:reference id="userService" interface="xxx.UserService" url="rest://api.foo.com/services/"/>

注意：这里协议必须用rest://而不是http://之类。如果外部的REST服务有context path，则在url中也必须添加上（除非你在每个服务接口的@Path annotation中都带上context path），例如上面的/services/。同时这里的services后面必须带上/，这样才能使dubbo正常工作。

• 另外，这里依然可以配置客户端可启动的最大连接数和超时时间：

  <dubbo:reference id="userService" interface="xxx.UserService" url="rest://api.foo.com/services/" timeout="2000" connections="10"/>
  

• Dubbo进行rest调用的时候，采用的是将RpcContext的attachment转换为header的方式，所以，dubbo消费端可以按以下方式进行自定义header的设置：

      RpcContext.getContext().setAttachment("key1", "value1");
      RpcContext.getContext().setAttachment("key2", "value2");
  

• 即可设置如下格式的header:

      key1=value1
      key2=value2
  

1. 服务实现只能是singleton的，不能支持per-request scope和per-lookup scope
2. 不支持用@Context annotation对服务的实例字段注入 ServletConfig、ServletContext、HttpServletRequest、HttpServletResponse等等，但可以支持对服务方法参数的注入。但对某些特定REST server实现，（祥见前面的叙述），也不支持对服务方法参数的注入。

• 可以的，而且是自动集成的，也就是你在dubbo中开发的所有REST服务都会自动注册到注册中心和监控中心，可以通过它们做管理。
• 但是，只有当REST的消费端也是基于dubbo的时候，注册中心中的许多服务治理操作才能完全起作用。而如果消费端是非dubbo的，自然不受注册中心管理，所以其中很多操作是不会对消费端起作用的。

• 如果dubbo REST的消费端也是dubbo的，则Dubbo REST和其他dubbo远程调用协议基本完全一样，由dubbo框架透明的在消费端做load balance、failover等等。
• 如果dubbo REST的消费端是非dubbo的，甚至是非Java的，则最好配置服务提供端的软负载均衡机制，目前可考虑用LVS、HAProxy、 Nginx等等对HTTP请求做负载均衡。

• http://stackoverflow.com/questions/17196766/can-resteasy-choose-method-based-on-query-params

• http://stackoverflow.com/questions/5553218/jax-rs-post-multiple-objects

• dubbo支持多种远程调用方式，但所有调用方式都是用<dubbo:protocol/>来配置的，例如：

  <dubbo:protocol name="dubbo" port="9090" server="netty" client="netty" codec="dubbo" serialization="hessian2" 
      charset="UTF-8" threadpool="fixed" threads="100" queues="0" iothreads="9" buffer="8192" accepts="1000" payload="8388608"/>
  

<dubbo:protocol-rest port="8080">
    <dubbo:extension>someInterceptor</dubbo:extension>
    <dubbo:extension>someFilter</dubbo:extension>
    <dubbo:extension>someDynamicFeature</dubbo:extension>
    <dubbo:extension>someEntityProvider</dubbo:extension>
</dubbo:protocol-rest>

• dubbo的XML配置中大量命名都不符合Spring规范，比如：

  <dubbo:protocol name="dubbo" port="9090" server="netty" client="netty" codec="dubbo" serialization="hessian2" 
      charset="UTF-8" threadpool="fixed" threads="100" queues="0" iothreads="9" buffer="8192" accepts="1000" payload="8388608"/>
  

• 两台独立服务器
• 4核Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz
• 8G内存
• 服务器之间网络通过百兆交换机
• CentOS 5
• JDK 7
• Tomcat 7
• JVM参数-server -Xms1g -Xmx1g -XX:PermSize=64M -XX:+UseConcMarkSweepGC

• 传入嵌套复杂对象（但单个数据量很小），不做任何处理，原样返回
• 传入50K字符串，不做任何处理，原样返回（TODO：结果尚未列出）

• “REST: Jetty + XML + GZIP”的意思是：测试REST，并采用Jetty server，XML数据格式，启用GZIP压缩。
• “Dubbo: hessian2”的意思是：测试dubbo RPC，并采用hessian2序列化方式。

• dubbo RPC（特别是基于高效Java序列化方式如kryo，fst）比REST的响应时间和吞吐量都有较显著优势，内网的dubbo系统之间优先选择dubbo RPC。
• 在REST的实现选择上，仅就性能而言，目前tomcat7和Netty最优（当然目前使用的Jetty和Netty版本都较低）。tjws和sun http server在性能测试中表现极差，平均响应时间超过200ms，平均tps只有50左右（为了避免影响图片效果，没在上面列出）。
• 在REST中JSON数据格式性能优于XML（数据暂未在以上列出）。
• 在REST中启用GZIP对企业内网中的小数据量复杂对象帮助不大，性能反而有下降（数据暂未在以上列出）。

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
               connectionTimeout="20000"
               redirectPort="8443"
               minSpareThreads="20"
               enableLookups="false"
               maxThreads="100"
               maxKeepAliveRequests="-1"
               keepAliveTimeout="60000"/>

谢谢，对于jax-rs和Spring mvc，其实我对Spring mvc的rest支持还没有太深入的看过，说点初步想法，请大家指正：

Spring mvc也支持annotation的配置，其实和jax-rs看起来是非常非常类似的。

我个人认为Spring mvc相对更适合于面向Web应用的RESTFul服务，比如被AJAX调用，也可能输出HTML之类的，应用中还有页面跳转流程之类，Spring mvc既可以做好正常的Web页面请求也可以同时处理rest请求。但总的来说这个RESTFul服务是在展现层或者叫Web层之类实现的

而jax-rs相对更适合纯粹的服务化应用，也就是传统Java EE中所说的中间层服务，比如它可以把传统的EJB发布成RESTFul服务。在Spring应用中，也就把Spring中充当service之类的bean直接发布成RESTFul服务。总的来说这个RESTFul服务是在业务、应用层或者facade层。而MVC层次和概念在这种做比如（后台）服务化的应用中通常是没有多大价值的。

当然jax-rs的有些实现比如jersey，也试图提供mvc支持，以更好的适应上面所说的Web应用，但应该是不如Spring mvc。

在dubbo应用中，我想很多人都比较喜欢直接将一个本地的Spring service bean（或者叫manager之类的）完全透明的发布成远程服务，则这里用JAX-RS是更自然更直接的，不必额外的引入MVC概念。当然，先不讨论透明发布远程服务是不是最佳实践，要不要添加facade之类。

当然，我知道在dubbo不支持rest的情况下，很多朋友采用的架构是Spring mvc RESTFul调用dubbo (spring) service来发布RESTFul服务的。这种方式我觉得也非常好，只是如果不修改Spring mvc并将其与dubbo深度集成，RESTFul服务不能像dubbo中的其他远程调用协议比如webservices、dubbo rpc、hessian等等那样，享受诸多高级的服务治理的功能，比如：注册到dubbo的服务注册中心，通过dubbo监控中心监控其调用次数、TPS、响应时间之类，通过dubbo的统一的配置方式控制其比如线程池大小、最大连接数等等，通过dubbo统一方式做服务流量控制、权限控制、频次控制。另外Spring mvc仅仅负责服务端，而在消费端，通常是用Spring restTemplate，如果restTemplate不和dubbo集成，有可能像dubbo服务客户端那样自动或者人工干预做服务降级。如果服务端消费端都是dubbo系统，通过Spring的rest交互，如果Spring rest不深度整合dubbo，则不能用dubbo统一的路由分流等功能。

当然，其实我个人认为这些东西不必要非此即彼的。我听说Spring创始人rod johnson总是爱说一句话，the customer is always right，其实与其非要探讨哪种方式更好，不如同时支持两种方式就是了，所以原来在文档中也写过计划支持Spring rest annoation，只是不知道具体可行性有多高。

• Spring mvc的rest annotation支持
• 安全
• OAuth
• 异步调用
• 完善gzip
• 最大payload限制