I have two stateful services hosted on my service fabric.. I need to communicate from one service to another service using service proxy. Some thing like this
_proxyFactory.CreateServiceProxy<IRestoreStatefulService>(new
Uri("fabric:/Itron.Cloud.ActionManager.ExDefinition.Services/BackupResStateful"),
new ServicePartitionKey(0), TargetReplicaSelector.Default, null)
I could do this from stateful to stateless service, but couldnt do the same between two stateful services..
Related
Let's say we have the following setup:
Service A consists of a pod in a Kubernetes cluster with two containers Api A and Sidecar A. Api A communicates with the outside world through Sidecar A. Sidecar A is registered as a consumer.
Service B consists of a pod in a Kubernetes cluster with two containers Api B and Sidecar B. Api B communicates with the outside world via Sidecar B. Sidecar B is registered as a producer.
Service A and Service B could potentially have multiple instances.
The services register themselves with the service mesh through a central authority, let's call it Service Discovery, that knows about the specific instances of each service and the endpoints that they expose. Service A can also subscribe to a specific endpoint of Service B via this Service Discovery central authority. (The central authority also deals with security, tokens and certificates but I want to simplify)
Sidecar A and Sidecar B regularly communicate with Service Discovery to confirm availability.
How should Service A call an endpoint of Service B:
directly via a specific url because the Sidecar A should know about the instances of Service B via service discovery and should choose a healthy one?
or indirectly by calling a generic api of Service Discovery which should know what are the healthy instances that can be called and redirect the request to one of them accordingly?
or in some other way?
I found out that the recommended way is for service A to call endpoint B directly via a specific URL because the Sidecar A should know about the instances of Service B via service discovery and should choose a healthy instance.
The purpose of service discovery is just that: to allow services to be discoverable. It should not serve as a proxy between calls.
I have a stateless service, Subscription Service.
Subscription Service has 3 routes(3 controllers)
"api/v1/Subscription"
"api/v1/notification"
"api/v1/AdminService".
Now I want to add new service BotService, on port 9067. it has 1 route "api/v1/botservice" How to configure Service Fabric to route calls to Bot Service for its registered routes and Subscription Service on its registered route.
If each service runs on a different port then there shouldn't be a problem. You need to update your cluster network resources (NSG and load balancer) to enable inbound traffic towards your cluster VMSS, on the new port (9067).
this links can be maybe helpful:
https://dzimchuk.net/hosting-multiple-externally-accessible-asp-net-core-applications-in-service-fabric/
or this:
https://dzimchuk.net/exposing-services-on-different-domains-in-azure-service-fabric/
In my SF application a stateful Worker service communicates with a stateless Logging service using service remoting. The stateful Worker service creates the Logging proxy in its constructor using ServiceProxy.Create<ILoggingService>(loggingServiceUri) and keeps the returned reference for its entire lifetime. There are several stateless Logging service instances running on the cluster (i. e. Instance Count == -1). My question is:
Are calls to the ILoggingService proxy form the Worker service routed to different Logging service instances?
Yes, when you are using SF remoting to talk to a stateless service, your message will be delivered to a random instance. The proxy will keep track of healthy instances for you, and deal with transient errors.
I have a Service Fabric Application which consists of two services. Both are stateless services and have a single instance of the services.
In Service A, I would like to define a Endpoint in the Resources section of the ServiceManifest.xml. I don't care what port I get, I just need one and I'd like to get it from Service Fabric so it can ensure it's accessible between the vms managed by the Service Fabric cluster.
In Service B, I'd like to pass the port created for Service A so it can use it to interact with the Service A. I will be defining both services with Service Fabric DNS names, so Service B will know the host of Service A (regardless of where it's running). But Service B also needs to the port that was created for Service A (via it's Endpoint declaration). Is that information passed to the Services? Can it be passed as a parameter, or is there another mechanism.
Thanks for any help
You can discover information about the endpoints of the other service by using the QueryManager on the FabricClient. Example here.
Out of curiosity, can't you use SF remoting for this?
Currently in our project, we have few Stateless and Stateful services and then we have an API (which is again a Stateless service). Our API service is exposed over http and run of frontEnd Nodes in cluster. Any client from outside hits the WebAPi stateless service, which inturn can call other services via SF remoting. But other services are not exposed over HTTP. and individual services also can call each other via SF remoting.
As a part of a new requirement, there are some other services hosted in other cloud (Openshift) needs to access our Stateless and Stateful services directly (i.e. without the WebAPI service) over REST. I understand that we can expose our Stateless and Stateful services over http, by writing our own custom HttpCommunicationListener (which should implement "ICommunicationListener"). But apart from this I guess, we would need to configure some reverse proxy and Load Balancer stuff etc, to ensure that one URL works for all the requests.
Is this something, which can be achieved. If yes, can somebody points me to any documentation or code sample ?
I recommend having a look at Traefik as a reverse proxy and load balancer.
You can run it as a (containerized) ingress routing service inside the cluster, and direct HTTP calls to your services.
Here's the documentation.
Here's how to get started.
Here's an example.