Recently I started working on an old Azure cloud based micro service project, which is running on Azure Service Fabric platform.
(I'm new to this platform, also I don't have team members for discussion. I can read the code and document to understand this project.)
I roughly understand how Service Fabric works. But one question confuses me a lot about inter service communications. I want to know which inter service communication solution my project is using.
Here are some useful information about this point:
Suppose the Azure Service Fabric cluster endpoint is as follows: myTestCluster.westus.cloudapp.azure.com:19000
The project use Consul for service discovery. In the codebase, before sending request to other services, first need to get the registered URL from consul. And the URL resolved from Consul is something as follows: myTestCluster.westus.cloudapp.azure.com:23333, which is another service deployed and run on the cluster. The code for sending request is something like:
using (var client = new HttpClient())
{
var response = await client.PostAsync(uri); // uri is resolved from Consul
return await response.Content.ReadAsStringAsync();
}
I read some article and know that the potential inter-service communication methods are:
Service Fabric's Naming service: based on the method I shown above, I think it's not this one.
Reverse proxy
DNS service
But I can't tell out method 2 or 3, which one is used. Or any other ones?
Related
Currently we have a configuration of two Azure SignalR services and two web app services that are configured with the two signalr services (below code). My question is whether ServerStickyMode is required since the documentation is confusing, we have documentation that says its mostly not required since we are using a Azure SignalR service and a post that says it is required, I ran into issues with it disabled it does not work all the time, just intermittently, so it really is required. Would the amount of instances (sku units) also affect ServerStickyMode?
*Not Required?
https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-7.0#azure-signalr-service
"The only circumstances in which sticky sessions are not required are:"
When using the Azure SignalR Service.
"Sticky sessions, also known as client affinity, is not required, because clients are immediately redirected to the Azure SignalR Service when they connect."
*Required?
https://devblogs.microsoft.com/dotnet/whats-new-in-azure-signalr-1-1-0-preview-1/#:~:text=Also%20when%20sticky%20mode%20is%20enabled%2C%20service%20won%E2%80%99t,only%20enable%20it%20when%20there%20is%20a%20need.
"The typical connection flow when using SignalR service is that client first negotiates with app server to get the url of SignalR service, then service routes client to app server.
When you have multiple app servers, there is no guarantee that two servers (the one who does negotiation and the one who gets the hub invocation) will be the same one.
We hear a lot of customers asking about whether it’s possible to make the two servers the same one so they can share some states between negotiation and hub invocation. In this release we have added a new “server sticky mode” to support this scenario.
To enable this, you just need to set ServerStickyMode to Required in AddAzureSignalR():"
Any help would be appreciated.
.AddSignalR().AddAzureSignalR(options =>
{
options.Endpoints = new[]
{
new ServiceEndpoint(configuration["SignalRConnectionStringPrimary"],
EndpointType.Primary, "Primary"),
new ServiceEndpoint(configuration["SignalRConnectionStringSecondary"],
EndpointType.Primary, "Secondary")
options.ServerStickyMode = ServerStickyMode.Disabled;
};
I am expecting that any published data on SignalR will be received by the subscribers.
We use Azure Service Fabric with Reliable Services and Actors, the IoTHub and Web Apis and are currently integrating "Transient Fault Handling" (TFH) to deal with errors during (remote) communication of services.
For Azure Storage and SQL it is already implemented, we use the built-in retry policies for that and it works fine.
But what about the Service Fabric internal communication? There are also services, communicating via a remoting mechanism.
Here are my questions:
Do we need to handle transient faults for the communication between Reliable Services and Reliable Actors in Service Fabric?
If so - how could this be done? Is the Transient Fault Handling Application Block the only way to implement retry policies for the internal communication?
If not - how does Service Fabric handle transient faults?
Additional information I already gathered:
This article about communication between services describes a typical fault-handling retry pattern for the inter-service communication. But instead of ICommunicationClientFactory and ICommunicationClient, we use Service Remoting for that. I could not figure out, how to use this typical fault handling with Service Remoting.
Late answer, but maybe people are still looking for answers... Anyhow, Service Fabric has default transient fault handling (and non transient fault handling as well). Via the OperationRetrySettings you can customize these. You can also customize other properties via the TransportSettings. Here is an example how you can customize these settings:
FabricTransportSettings transportSettings = new FabricTransportSettings
{
OperationTimeout = TimeSpan.FromSeconds(30)
};
var retrySettings = new OperationRetrySettings(TimeSpan.FromSeconds(15), TimeSpan.FromSeconds(1), 5);
var clientFactory = new Microsoft.ServiceFabric.Services.Remoting.FabricTransport.Client.FabricTransportServiceRemotingClientFactory(transportSettings);
var serviceProxyFactory = new Microsoft.ServiceFabric.Services.Remoting.Client.ServiceProxyFactory((c) => clientFactory, retrySettings);
var client = serviceProxyFactory.CreateServiceProxy<IXyzService>(new Uri("fabric:/Xyz/Service"));
return client;
hth //Peter
I have been researching Azure's Service Fabric Reliable Services and looking at the samples too.
I am now building a simple proof-of-concept application with a recommended setup: A stateless Web API service with a stateful service behind (1 partition).
I've been going round in circles trying to find the easiest way for the API service to talk to the stateful service behind. It looks like the stateful service will have to exposed using Web API too (as shown in the example WordCount app).
Am I correct thinking that in order to consume a stateful service it needs to expose itself via HTTP/WCF etc. using something like OwinCommunicationListener : ICommunicationListener from the examples?
When the services lives inside the same app, you can access the service instance something like:
public static MyServices.Interfaces.IMyStatefulService GetMyStatefulService()
{
var proxyLocation = new ServiceUriBuilder("MyStatefulService");
var partition = new ServicePartitionKey(1); //provide the partitionKey for stateful services. for stateless services, you can just comment this out
return ServiceProxy.Create<MyServices.Interfaces.IMyStatefulService>(proxyLocation.ToUri(), partition);
}
ServiceProxy is from the Microsoft.ServiceFabric.Services.Remoting.Client namespace.
And you interface code will look something like:
public interface IMyStatefulService : IService
{
Task<MyResponseResult> DoSomething(MyRequest request);
}
If the Stateful and Stateless service are in the same cluster (In your case i assume that both services are in the same application type (same solution) ), You can call the Stateful service from Stateless service Using 'Service Proxy'
If you want to consume the stateful service from outside the cluster, you need to open an API communication listener.
ServiceProxy class is available from "Microsoft.ServiceFabric.Services".
Service Proxy only works within the same cluster.
usage
IServiceClass proxy = ServiceProxy.Create<IServiceClass >(new Uri(fabric:/your_service));
In order to proxy to works, the Methods in the stateful service needs to be exposed using an Interface.
Service Fabric was just announced at the build conference. I was reading the scarce documentation about it and I have a question.
I'm evaluating Service Fabric for hosting CRUD like microservices that are at the moment built in ASP.NET WebApi.
Is Service Fabric geared towards hosting small pieces of functionality that receive data, process it and return the result, rather than hosting CRUD WebApi types of application?
Service Fabric enables the creation of both stateless and stateful microservices.
As the name suggests, any state maintained by an an instance of a stateless service will be lost if the node goes down. A new, fresh instance will simply be spun up elsewhere in the cluster.
Stateful services offer the ability to persist state without relying on an external store. Any data stored in a Reliable Collection will be automatically replicated across multiple nodes in the cluster, ensuring that the state is resilient to failures.
A common pattern is to use a stateless service as the client-facing gateway to the application and then have that service direct traffic to the app's partitioned stateful services. This hides the work of resolving partitions from clients, allowing them to to target one logical endpoint with all requests.
Take a look at the WordCount sample for an example of how this works. The WordCount.WebService stateless service acts as the front end to the application. It simply resolves the partition based on the incoming request and then sends it on. The WordCount.Service stateful service (partitioned based on the first letter of the word) immediately puts those incoming requests in a ReliableQueue and then processes them in the background, storing the results in a ReliableDictionary.
For more details, see the Reliable Services Overview.
Note: for now, the best way to expose WebAPI endpoints to clients is to self-host an OWIN server in the stateless service. ASP.NET 5 projects will soon be supported as well.
This video answers my own question: http://channel9.msdn.com/Events/Build/2015/2-704. In summary, we should use Stateless Services to host ASP.NET based sites or API's which persist data to external data stores.
If you don't have state (or have it externally), Stateless Service is the way to start.
Answer to the original question is "both". Basically, anything that have main() function (with couple of more extended contract methods to talk to Service Fabric) can be a service in Service Fabric world.
We are looking to use Windows Azure to host our existing SaaS platform and extend our functionality and capability. WE will be taking adavantage of both the data storage and application and web service functionality of Azure.
My question is as follows:
Some of our clients will not want Public CLoud access. Since our datastore stores sensitive client data many of them will require our whole system to be hosted internally on their own network and servers.
If we setup a full Azure setup of database and connected applications and processes how difficult is it to be able to duplicate that system for a specific client on their own servers and network using existing Microsoft technologies?
I know its a vague question and I also have a liminted understanding of Azure so whatever information you can provide here would be most appreciated.
Thank you
It sounds like you need the flexibility of a hybrid cloud/on-prem solution. Likely the best solution is the Windows Azure Service Bus. Essentially, you configure a WCF web service in the cloud (SOAP, REST, etc) that performs asynchronous brokered messaging between your on-premise application and your web application. This can be performed using queue messages, for example:
The web application (cloud) requests resources from the brokering service (cloud) by sending a queue message
The service handles the queue message and makes it available to the consuming (on-prem) service
On-prem service checks for new messages from the brokering service, gets the request for data, and returns desired data from DB
On-prem service sends message to brokering service with desired data
Web app (cloud) checks for new messages from the brokering service, then uses the data from on-prem service
Service bus is secure, asynchronous, fault-tolerant, and ensures that both components are decoupled.
Another method is to use Windows Azure Connect, which is a VPN solution that sets up network-level connnectivity. I recommend Service Bus because it promotes a more robust and scalable architecture, and fault-tolerance is high.