I was interested in creating a new load balancer for my WCF Service which is deployed on my Azure Account. While creating it, I saw "Load Balancing Methods". I let the default one which is called "Performance". May I have some information on which one should I choose, what are the purposes of those Methods?
Here's a screenshot which can describe better what I'm actually interested in.
Related
I'm fairly new to the realm of microservices but know basics about load balancing. I recently read an article about the microservices: Enough with the microservices.
There it's mentioned that both the microservices and load balancers have clusters/different VM's for deploying many copies of application but in the case of microservices, we have a separate database in contrast to load balancers which backs a single database. Is it the only difference between them?
Here's the quoted text:
"multiple copies of the same microservice can be deployed in order to
achieve a form of scalability. However, most companies that adopt
microservices too early will use the same storage subsystem (most
often a database) to back all of their microservices. What that means
is that you don’t really have horizontal scalability for your
application, only for your service. If this is the scalability method
you plan to use, why not just deploy more copies of your monolith
behind a load balancer? You’ll accomplish the same goal with less
complexity."
You can not compare Micro-services with load balancer... you should compare it with monolithic or SOA architecture.
In monolithic approach you mainly have only one database for the whole system and a monolithic application as a single project for your business.
monolithic is single unit But SOA is a coarse-grain approach and Microservice is fine-grain approach. In microservice architecture instead of designing a monolithic system you design different micro-services around your business capabilities and base on your domain and bounded-context.
each micro-services may have their own database. for e.g. order micro-service may have mysql database, recommendation micro-service may have Cassandra database and user-search micro service may have Elasticsearch or SOLR database.
In microservices each micro-service can talk to another base on two different communication style:
Sync (Rest is suggested)
Async (via message brokers like Kafka, RabbitMQ, ActiveMQ or NATS
and etc.)
Scaling up-down in micro-services architecture is much easier than monolithic systems and you can even change a part of system and redeploy it independently without affecting the whole system.
Also micro-services adhere to let-it-crash paradigm and with using EIP patterns like Circuit-Breaker you can let user think system is always up and working and Base on CAP theorem you can have high-available system by compensating for consistency and having Eventual Consistency according to BASE instead of ACID
For load balancing Client-side Load Balancing with Ribbon devised by Netflix is very viable approach.
Also with using NginX, Docker Swarm and kubernetes you can implement load balancing.
In a nutshell there is nothing to do about comparing Microservices with Load balancer.
Here's the (hopefully) simplest answer to your question:
Microservices are a different (micro-) application each. Each with its own application logic and database.
Load Balancers are usually used to distribute client requests to a cluster of instances of the same application.
That means: You can also use a load balancer to distribute requests for a microservice that is deployed in a cluster with many instances. But a load balancer can also be used to distribute requests to many instances of a large monolithic application (as opposed to micro).
The probably best overview for what Microservices are supposed to be.
I am currently evaluating solutions for WCF Webservice HA with load balancing. I see 2 feasible approaches for the type of WS i am authoring which are
1) Using the RoutingService API / Class provided by .NET
2) Using a HTTP load balancer like nginx.
Which one is a better approach for WCF WS hosted on IIS.
It depends on a lot of factors. The main one being, is the load balancing requirement a pure availability/scalability driven requirement or is it a business requirement?
If you simply require scale, eg a round robin distribution, or high availability, eg. active/passive failover, and you already have a network load balancer in front of your servers, then I would definitely use that.
The simple reason is that then it will be looked after by your infrastructure people, which is how it should be. Load balancing for scale/availability etc is not normally a development concern.
However, if you have a requirement for routing based on message content, eg routing of high priority calls to one endpoint only, or meeting call processing SLAs for different content, then this becomes a business requirement, because routing logic will then be determined on the business context of the call.
This most definitely is a development concern. In this instance I would certainly use the routing service to implement these various business cases.
Hope this helps you.
We have WCF service X: deployed on server A and Server B, host address:
http://127.0.0.1:8777/ServiceX/
And we load balance the two servers. We accesss the service via http://myappserver/ServiceX
We need to use per-session mode, and we set [reliable sessions] as true:
We don't find any issue till now based on testing. But the below linked MSDN article says that Do not use reliable sessions for Load Balancing with the WSHttp Binding? Please can someone give more details? Thanks a lot.
WCF Load Balancing http://msdn.microsoft.com/en-us/library/ms730128.aspx
Reliable Messaging means all your messages from your established client reach the same endpoint behind any intermediaries like routers and load balancers.
Load balancing means your calls will be distributed across all nodes as the load balancer sees fit.
Those two goals are mutually exclusive. You can have one or the other, not both.
I have not had time to try this myself yet, but I found this old blog entry (https://blogs.msdn.microsoft.com/drnick/2007/07/13/sticky-sessions/):
This division according to groups would allow a feature like reliable messaging to work because the same server would be used to process all of the messages in the reliable session. The feature that this division method represents is typically called “sticky sessions” or some other phrase for affinitization in the load balancer.
Given that you mention that your firewall supports sticky sessions, I suspect/hope you will be fine.
I am working on a very big project of social networking in YII framework where the load balancing is very important issue that is arising.
What I need is :
I want to keep all the three layers ( models, views, controllers) on different EC2 amazon servers so that load balancing can be done in an efficient way.
What can I do for that in YII ?
Any help ?
For your load balancing you should not seperate the application on 3 different instances.
You should have the same app (with all the models, views and controllers) on several servers and then depending on each server's CPU and RAM usage the load balancer will redirect the end user on the appropriate server.
I don't even know if separate the app is doable, and if it is the user will have to wait much longer:
The front controller will call some models => One or several calls to the model server = some time
The front controller have to send the datas to the view => more time
At the end the user will have waited more than on a loaded server!
I'd highly recommend Amazon's Elastic Beanstalk service, as I'm using it for a project I'm developing which is also based on the Yii Framework.
The solution i use, is to deploy my application on 3 servers and keep them in sync from a deployment server with rsync. My static content comes from a 4rth server, but that would put all your code on 3 servers, as 3 exact clones. Imo this is the best because with amazone you can just spawn more clones if you need to scale your balancing.
Load balancing means that you will server a portion of the users on 1 server and another portion on a 2nd server and so on..
But if you split up your models/controllers/views you do not understand what load balancing is about.
I would like to create a service whose job is to monitor other services that are running within the same process, and then report basic information like health or service dependencies. I'm having trouble figuring out the best way for my monitoring service to access detailed information about the other services without having to have each service publish its metadata or expose some custom endpoint the monitoring service can communicate with. If I load the configuration and read through it I can get most of the way there but this approach has a few weaknesses:
Getting the absolute URI for each endpoint can be difficult,
especially when using IIS hosting or fileless activation.
Any configuration that was done programmatically would not be able to be read by the monitoring service
What I'd like to be able to do is to somehow access the ServiceDescription to get all the information I need about each ServiceHost, without requiring any work on the part of the service designer to give it to me. Is something like this possible?
If you've checked Channs links and are convinced you need to roll your own health monitoring infrastructure, you'll probably need to either derive from ServiceHost or go all out and derive from ServiceHostFactoryBase or possibly do both depending on what you need to implement. They'll give you access to the ServiceDescription instance for each service as it is spun up.
One alternative would be to use WCF's built-in health monitoring and performance monitoring capabilities. This works at the individual service level though.