mirror of https://github.com/dapr/docs.git
Add service invocation How To (#43)
* add how to for service discovery * fix links * MInor updates * Update Readme.md * Changes to doc
This commit is contained in:
parent
573c436afe
commit
64bce7a898
|
@ -10,7 +10,7 @@ Bindings allow for on-demand, event-driven compute scenarios, and dapr bindings
|
|||
* Switch between bindings at runtime time
|
||||
* Enable portable applications where environment-specific bindings are set-up and no code changes are required
|
||||
|
||||
Bindings are developed independently of dapr runtime. You can view and contribute to the bindings [here](https://github.com/actionscore/components-contrib/tree/master/bindings).
|
||||
Bindings are developed independently of Dapr runtime. You can view and contribute to the bindings [here](https://github.com/dapr/components-contrib/tree/master/bindings).
|
||||
|
||||
## Supported Bindings and Specs
|
||||
|
||||
|
@ -37,24 +37,24 @@ Every binding has its own unique set of properties. Click the name link to see t
|
|||
|
||||
## Input Bindings
|
||||
|
||||
Input bindings are used to trigger your app when an event from an external system has occured.
|
||||
Input bindings are used to trigger your application when an event from an external resource has occured.
|
||||
An optional payload and metadata might be sent with the request.
|
||||
|
||||
In order to receive events from an input binding:
|
||||
|
||||
1. Define the component YAML that describes the type of bindings and its metadata (connection info, etc.)
|
||||
1. Define the component YAML that describes the type of binding and its metadata (connection info, etc.)
|
||||
2. Listen on an HTTP endpoint for the incoming event, or use the gRPC proto library to get incoming events.
|
||||
|
||||
Read the [How To](../../howto) section to get started with input bindings.
|
||||
|
||||
## Output Bindings
|
||||
|
||||
Output bindings allow users to invoke external systems
|
||||
Output bindings allow users to invoke external resources
|
||||
An optional payload and metadata can be sent with the invocation request.
|
||||
|
||||
In order to invoke an output binding:
|
||||
|
||||
1. Define the component YAML that describes the type of bindings and its metadata (connection info, etc.)
|
||||
1. Define the component YAML that describes the type of binding and its metadata (connection info, etc.)
|
||||
2. Use the HTTP endpoint or gRPC method to invoke the binding with an optional payload
|
||||
|
||||
Read the [How To](../../howto) section to get started with output bindings.
|
||||
|
|
|
@ -0,0 +1,99 @@
|
|||
# Invoke remote services
|
||||
|
||||
In many environments with multiple services that need to communicate with each other, developers often ask themselves the following questions:
|
||||
|
||||
* How do I discover and invoke different services?
|
||||
* How do I handle retries and transient errors?
|
||||
* How do I use distributed tracing correctly to see a call graph?
|
||||
|
||||
Dapr allows developers to overcome these challenges by providing an endpoint that acts as a combination of a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing and error handling.
|
||||
|
||||
## 1. Choose an ID for your service
|
||||
|
||||
Dapr allows you to assign a global, unique ID for your app.<br>
|
||||
This ID encapsulates the state for your application, regardless of the number of instances it may have.
|
||||
|
||||
### Setup an ID using the Dapr CLI
|
||||
|
||||
In Standalone mode, set the `--app-id` flag:
|
||||
|
||||
`dapr run --app-id cart --app-port 5000 python app.py`
|
||||
|
||||
### Setup an ID using Kubernetes
|
||||
|
||||
In Kubernetes, set the `dapr.io/id` annotation on your pod:
|
||||
|
||||
<pre>
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: python-app
|
||||
labels:
|
||||
app: python-app
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: python-app
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: python-app
|
||||
annotations:
|
||||
dapr.io/enabled: "true"
|
||||
<b>dapr.io/id: "cart"</b>
|
||||
dapr.io/port: "5000"
|
||||
...
|
||||
</pre>
|
||||
|
||||
## Invoke a service in code
|
||||
|
||||
Dapr uses a sidecar, decentralized architecture. To invoke an applications using Dapr, you can use the `invoke` endpoint on any Dapr instance in your cluster/environment.
|
||||
|
||||
The sidecar programming model encourages each applications to talk to its own instance of Dapr. The Dapr instances discover and communicate with one another.
|
||||
|
||||
*Note: The following is a Python example of a cart app. It can be written in any programming language*
|
||||
|
||||
```python
|
||||
from flask import Flask
|
||||
app = Flask(__name__)
|
||||
|
||||
@app.route('/add', methods=['POST'])
|
||||
def add():
|
||||
return "Added!"
|
||||
|
||||
if __name__ == '__main__':
|
||||
app.run()
|
||||
```
|
||||
|
||||
This Python app exposes an `add()` method via the `/add` endpoint.
|
||||
|
||||
### Invoke with curl
|
||||
|
||||
```
|
||||
curl http://localhost:3500/v1.0/invoke/cart/add -X POST
|
||||
```
|
||||
|
||||
Since the aoo endpoint is a 'POST' method, we used `-X POST` in the curl command.
|
||||
|
||||
To invoke a 'GET' endpoint:
|
||||
|
||||
```
|
||||
curl http://localhost:3500/v1.0/invoke/cart/add
|
||||
```
|
||||
|
||||
To invoke a 'DELETE' endpoint:
|
||||
|
||||
```
|
||||
curl http://localhost:3500/v1.0/invoke/cart/add -X DELETE
|
||||
```
|
||||
|
||||
Dapr puts any payload return by ther called service in the HTTP response's body.
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
The example above showed you how to directly invoke a different service running in our environment, locally or in Kubernetes.
|
||||
Dapr outputs metrics and tracing information allowing you to visualize a call graph between services, log errors and optionally log the payload body.
|
||||
|
||||
For more information on tracing, visit [this link](../../best-practices/troubleshooting/tracing.md).
|
|
@ -10,14 +10,14 @@ Dapr bindings allow you to:
|
|||
* Replace bindings without changing your code
|
||||
* Focus on business logic and not the event resource implementation
|
||||
|
||||
For more info on bindings, read [this](../concepts/bindings/bindings.md) link.<br>
|
||||
For more info on bindings, read [this](../../concepts/bindings/bindings.md) link.<br>
|
||||
For a complete sample showing bindings, visit this [link](<PLACEHOLDER>).
|
||||
|
||||
## 1. Create a binding
|
||||
|
||||
An input binding represents an event resource that Dapr uses to read events from and push to your application.
|
||||
|
||||
For the purpose of this HowTo, we'll use a Kafka binding. You can find a list of the different binding specs [here](../concepts/bindings/specs).
|
||||
For the purpose of this HowTo, we'll use a Kafka binding. You can find a list of the different binding specs [here](../../concepts/bindings/specs).
|
||||
|
||||
Create the following YAML file, named binding.yaml, and save this to the /components sub-folder in your application directory:
|
||||
|
||||
|
|
Loading…
Reference in New Issue