You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by li...@apache.org on 2019/09/06 08:33:57 UTC
[dubbo-website] branch master updated: Translation of
dubboAsync_client.md (#464)
This is an automated email from the ASF dual-hosted git repository.
lixiaojie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new 3078d28 Translation of dubboAsync_client.md (#464)
3078d28 is described below
commit 3078d28eb0e1b6b8f2523cbd90a619062396670c
Author: Kyle <fi...@hotmail.com>
AuthorDate: Fri Sep 6 16:33:51 2019 +0800
Translation of dubboAsync_client.md (#464)
---
blog/en-us/dubboAsync_client.md | 85 +++++++++++++++++++++++++++++++++++++
blog/zh-cn/dubboAsync_client.md | 2 +-
img/blog/dubboasyn_client/1_en.png | Bin 0 -> 17755 bytes
site_config/blog.js | 7 +++
4 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/blog/en-us/dubboAsync_client.md b/blog/en-us/dubboAsync_client.md
new file mode 100644
index 0000000..d5993be
--- /dev/null
+++ b/blog/en-us/dubboAsync_client.md
@@ -0,0 +1,85 @@
+---
+title: Implementation background and practice of Dubbo client asynchronous interface
+keywords: Dubbo, Asynchronous, Reactive
+description: Implementation background and practice of Dubbo client asynchronous interface
+---
+
+# Implementation background and practice of Dubbo client asynchronous interface
+
+## Preface
+
+
+
+Let's start with a brief introduction about the stages of a complete Dubbo invocation.
+1. Biz~ represents business thread, that is, the thread where the business logic is located. Biz~ thread pool may be created and maintained by business itself, most of which may be managed by system framework itself (for example, a web system runs under Tomcat container, Biz~ thread is maintained by Tomcat); IO~ stands for network data processing thread, which is created and maintained by IO framework (such as Netty, Grizzly). Dubbo Remoting's default Netty implementation is NioEventloop [...]
+
+2. As we all know, the way of data communication between threads is shared variables. The data communication between Biz and IO is Queue. Specifically to Dubbo, Biz put a task in EventLoop's LinkedBlockingQueue in the client side implementation (i.e. the steps labeled in Figure 1 above), and the corresponding Thread in the EventLoop will keep iteration the Queue to keep on executing the information the task contains. Specific code can refer to SingleThreadEventExecutor (by the way, the d [...]
+
+3. As shown in the figure above, a standard RPC call passes through four message (event) transfers of 1,2,3,4, respectively are the client business thread sending requests to the client IO thread, the server business logic thread receiving the server IO thread requests, the server logic thread responding to the server IO thread after processing, and the client IO thread receiving the results feedback to the business logic thread.
+
+## Client Asynchronization
+
+### Background
+In the Java language (other languages are not clear), a call of the local interface can be transparently converted into the call of remote RPC through the proxy mechanism. Most business parties prefer this programming method similar to the local interface to do remote service invocation. Therefore, although RPC is naturally asynchronous internally, users using Dubbo mostly use synchronization, while asynchrony becomes a minority use scenario. The advantage of synchronization is that the [...]
+
+Therefore, the motivation of client asynchronization is to save thread resource overhead at the cost of understanding how asynchronization is used. In the synchronous mode, the return type of API interface represents a certain business class, while in the asynchronous case, the response and the request are completely independent events, so it is most suitable for the return type of API interface to be CompletionStage mentioned above, which is the inevitable asynchronization supported by [...]
+
+The example blow is to illustrate it.
+
+### The sample
+
+Refer to the example code for event notification: [https://github.com/dubbo/dubbo-samples/tree/master/dubbo-samples-notify](https://github.com/dubbo/dubbo-samples/tree/master/dubbo-samples-notify)
+
+Event notification allows the Consumer to trigger 'oninvoke', 'onreturn' and 'onthrow' events, which respectively represent before the call, after the call returns normally, or when an exception occurs.
+
+You can specify a method for notifying events when configuring the Consumer, such as:
+
+```xml
+<bean id="demoCallback" class="com.alibaba.dubbo.samples.notify.impl.NotifyImpl" />
+
+<dubbo:reference id="demoService" check="false" interface="com.alibaba.dubbo.samples.notify.api.DemoService" version="1.0.0" group="cn">
+ <dubbo:method name="sayHello" onreturn="demoCallback.onreturn" onthrow="demoCallback.onthrow"/>
+</dubbo:reference>
+```
+
+The code for NotifyImpl is as follows:
+
+```java
+public class NotifyImpl implements Notify{
+
+ public Map<Integer, String> ret = new HashMap<Integer, String>();
+
+ public void onreturn(String name, int id) {
+ ret.put(id, name);
+ System.out.println("onreturn: " + name);
+ }
+
+ public void onthrow(Throwable ex, String name, int id) {
+ System.out.println("onthrow: " + name);
+ }
+}
+```
+
+It is important to note that the parameters for the three methods in the custom Notify interface are as follows:
+
+* `oninvoke` The parameters of the method are the same as those of the calling method.
+* `onreturn` The first parameter of the method is the return value of the calling method, and the rest is the parameters of the calling method.
+* `onthrow` The first parameter to the method is the call exception, and the rest is the parameter to the calling method.
+
+In the above configuration, the `sayHello` method is called synchronously, so the execution of the event notification method is also synchronously executed. `async=true` can be configured to make the method call asynchronous, and the notification event method is also executed asynchronously. In particular, the `oninvoke` method executes synchronously, regardless of whether it is invoked asynchronously or not.
+
+### Practical advice
+
+* <div data-type="alignment" data-value="justify" style="text-align:justify">
+ <div data-type="p">Logical Non-Strongly dependent results after RPC invocation: Asynchronous callbacks are suitable for client-side asynchronous invocation when the client <strong>is not strongly dependent on the server response</strong>.</div>
+ </div>
+
+* <div data-type="alignment" data-value="justify" style="text-align:justify">
+ <div data-type="p">RX scenario: after learning about reactive programming model, I believe that as long as the programming thinking can embrace reactive and the state machine design of business model can be adjusted appropriately, asynchronous solutions can be applied in all scenarios, so as to achieve better terminal response experience. For Dubbo, the current asynchronous interface model needs to be improved like the reactive model interface in order to make the user more naturally a [...]
+ </div>
+
+
+### Conclusions
+
+* The motivation of client asynchronization is that the request sending and response processing are two different independent events, how the response is handled and in which thread is handled are not required to be coupled with the business logic thread of the request sending event.
+* The processing logic of response event callbacks in which thread to process is to be selected according to the situation. It is recommended that if the callback logic is relatively simple, it should be directly in the IO thread; if it contains IO type synchronization operations such as remote access or DB access, it is recommended that it be processed in a separate thread pool.
\ No newline at end of file
diff --git a/blog/zh-cn/dubboAsync_client.md b/blog/zh-cn/dubboAsync_client.md
index a59b190..ab14225 100644
--- a/blog/zh-cn/dubboAsync_client.md
+++ b/blog/zh-cn/dubboAsync_client.md
@@ -24,7 +24,7 @@ description: Dubbo客户端异步接口的实现背景和实践
## 客户端异步
### 实现背景
-在Java语言（其他语言不清楚）下一次本地接口的调用可以透明地通过代理机制转为远程RPC的调用，大多数业务方也比较喜欢这种与本地接口类似的编程方式做远程服务集成，所以虽然RPC内部天然是异步的，但使用Dubbo的用户使用最广泛的还是同步，而异步反而成为小众的使用场景。同步的优点是编程模型更加符合业务方的“传统”习惯，代价是在图中的1代表的请求发出事件后需要阻塞当前的Biz~线程，一直等到4代表的响应处理后才能唤醒。在这个短则微妙级别，长则秒级的1,2,3,4处理过程中都要阻塞Biz~线程，就会消耗线程资源，增加系统资源的开销。
+在Java语言（其他语言不清楚）下一次本地接口的调用可以透明地通过代理机制转为远程RPC的调用，大多数业务方也比较喜欢这种与本地接口类似的编程方式做远程服务集成，所以虽然RPC内部天然是异步的，但使用Dubbo的用户使用最广泛的还是同步，而异步反而成为小众的使用场景。同步的优点是编程模型更加符合业务方的“传统”习惯，代价是在图中的1代表的请求发出事件后需要阻塞当前的Biz~线程，一直等到4代表的响应处理后才能唤醒。在这个短则微秒级别，长则秒级的1,2,3,4处理过程中都要阻塞Biz~线程，就会消耗线程资源，增加系统资源的开销。
所以，客户端异步的出发点是节省线程资源开销，代价是需要了解下异步的使用方式:)。在同步方式下API接口的返回类型是代表着某个业务类，而当异步情况下，响应返回与请求发出是完全独立的两个事件，需要API接口的返回类型变为上述中说的CompletionStage才是最贴合的，这是Dubbo在异步上支持的必然异步。回到最近的Dubbo发布版，是不改变接口的情况下，需要在服务创建时注册一个回调接口来处理响应返回事件。
diff --git a/img/blog/dubboasyn_client/1_en.png b/img/blog/dubboasyn_client/1_en.png
new file mode 100644
index 0000000..6e12e51
Binary files /dev/null and b/img/blog/dubboasyn_client/1_en.png differ
diff --git a/site_config/blog.js b/site_config/blog.js
index c12ee98..7902c8b 100644
--- a/site_config/blog.js
+++ b/site_config/blog.js
@@ -9,6 +9,13 @@ export default {
dateStr: 'August 26th, 2019',
desc: 'This article introduces how to make service test with Dubbo',
link: '/en-us/blog/service-test.html',
+ }，
+ {
+ title: 'Implementation background and practice of Dubbo client asynchronous interface',
+ author: '@JeffLv',
+ dateStr: 'Feb 20th, 2019',
+ desc: 'Implementation background and practice of Dubbo client asynchronous interface',
+ link: '/en-us/blog/dubboAsync_client.html',
},
{
title: 'How to use Fescar to ensure consistency between Dubbo Microservices',