forked from jasonkeene/docs-rabbitmq-staging
-
Notifications
You must be signed in to change notification settings - Fork 0
/
service-gateway-access.html.md.erb
58 lines (43 loc) · 2.92 KB
/
service-gateway-access.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
---
title: Service-Gateway Access
owner: RabbitMQ
---
Service-gateway access enables a <%= vars.product_full %> on-demand service instance to
connect to external components that are not on the same foundation as the service instance.
These components could be on another foundation or hosted outside of the foundation.
For related procedures, see:
* [Enabling Service-Gateway Access](./enable-service-gateway.html)
* [Create a Service Instance with Service-Gateway Access](./create-service-gateway-instance.html)
<p class="note">
<strong>Note:</strong> Service-gateway access is no longer in the beta stage. It works with
Advanced Message Queuing Protocol (AMQP), MQ Telemetry Transport (MQTT), Simple (or Streaming) Text
Orientated Messaging Protocol (STOMP), STOMP over a WebSocket connection (Web STOMP), and AMQP 1.0.
</p>
## <a id='overview'></a> Overview
There are multiple use cases for service-gateway access. For example:
- Accessing RabbitMQ from apps deployed to <%= vars.app_runtime_full %> (<%= vars.app_runtime_abbr %>)
in a different foundation
- Replicating messages between RabbitMQ clusters in different foundations,
for example, to set up federation for disaster recovery
- Enabling apps running outside the foundation to communicate, through RabbitMQ,
with <%= vars.app_runtime_abbr %>-deployed apps
- Using RabbitMQ as a service for apps that are not deployed to <%= vars.app_runtime_abbr %>
## <a id='architecture'></a> Architecture
Service-gateway access to <%= vars.product_short %> instances leverages the TCP router in
<%= vars.app_runtime_abbr %>.
Any RabbitMQ requests that an app makes are forwarded through DNS to a load balancer that can route
traffic from outside to inside the foundation.
This load balancer opens a range of ports that are reserved for RabbitMQ traffic.
When an app developer creates a service instance on a plan with service-gateway access enabled, a
port from the range is provisioned for that service instance.
The load balancer then forwards the requests for this <%= vars.product_short %> service instance to
the TCP router.
The TCP router internally load balances between the <%= vars.product_short %> service instance nodes.
The diagram below shows how the traffic is routed from apps to the RabbitMQ nodes in this case.
All apps using this <%= vars.product_short %> service instance follow the same route,
irrespective of whether they are hosted on the foundation or are hosted outside of the foundation.
![Diagram showing an app that is external to the foundation sending traffic to the external load balancer.
The load balancer sends the traffic to a RabbitMQ tile port in the TCP router.
The TCP router is inside the foundation.
The TCP router balances the load among the RabbitMQ nodes in the RabbitMQ service instance.](images/service-gateway-architecture.png)
<a href="./images/service-gateway-architecture.png" target="_blank" aria-hidden="true">Click here to view a larger version of the image above</a>