Multi-cloud HTTP communication using MQTT
fuyuu-router hub -c config.toml -b mqtt://BROKER-IP:1883
fuyuu-router agent -c config.toml --id agent01 -b mqtt://BROKER-IP:1883 --proxy-host PROXY-HOST-IP
curl http://FUYUU-ROUTER-HUB-IP:8080/ -H "FuyuuRouter-IDs: agent01"
This request follows the path below:
fuyuu-router hub -> MQTT broker -> fuyuu-router agent -> proxy host
When multiple IDs are passed to FuyuuRouter-IDs separated by commas, fuyuu-router performs load balancing between those IDs.
The current load balancing algorithm is random only.
fuyuu-router doesn't perform any service discovery.
Agents publish a message to the fuyuu-router/launch
topic when they launch and to the fuyuu-router/terminate
topic when they disconnect.
Users can subscribe to these topics to create a mechanism, for example, to update Istio VirtualServices.
While many MQTT brokers have payload size limitations, there is a desire to send large HTTP request/response.
The fuyuu-router addresses this with two policies - 1) split and 2) storage relay.
The fuyuu-router can bypass payload size limitations by splitting large HTTP requests/responses into multiple chunks and then combining them.
apiVersion: v1
kind: ConfigMap
metadata:
name: example
data:
config.toml: |
[networking]
format = "json"
large_data_policy = "split"
[split]
chunk_bytes = 128000
fuyuu-router allows the hub and agent to transparently communicate with each other through object storage only when the HTTP request/response is large.
fuyuu-router uses objstore, and its configuration file is needed.
apiVersion: v1
kind: ConfigMap
metadata:
name: example
data:
config.toml: |
[networking]
format = "json"
large_data_policy = "storage_relay"
[storage_relay]
objstore_file = "/app/config/objstore.yaml"
threshold_bytes = 128000
objstore.yaml: |
type: S3
config:
bucket: "example-bucket"
endpoint: "s3.amazonaws.com"
access_key: "<ACCESS_KEY>"
secret_key: "<SECRET_KEY>"
The hub and agent must reference the same bucket and have appropriate permissions to it.
For instance, in S3, the shortest deletion period is one day. In fuyuu-router, since object storage is used only temporarily, if you want to reduce costs, you can have the hub delete objects by using the deletion
settings.
[storage_relay]
objstore_file = "/app/config/objstore.yaml"
threshold_bytes = 128000
deletion = true
- Currently only HTTP 1.1 is supported. Perhaps HTTP2 is the next roadmap.
- fuyuu-router introduces an additional hop to the MQTT broker. It is not suitable for cases where strict latency requirements are demanded.
How about Skupper?
Skupper is great, but I had a few complaints.
- skupper doesn't support revocation of a specific site only. To work around that problem deploy Skupper and load balancer per site
- Skupper doesn't support star topology. To work around that problem deploy Skupper and load balancer per site
- skupper-router is written in C.
- Skupper uses AMQP, but Open Cluster Management has MQTT-based client.
I referred to the following articles:
- https://stackoverflow.com/questions/68533190/any-implications-of-using-uuids-in-mqtt-topic-names
- emqx/emqx#8261
- https://repost.aws/questions/QUkUTmC3fRRkWb41he5U-HwQ/is-there-a-limitation-on-the-number-of-topics-in-iot-core
"fuyuu" means floating in Japanese(浮遊). It flies above the clouds.
It is also inspirated by the word sky computing.
alpha