From 889f0ac3814097e4abfca53e648122aa60d6991b Mon Sep 17 00:00:00 2001 From: Redkale <22250530@qq.com> Date: Thu, 14 Dec 2017 10:42:46 +0800 Subject: [PATCH] --- article_regain.html | 2 +- course02_rest.html | 2 +- net.html | 12 ++++++------ service.html | 6 +++--- 4 files changed, 11 insertions(+), 11 deletions(-) diff --git a/article_regain.html b/article_regain.html index cd32808f3..531c5e05d 100644 --- a/article_regain.html +++ b/article_regain.html @@ -98,7 +98,7 @@

  Service

-         Redkale所有API设计中最精简的当属RPC功能，RPC没有直接调用的API，其功能依附在Service。RPC或类似功能的框架在Java里一直是比较重量级的，从古老的Corba、RMI到后来的EJB、WebService，还有其他很多RPC开源框架，都有着复杂的配置和大量API学习成本，有些还需要区分客户端和服务端(如WebService)。 Service不仅只是个逻辑层的规范定义，还集成了很强大的RPC和异步调用功能，远程模式的Service就是RPC功能，系统在依赖注入过程中创建Service时通过基本的IP配置自动识别是创建本地模式的Service还是远程模式的Service，远程模式的Service使用的就是RPC，但在代码层Service的调用本地模式与远程模式完全一样。更神奇的是，带有异步回调函数AsyncHandler 或返回类型为CompletableFuture的Service方法同样能执行远程模式。这种RPC的简易性是其他框架都无可匹敌的。REST风格的Service在接口设计上尽量减少注解性的配置，同时保留灵活性,减少HttpServlet的编写。
+         Redkale所有API设计中最精简的当属RPC功能，RPC没有直接调用的API，其功能依附在Service。RPC或类似功能的框架在Java里一直是比较重量级的，从古老的Corba、RMI到后来的EJB、WebService，还有其他很多RPC开源框架，都有着复杂的配置和大量API学习成本，有些还需要区分客户端和服务端(如WebService)。 Service不仅只是个逻辑层的规范定义，还集成了很强大的RPC和异步调用功能，远程模式的Service就是RPC功能，系统在依赖注入过程中创建Service时通过基本的IP配置自动识别是创建本地模式的Service还是远程模式的Service，远程模式的Service使用的就是RPC，但在代码层Service的调用本地模式与远程模式完全一样。更神奇的是，带有异步回调函数CompletionHandler 或返回类型为CompletableFuture的Service方法同样能执行远程模式。这种RPC的简易性是其他框架都无可匹敌的。REST风格的Service在接口设计上尽量减少注解性的配置，同时保留灵活性,减少HttpServlet的编写。

  Source

