https://github.com/scalecube/scalecube-services ⚛ High-Speed ⚛ Cloud-Native ⚛ Reactive Microservices ⚓
and the test are also written as usecases
so each test demo some behavior that might happen
the examples are more on level of getting started
the tests go deeper
the ScalecubeServiceDiscovery uses cluster internally
so if you need strict SWIM and Gossip you can just use cluster
for services you can use discovery() that speaks about service endpoints
so we pushed down the cluster as implementation of discovery
you can always create clusters instances when required
and fanout to all using your custom router
but this would be kind of wired usecase :)
better alternative is to use directlly the cluster
but gossip is not a messaging platfrom
there is no ordering
its will reach to all cluster nodes eventually
its good for static things
cluster have transport
and knowing members you can message to all
"better alternative is to use directlly the cluster" -- means we can get the cluster reference of the microservice or a separate cluster instance?
@ronenhamias thanks a lot for your inputs
please, help me in this case.
test failed by 43 line. If we have signature on Invalid interface as
Flux<String> invalidRequestChannel(Flux<String> input) test succecfull
I'm writing the documentation for the project and I found this bug.
@ronenhamias @artem-v https://github.com/scalecube/scalecube-services/pull/711#issuecomment-647587227 some yet
Exberry is based on scalecube microservices architecture
I want to pass some argument in ServiceMessage headers, so that I can route by it,
then I found headers cannot be mapped to the ServiceMethod.
I thought it can be done by adding a ServiceHeader like following snippet, could anyone give some advice on this? Thanks.
then I found headers cannot be mapped to the ServiceMethod.
I thought it can be done by adding a ServiceHeader like following snippet, could anyone give some advice on this? Thanks.
@Service
public interface FooApi extends IDL {
@ServiceMethod
Flux<SCMessage> roundtrip(Flux<SCMessage> messages,
@ServiceHeader("dst-region") String dstRegion);
}
You will need at least one static IP to let other nodes to join, such IP is called seedAddress in the code, and it should be public if other nodes are not in same LAN network.
But with single seed is not robust, it will fail when the seed fails. Having more seeds will make it better.
@swapnil-pandey
But with single seed is not robust, it will fail when the seed fails. Having more seeds will make it better.
@swapnil-pandey
About the header thing, I just realized I can do that using service dispatcher, like:
@ServiceMethod
@RequestType(GreetingRequest.class)
@ResponseType(GreetingResponse.class)
Flux<ServiceMessage> bidiGreetingMessage(Publisher<ServiceMessage> requests);But it errors when invoking the service provider, I have sent a PR for this, would some one please take a look?
scalecube/scalecube-services#790
Thank you.
It depends what you use. @swapnil-pandey
For gossip, if two nodes could not reach each other, there's still a chance they can gossip to each other (depends on the gossip settings) with the help of other nodes which they could reach.
For RPC, if two nodes could not connect each other, then a central node which they both can connect could be used as exchange, this central node need a public IP to let others provide and consume service from it.
For gossip, if two nodes could not reach each other, there's still a chance they can gossip to each other (depends on the gossip settings) with the help of other nodes which they could reach.
For RPC, if two nodes could not connect each other, then a central node which they both can connect could be used as exchange, this central node need a public IP to let others provide and consume service from it.