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 @@
远程模式不仅对@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