diff --git a/course02_rest.html b/course02_rest.html index 61513d5a9..d1770f3f5 100644 --- a/course02_rest.html +++ b/course02_rest.html @@ -34,7 +34,7 @@ @RestService标记Service需要REST化。 @RestMapping标记请求的方法名，同一方法上可重复标记(需确保name值在Service中是唯一的)。
其标记的Service方法只能throws IOException或不抛异常。 @RestConvert标记请求的方法名上，对返回值以JSON形式输出时进行字段的屏蔽或开启进行设置。 - @RestParam获取常规参数值, 字段类型可以是 基础数据类型/Flipper/AsyncHandler/String/JavaBean
name='&'    表示当前用户(@HttpUserType)
name='#'    表示截取uri最后一段
name='#xxx:'    表示从uri中/pipes/xxx:v/截取xxx:的值 + @RestParam获取常规参数值, 字段类型可以是 基础数据类型/Flipper/CompletionHandler/String/JavaBean
name='&'    表示当前用户(@HttpUserType)
name='#'    表示截取uri最后一段
name='#xxx:'    表示从uri中/pipes/xxx:v/截取xxx:的值 @RestHeader通过request.getHeader获取参数值, 字段类型只能是String @RestCookie通过request.getCookie获取Cookie值, 字段类型只能是String @RestBody通过request.getBody获取参数值, 字段类型只能是String/byte[]/JavaBean diff --git a/net.html b/net.html index ac1392bb6..b6b6c2b69 100644 --- a/net.html +++ b/net.html @@ -557,11 +557,11 @@ //增加Cookie值 public HttpResponse addCookie(Collection<HttpCookie> cookies); - //创建AsyncHandler实例，将非字符串对象以JSON格式输出，字符串以文本输出 - public AsyncHandler createAsyncHandler(); + //创建CompletionHandler实例，将非字符串对象以JSON格式输出，字符串以文本输出 + public CompletionHandler createAsyncHandler(); - //传入的AsyncHandler子类必须是public，且保证其子类可被继承且completed、failed可被重载且包含空参数的构造函数 - public <H extends AsyncHandler> H createAsyncHandler(Class<H> handlerClass); + //传入的CompletionHandler子类必须是public，且保证其子类可被继承且completed、failed可被重载且包含空参数的构造函数 + public <H extends CompletionHandler> H createAsyncHandler(Class<H> handlerClass); //设置状态码 public void setStatus(int status); @@ -595,10 +595,10 @@ public HttpResponse skipHeader(); //异步输出指定内容 - public <A> void sendBody(ByteBuffer buffer, A attachment, AsyncHandler<Integer, A> handler); + public <A> void sendBody(ByteBuffer buffer, A attachment, CompletionHandler<Integer, A> handler); //异步输出指定内容 - public <A> void sendBody(ByteBuffer[] buffers, A attachment, AsyncHandler<Integer, A> handler); + public <A> void sendBody(ByteBuffer[] buffers, A attachment, CompletionHandler<Integer, A> handler); //关闭HTTP连接，如果是keep-alive则不强制关闭 public void finish(); diff --git a/service.html b/service.html index a5a4d6dce..7129aac1e 100644 --- a/service.html +++ b/service.html @@ -608,14 +608,14 @@

Service 异步调用

-

        远程模式不仅对@RpcCall注解进行处理，而且对方法含有 AsyncHandler 的参数或返回类型为CompletableFuture也进行异步特殊处理。异步调用对远程模式非常有意义，可以减少同步方式对当前线程的占用时间。也给Source组件的异步调用提供了基础。

+

        远程模式不仅对@RpcCall注解进行处理，而且对方法含有 CompletionHandler 的参数或返回类型为CompletableFuture也进行异步特殊处理。异步调用对远程模式非常有意义，可以减少同步方式对当前线程的占用时间。也给Source组件的异步调用提供了基础。

    @Override
-    public <T> void updateAsync(final AsyncHandler<Void, T[]> handler, @RpcAttachment final T... values) {
+    public <T> void updateAsync(final CompletionHandler<Void, T[]> handler, @RpcAttachment final T... values) {
         source.update(values);
         if (handler != null) handler.completed(null, values);
     }

-         如上图源码，异步接口(含AsyncHandler参数或返回类型为CompletableFuture)与同步接口执行流程相同。当Service为远程模式时，调用异步接口时，通信接口发到远程服务器时AsyncHandler参数的值传null，返回数据后再调用本地的AsyncHandler参数值执行。
+         如上图源码，异步接口(含CompletionHandler参数或返回类型为CompletableFuture)与同步接口执行流程相同。当Service为远程模式时，调用异步接口时，通信接口发到远程服务器时CompletionHandler参数的值传null，返回数据后再调用本地的CompletionHandler参数值执行。
        异步调用方式是提高服务并发性的有效手段，特别是在远程模式Service比较多的情况下效果更明显。以HTTP服务为例，在Tomcat刚刚改版成NIO的时候，网上随处可见都是大谈NIO性能比BIO多好，认为BIO与NIO的不同，是BIO往往会引入多线程，每个连接一个单独的线程；NIO则是使用单线程或者只使用少量的多线程，每个连接共用一个线程。而事实上呢，通常还是通过增加线程数来提高并发量。为什么NIO作用不大呢， 因为一个HTTP动态请求耗时最多是业务逻辑层，特别是操作数据库，IO操作的耗时比重小得多，只有在静态资源请求这种纯IO操作才能体现NIO、AIO(NIO.2)的优势。举例一个简单的数据查询请求，采用BIO方式耗时（为了方便比较将所耗时间扩大几倍）如下:
                1、服务器TCP连接开始到进入HttpServlet，耗时 10ms
                2、用户态判断和参数验证，                         耗时 10ms