dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

#90 - clarify service invocation conceptual doc with an endpoint. Also, improve the diagram. (#135)

This commit is contained in:
Leon Mai 2019-10-15 22:10:14 -07:00 committed by Yaron Schneider
parent aa39521cc0
commit 9b1050b170
2 changed files with 13 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
concepts/service-invocation/service-invocation.md
View File

@ -5,13 +5,25 @@ Dapr-enabled apps can communicate with each other through well-known endpoints i
![Service Invocation Diagram](../../images/service-invocation.png) ![Service Invocation Diagram](../../images/service-invocation.png)
1. Service A makes a http/gRPC call meant for Service B. The call goes to the local Dapr sidecar. 1. Service A makes a http/gRPC call meant for Service B. The call goes to the local Dapr sidecar.
2. Dapr discovers Service B's location and forwards the message to Service B's Dapr sidecar 2. Dapr discovers Service B's location and forwards the message to Service B's Dapr sidecar
3. Service B's Dapr sidecar forwards the request to Service B. Service B performs its corresponding business logic. 3. Service B's Dapr sidecar forwards the request to Service B. Service B performs its corresponding business logic.
4. Service B sends a response for Service A. The response goes to Service B's sidecar. 4. Service B sends a response for Service A. The response goes to Service B's sidecar.
5. Dapr forwards the response to Service A's Dapr sidecar. 5. Dapr forwards the response to Service A's Dapr sidecar.
6. Service A receives the response. 6. Service A receives the response.
As an example for all the above, suppose we have the collection of apps described in the following sample, where a python app invokes a Node.js app: https://github.com/dapr/samples/blob/master/2.hello-kubernetes/README.md
In such a scenario, the python app would be "Service A" above, and the Node.js app would be "Service B".
The following describes items 1-6 again in the context of this sample:
1. Suppose the Node.js app has a Dapr app id of "nodeapp", as in the sample. The python app invokes the Node.js app's `neworder` method by posting `http://localhost:3500/v1.0/invoke/nodeapp/method/neworder`, which first goes to the python app's local Dapr sidecar.
2. Dapr discovers the Node.js app's location and forwards it to the Node.js app's sidecar.
3. The Node.js app's sidecar forwards the request to the Node.js app. The Node.js app performs its business logic, which, as described in the sample, is to log the incoming message and then persist the order ID into Redis (not shown in the diagram above).
Steps 4-5 are the same as the list above.
For more information, see: For more information, see:
- The [Service Invocation Spec](https://github.com/dapr/spec/blob/master/service_invocation.md) - The [Service Invocation Spec](https://github.com/dapr/spec/blob/master/service_invocation.md)
- A [HowTo]() on Service Invocation - A [HowTo]() on Service Invocation

BIN
images/service-invocation.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 44 KiB