jinrongluo edited a comment on issue #349:
URL:
https://github.com/apache/incubator-eventmesh/issues/349#issuecomment-841673220
Thanks @vongosling and @lrhkobe for your comments.
Our use case is that we use EventMesh's HTTP protocol for PubSub, and we
don't want the clients to react to the event of EventMesh Server restart. In
other words, we would like EventMesh to recover the existing subscriptions
after it restarts. This event is transparent to clients.
This is an important design requirement in cloud native production
environment, where Client Apps are managed by developers and the number of
Client Apps are large. The Server maintenance events should be self-managed,
and self-recovered. Operational transparency to End User (Client App) is the
key.
With this requirement in mind, I propose the following design model:
1. Have a pluggable persistency layer to store the existing Client Map
table. It has two parts:
1-1). eventmesh-persist-api
This is the persistency interface module which provide the APIs to
persist subscriber (Client) data, including Evn, Region, IDC, DCN, Hostname,
Sys, PidTopic, URL,etc. Example APIs look like the followings:
```
// Call after successful Subscribe()
public void addClient(Client client);
// Call after successful Unsubscribed(), or Client's lastUpTime expired
public void removeClient(Client client);
// Call after Runtime restart
public List<Client> loadClients();
```
1-2). eventmesh-persist
This module provides a pluggable vendor implementation of
`eventmesh-persist-api`, for example it can be file system, in-memory DB, MySQL
Database, etcd data store, Each storage module supplies with its own
configuration file, and implementation, this is similar idea to
`eventmesh-connector-rocketmq` module implementing `eventmesh-connector-api`
2. In Cloud native environment, it is typical for a Server to offer RESTful
API for its operations. So I would also suggest having a new eventmesh-rest
module which offers a list of RESTful APIs for publish / subscribe. This is on
top of the SDK-based support.
HTTP POST /rest/publish
headers: topic
payload:
{
"message": "test message"
}
HTTP POST /rest/subscribe
payload:
{
"env": "prod",
"Sys": "myapp",
"ping": "http://myapp/ping"; , // This API is used by Runtime to
check the health of client App, similar to Heartbeat
"topics": ["topic1", "topic2"],
"url": "http://myapp/webhook";
}
HTTP POST /rest/unsubscribe
payload:
{
"env": "prod",
"Sys": "myapp",
"topics": ["topic1", "topic2"],
"url": "http://myapp/webhook";
}
In this rest module, the Client module would be lighter, we may not need all
the Client params as current Client model. This is related to my previous issue
#320
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
