lxy/redkale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
Redkale
2017-04-23 21:28:08 +08:00
parent b0eeeaebf3
commit 6c893285e5
3 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
article_regain.html
View File

@@ -98,7 +98,7 @@
</p>
<p>&nbsp;&nbsp;<b>Service</b></p>
<p>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://redkale.org" target="_blank">Redkale</a>所有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 的Service方法同样能执行远程模式。这种RPC的简易性是其他框架都无可匹敌的。REST风格的Service在接口设计上尽量减少注解性的配置，同时保留灵活性,减少HttpServlet的编写。<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://redkale.org" target="_blank">Redkale</a>所有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的编写。<br>
</p>
<p>&nbsp;&nbsp;<b>Source</b></p>
<p>

4
service.html
View File

@@ -631,14 +631,14 @@
<h3><a id="service_async" class="anchor" href="#" aria-hidden="true"></a>Service 异步调用</h3>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;远程模式不仅对@RpcCall注解进行处理，而且对方法含有 <b>AsyncHandler</b> 的参数也进行异步特殊处理。异步调用对远程模式非常有意义，可以减少同步方式对当前线程的占用时间。也给Source组件的异步调用提供了基础。</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;远程模式不仅对@RpcCall注解进行处理，而且对方法含有 <b>AsyncHandler</b> 的参数或返回类型为<b>CompletableFuture</b>也进行异步特殊处理。异步调用对远程模式非常有意义，可以减少同步方式对当前线程的占用时间。也给Source组件的异步调用提供了基础。</p>
<div class="highlight"><pre> <span class="nd">@Override</span>
<span class="kd">public</span> <span class="o">&lt;</span><span class="n">T</span><span class="o">&gt;</span> <span class="kt">void</span> <span class="nf">updateAsync</span><span class="o">(</span><span class="kd">final</span> <span class="n">AsyncHandler</span><span class="o">&lt;</span><span class="n">Void</span><span class="o">,</span> <span class="n">T</span><span class="o">[]&gt;</span> <span class="n">handler</span><span class="o">,</span> <span class="nd">@RpcAttachment</span> <span class="kd">final</span> <span class="n">T</span><span class="o">...</span> <span class="n">values</span><span class="o">)</span> <span class="o">{</span>
<span class="n">source</span><span class="o">.</span><span class="na">update</span><span class="o">(</span><span class="n">values</span><span class="o">);</span>
<span class="k">if</span> <span class="o">(</span><span class="n">handler</span> <span class="o">!=</span> <span class="kc">null</span><span class="o">)</span> <span class="n">handler</span><span class="o">.</span><span class="na">completed</span><span class="o">(</span><span class="kc">null</span><span class="o">,</span> <span class="n">values</span><span class="o">);</span>
<span class="o">}</span></pre></div>
<p>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;如上图DataSourceService的源码，当DataSource为本地实例时，异步接口(含<b>AsyncHandler</b>参数的)与同步接口执行流程相同。当DataSource为远程模式时，调用异步接口时，通信接口发到远程服务器时AsyncHandler参数的值传<b>null</b>，返回数据后再调用本地的AsyncHandler参数值执行。<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;如上图DataSourceService的源码，当DataSource为本地实例时，异步接口(含<b>AsyncHandler</b>参数或返回类型为<b>CompletableFuture</b>)与同步接口执行流程相同。当DataSource为远程模式时，调用异步接口时，通信接口发到远程服务器时AsyncHandler参数的值传<b>null</b>，返回数据后再调用本地的AsyncHandler参数值执行。<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;异步调用方式是提高服务并发性的有效手段，特别是在远程模式Service比较多的情况下效果更明显。以HTTP服务为例，在Tomcat刚刚改版成NIO的时候，网上随处可见都是大谈NIO性能比BIO多好，认为BIO与NIO的不同，是BIO往往会引入多线程，每个连接一个单独的线程；NIO则是使用单线程或者只使用少量的多线程，每个连接共用一个线程。而事实上呢，通常还是通过增加线程数来提高并发量。为什么NIO作用不大呢， 因为一个HTTP动态请求耗时最多是业务逻辑层，特别是操作数据库，IO操作的耗时比重小得多，只有在静态资源请求这种纯IO操作才能体现NIO、AIO(NIO.2)的优势。举例一个简单的数据查询请求，采用BIO方式耗时（为了方便比较将所耗时间扩大几倍）如下: <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1、服务器TCP连接开始到进入HttpServlet，耗时 10ms <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2、用户态判断和参数验证，&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 耗时 10ms <br>

2
source.html
View File

@@ -75,7 +75,7 @@
</table>
<p>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;以上接口除了directXXX，其他都有等同的异步接口。insert、delete、update接口与JPA同名接口用法一样。DataSource提供了丰富的查询接口，且有独特的翻页查询功能。每以系列的方法主要重载三类： 单个字段过滤、FilterBean过滤和FilterNode过滤。<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>带 AsyncHandler 参数的接口均为异步接口</b>。<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b>带 AsyncHandler 参数或返回类型为CompletableFuture的接口均为异步接口</b>。<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;开发者可以借鉴 <a href="https://github.com/redkale/redkale-demo" target="_blank">Redkale-demo</a> 中的 <a href="https://github.com/redkale/redkale-demo/blob/master/src/org/redkale/demo/base/AutoClassCreator.java" target="_blank"> AutoClassCreator</a>的代码根据数据表自动生成Entity代码。
</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;<b>过滤条件</b></p>