Software Architectures, Week 4 - Message-based Architectures, Message Bus
-
Upload
angelos-kapsimanis -
Category
Documents
-
view
100 -
download
0
Transcript of Software Architectures, Week 4 - Message-based Architectures, Message Bus
![Page 1: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/1.jpg)
Message-based Architectures
Week 4
![Page 2: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/2.jpg)
Distinction of systems in comms patterns
• Distributed systems (microservice-based systems belong to them) need well defined and efficient methods for communications.
• There are many different architectural patterns which specify the communications between the components of a distributed system.
• They can be classified to two broad categories: • Event-based• Message passing
![Page 3: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/3.jpg)
Event-based systems• The control flow is determined by events like user actions, sensory
input or requests from other systems.
• Usually there is a main loop which listens for events and triggers the appropriate callback function.
• Used predominantly for GUI-centered applications.
![Page 4: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/4.jpg)
Event-based systems (cont.)
Is the MVC pattern an event-based pattern?
Are web applications web based?
![Page 5: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/5.jpg)
Is the MVC pattern an event-based pattern?
Short answer: Yes
![Page 6: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/6.jpg)
Is the MVC pattern an event-based pattern?
Credit: MIT
![Page 7: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/7.jpg)
Are web applications web based?
Short answer: Yes
![Page 8: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/8.jpg)
Are web applications event-based?
Nearly all of them
![Page 9: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/9.jpg)
Pros and Cons of event based systems
• Pros• Very reliable when the producer doesn't need to know who is the consumer
or vice versa. • Simpler communication patterns. • Systems can be dynamically composable (e.g. via plugins)
at runtime without strict contracts.
• Cons• Becomes very complex for large scale applications.• Can end up in 'callback hell'.
![Page 10: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/10.jpg)
Interesting project: P Language
Source: https://www.microsoft.com/en-us/research/publication/p-safe-asynchronous-event-driven-programming/
![Page 11: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/11.jpg)
P Language• A system comprises from a set of interacting state machines.
• Compiled and verifiable with model checking.
• It is ensured that events can not be deferred.
• The new USB device driver in Windows 8 is written in 8.
• Open-sourced for IoT and embedded applications.
![Page 12: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/12.jpg)
Message passing based systems• Based on messages being send from one process to another one.
• The recipient process can decide how to respond to the message.
• It separates invocation from implementation, where encapsulation plays a fundamental role.
• Synchronous vs asynchronous
• Usually implemented via actors or channels (π-calculus).
![Page 13: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/13.jpg)
Message passing based systems (cont.)
• Prominent actor-based languages: • Erlang • Scala • Smalltalk
• Prominent channel-based languages:• Go
![Page 14: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/14.jpg)
Pros and Cons of message based systems
• Pros• Very suitable for systems where producers and consumers are very well
known.• It adds security, e.g. if you write a credit-card processing system, you do want
to know to whom you talk to.
• Cons• Requires more thorough design, semantics need to be specified in advance.• May require schema versioning.
![Page 15: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/15.jpg)
Message Exchange Pattern TypesThere are many variations of MEP. These are:
• In-Only• Robust In-Only• In-Out• In-Optional-Out• Out-Only• Robust Out-Only• Out-In• Out-Optional-In
![Page 16: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/16.jpg)
In-Only
Sender(ATM)
Recipient(Account)
account_withdraw, 10
%%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount} -> {res, amount} = withdraw(amount) % from db end.
%%% main.erlATM = fun(account, amount) -> account ! amount end.spawn(ATM).
Account = spawn(Account, toms_account, []).
ATM(Account, 10). % returns nothing
![Page 17: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/17.jpg)
Robust In-Only
Sender(ATM)
Recipient(Account)
account_withdraw, 10
ok | err
%%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount} -> {res, amount} = withdraw(amount) % from db sender ! res end.
%%% main.erlATM = fun(account, amount) -> account ! amount end.spawn(ATM).
Account = spawn(Account, toms_account, []).
ATM(Account, 10). % returns ok
![Page 18: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/18.jpg)
In-Out
Sender(ATM)
Recipient(Account)
account_withdraw, 10
{ ok, 2990 }
%%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount} -> {res, amount} = withdraw(amount) % from db sender ! {res, amount} end.
%%% main.erlATM = fun(account, amount) -> account ! amount end.spawn(ATM).
Account = spawn(Account, toms_account, []).
ATM(Account, 10). % returns { ok, 2990 }
![Page 19: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/19.jpg)
In-Optional-Out
Sender(ATM)
Recipient(Account)
account_withdraw, 100000
%%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount} -> {res, amount} = withdraw(amount) % from db case res of ok -> sender ! {res, amount} Error -> io:format("let forget it :-)") end.
%%% main.erlATM = fun(account, amount) -> account ! amount end.spawn(ATM).Account = spawn(Account, toms_account, []).
ATM(Account, 10). % returns nothing
{ ok, 2990 }
![Page 20: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/20.jpg)
Out-Only
Consumer(Mobile Banking
App)
Recipient(Account)
bill_withdraw
%%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount, app_id} -> {res, amount} = withdraw(amount) % from db app_id ! bill_withdraw end.
%%% main.erlVattenfall = fun(account, amount) -> account ! amount end.spawn(Vattenfall ).
IPhone = fun(msg) -> io::format(msg) end. spawn(IPhone).
Account = spawn(Account, toms_account, []).Vattenfall (Account, 10). % IPhone prints bill_withdraw
Vattenfall(Account)
account_withdraw, 10
![Page 21: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/21.jpg)
Robust Out-Only
Consumer(Mobile Banking
App)
Recipient(Account)
err
%%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount, app_id} -> {res, amount} = withdraw(amount) % from db case res of ok -> app_id ! bill_withdraw error -> app_id ! error end.%%% main.erlVattenfall = fun(account, amount) -> account ! amount end.spawn(Vattenfall ).IPhone = fun(msg) -> io::format(msg) end. spawn(IPhone).Account = spawn(Account, toms_account, []).Vattenfall (Account, 10). % IPhone prints bill_withdraw
Vattenfall(Account)
account_withdraw, 100000
![Page 22: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/22.jpg)
Out-In
Consumer(Mobile Banking
App)
Recipient(Account)
bill_withdraw, 150 %%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount, app_id} -> {res, amount} = withdraw(amount) % from db case res of ok -> app_id ! bill_withdraw error -> app_id ! error end.%%% main.erlVattenfall = fun(account, amount) -> account ! amount end.spawn(Vattenfall ).IPhone = fun(msg) -> io::format(msg) end. spawn(IPhone).Account = spawn(Account, toms_account, []).Vattenfall (Account, 10). % IPhone prints bill_withdraw
Vattenfall(Account)
account_withdraw, 150
need_to_cut_waste
![Page 23: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/23.jpg)
Out-Optional-In
Consumer(Mobile Banking
App)
Recipient(Account)
bill_withdraw, 150 %%% account.erl-module(account).
check_balance(sender, msg) -> receive {account_withdraw, amount, app_id} -> {res, amount} = withdraw(amount) % from db case res of ok -> app_id ! bill_withdraw error -> app_id ! error end.%%% main.erlVattenfall = fun(account, amount) -> account ! amount end.spawn(Vattenfall ).IPhone = fun(msg) -> io::format(msg) end. spawn(IPhone).Account = spawn(Account, toms_account, []).Vattenfall (Account, 10). % IPhone prints bill_withdraw
Vattenfall(Account)
account_withdraw, 150
response
![Page 24: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/24.jpg)
Enough! Anything ready to use?
• ØMQ
• RabbitMQ
• ActiveMQ
• Kafka
![Page 25: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/25.jpg)
Easiest Start - ØMQ
• A socket on steroids• Super fast• Available in a multitude of languages• Supports MEP and even more• Request – Reply• Publish – Subscribe• Push – Pull• Exclusive Pair
![Page 26: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/26.jpg)
ØMQ Request - Replyrequire 'rubygems'require 'ffi-rzmq'
context = ZMQ::Context.new(1)puts "Starting Hello World server…"
# socket to listen for clientssocket = context.socket(ZMQ::REP)socket.bind("tcp://*:5555")while true do # Wait for next request from client request = '' rc = socket.recv_string(request) puts "Received request. Data: #{request.inspect}" # Do some 'work' sleep 1 # Send reply back to client socket.send_string("world")end
![Page 27: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/27.jpg)
ØMQ Push - Pull
• Ideal for delegating workload to worker threads.
• It can simplify asynchronous computation.
• Essentially a simple DAG (directed acyclid graph).
![Page 28: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/28.jpg)
ØMQ Exclusive Pair
• It can ensure the correct order of execution on a batch of data.
• Easier to ensure correctness of execution and validitiy of data.
• Can become overly complicated easily.
• Difficult to scale.
![Page 29: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/29.jpg)
How far can we go with ØMQ?
• Really far!• Openstack uses it for messaging between cluster nodes.• It has been scaled up to 168.000 cloud instances.
![Page 30: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/30.jpg)
How far can we go with ØMQ? (cont.)
• It is also very popular in HFT applications, where it has been optimized heavily.
![Page 31: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/31.jpg)
Kafka
![Page 32: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/32.jpg)
Not Franz Kafka, Apache Kafka
![Page 33: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/33.jpg)
What is kafka?• A distributed message queue.
• A high-throughput, low-latency platform handling real-time data feeds.
• A message bus.
![Page 34: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/34.jpg)
Message Bus Pattern
![Page 35: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/35.jpg)
'just' a smart pipe
![Page 36: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/36.jpg)
LinkedIn's perception of Kafka
https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
![Page 37: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/37.jpg)
Kafka Topics / Logs
• The most fundamental abstraction in Kafka, an ordered sequence of records ordered by time.
![Page 38: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/38.jpg)
Text durch Klicken hinzufügen
Distributed Topics
Credit: Cloudera
![Page 39: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/39.jpg)
Log-structured data flow• Multiple readers can subscribe to a log and receive the same
information, creating a small Message Bus.
![Page 40: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/40.jpg)
Flows can be very extensive and form DAGs
![Page 41: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/41.jpg)
DAGs are the basis for flow-based programming
![Page 42: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/42.jpg)
What is flow-based programming (FBP)?
• A programming paradigm that uses a "data factory" metaphor for designing and building applications. • FBP defines applications as networks of "black box" processes, which
exchange data across predefined connections by message passing, where the connections are specified externally to the processes.• These black box processes can be reconnected endlessly to form
different applications without having to be changed internally. FBP is thus naturally component-oriented.
![Page 43: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/43.jpg)
NoFlo
![Page 44: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/44.jpg)
NoFlo (cont.)
![Page 45: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/45.jpg)
Cloud Dataflow
![Page 46: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/46.jpg)
System responsibility can be easily distributed
![Page 47: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/47.jpg)
Advantages of the message bus• Decoupling. Producers and consumers are independent and can evolve and innovate seperately at
their own rate. • Redundancy. Queues can persist messages until they are fully processed.• Scalability. Scaling is acheived simply by adding more queue processors. • Elasticity & Spikability. Queues soak up load until more resources can be brought online. • Resiliency. Decoupling implies that failures are not linked. Messages can still be queue even if there's a
problem on the consumer side.• Delivery Guarantees. Queues make sure a message will be consumed eventually and even implement
higher level properties like deliver at most once.• Ordering Guarantees. Coupled with publish and subscribe mechanisms, queues can be used message
ordering guarantees to consumers.• Buffering. A queue acts a buffer between writers and readers. Writers can write faster than readers
may read, which helps control the flow of processing through the entire system. • Understanding Data Flow. By looking at the rate at which messages are processed you can identify
areas where performance may be improved. • Asynchronous Communication. Writers and readers are independent of each other, so writers can just
fire and forget will readers can process work at their own leisure.
![Page 48: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/48.jpg)
A Showcase: Kafka in Linkedin• The company's cornerstone in transfering high-velocity data.• When combined, the Kafka ecosystem at LinkedIn is sent over 800
billion messages per day which amounts to over 175 terabytes of data• Over 650 terabytes of messages are then consumed daily.• At the busiest times of day, over 13 million messages per second are
received, or 2.75 gigabytes of data per second. • To handle all these messages, LinkedIn runs over 1100 Kafka brokers
organized into more than 60 clusters.
![Page 49: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/49.jpg)
Linkedin's data platform before
![Page 50: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/50.jpg)
and after
![Page 51: Software Architectures, Week 4 - Message-based Architectures, Message Bus](https://reader035.fdocuments.in/reader035/viewer/2022062400/587784531a28abc85f8b61a9/html5/thumbnails/51.jpg)