Been getting into some different technologies but keep getting hung up on Service Bus, specifically Azure Service Bus and what the different components do. Queues, subscriptions, topics, etc…
​
Thanks!
In: 2
These are components of a service oriented architecture (SOA). This is a system where a number of independent services work together to create a complete application. For example authentication may be one service, authorization another, notifications, searching, etc. Some of these may be microservices while others are more macroservices and provide multiple features. Connecting all these services together is the enterprise service bus. The services will publish messages to the bus which will then send and transform them as needed. Typically each published message would have a topic and all subscribers to that topic gets a copy of the message. Because the subscribers may not check for new messages until it is ready the message gets put into a queue so it can be retrieved in a timely manner.
Think about a stereotypical cartoon office worker’s desk. There’s usually a box for papers labeled “IN” and a box for papers labeled “OUT”. In that kind of office, there are workers who periodically walk around and place new paperwork in the “IN” box while retrieving finished paperwork from the “OUT” box.
That worker and the boxes are a good metaphor for what service buses and queues do.
One way to design software is to make a “monolith”. That means you put all of the program code that does your work inside one program that runs on one machine. Another way to design software is to make a “distributed system”. That means you have many computers, each might be running a small program that does only one thing, and the computers are networked together.
Monoliths don’t need service buses or message queues because there’s one big program and it can handle sending data where it belongs. This doesn’t work well under heavy loads and it’s hard to solve the problem by adding new machines because one monolith can’t share data with another monolith.
But if you think about distributed systems, obviously they need tools that understand where data goes when any given part of the system finishes work. The service bus/message queue is a part of the system every part of the system knows about. When a worker finishes some work, they put it in the queue. The service bus understands when it gets that work where it should go and moves it to the right place.
Sometimes work comes “in” faster than it can go “out”. For example, people might send in big videos for Youtube to encode faster than Youtube can encode them. That’s the “queue” part. The parts of Youtube that accept uploads do their work then tell the queue, “I have a video to encode.” Youtube’s equivalent of a queue/service bus might note all encoding machines are busy, so they just hold on to the new video. When some encoding machine gets free, it tells the service bus, “Hey, I finished my work, is there any more?” and the service bus says, “Yes, can you encode this video from my queue?”
That makes it a lot easier to build systems where you can use a small number of computers when there isn’t a lot of demand then quickly add new computers when there is heavy demand. It’s easier to tell the service bus, “Hey, there are 100 new machines that can encode video, here’s their addresses” than it is to teach a monolith the same thing.
Latest Answers