Microservices for a Streaming World
12 likes9,938 views
The document discusses the advantages and challenges of building microservices in a streaming world, emphasizing loose coupling, autonomy, and scalability. It highlights the importance of distributed systems, particularly in stream processing, and presents patterns like event-based communication and the use of message brokers for fault tolerance and ordering guarantees. The text also compares centralized and decentralized approaches, advocating for decentralized tools to effectively manage data in microservices architectures.
Microservices for a Streaming World
- 1. Microservices in a Streaming World
- 2. There are many good reasons for building service-based systems • Loose Coupling • Bounded Contexts • Autonomy • Ease of scaling • Composability
- 3. But when we do, we’re building a distributed system
- 4. This can be a bit tricky
- 5. Monolithic & Centralised Approaches Shared, mutable state
- 8. Stream Processing is a bit different batch analytics => real time => at scale => accurately
- 9. and comes with an interesting toolset
- 11. Some fundamental patterns of distributed systems
- 14. Event Driven Async / Fire and Forget
- 15. Event Based • Simple • Synchronous • Event Driven • Good decoupling • Requires Broker • Fire & Forget • Polling • Full decoupling Request/Response vs.
- 16. SOA / Microservices Message Broker Event Based Request/Response
- 18. Combinations Withdraw £100 Account Service General Ledger Customer Statements Fraud Detection Check Funds Async Message Broker I need moneyReST
- 19. Services generally eschew shared, mutable state
- 20. How do we put these things together?
- 21. Request/Response
- 25. Queues
- 26. Point to Point Service A Service B
- 27. Load Balancing Instance 2 Instance 1 Single message allocation has scalability issues
- 28. Batched Allocation Instance 1 Instance 2 Throughput!
- 29. Lose Ordering Guarantees Fail! Instance 1 Instance 2
- 30. Topics
- 31. Topics are Broadcast Consumer Consumer Broker broadcast
- 32. Topics Retain Ordering Trades Buys Sells Broker Instance 1 Instance 2
- 33. Even when services fail Trades Buys Sells Fail! Broker We retain ordering, but we have to detect & reprovision Instance 1 Instance 2
- 35. Queues Lose Ordering Guarantees at Scale Fail! Worker 1 Worker 2
- 38. Is there another way?
- 39. A Distributed Log Kafka is one example
- 40. Think back to the queue example Batch Batch
- 41. Shard on the way in
- 42. Each shard is a queue Strong Ordering (in shard). Good concurrency.
- 43. Each consuming service is assigned a “personal set” of queues each little queue is sent to only one service in a group
- 44. Services instances naturally rebalance on failure Service instance dies, data is redirected, ordering guarantees remain
- 45. Very Scalable, Very High Throughput Sharded In, Sharded Out
- 46. Reduces to a globally ordered queue
- 47. Fault Tolerance
- 48. The Log Single seek & scan Append only messages don’t need to be transient!
- 49. Cleaning the Log Delete old segments
- 50. Cleaning the Log Delete old versions that share the same key K1 K1 K1 K2 K2 K2 K1 V1 V1 V2 V3 V2 V4 V3
- 51. • Scalable multiprocessing • Strong partition-based ordering • Efficient data retention • Always on
- 52. So how is this useful for microservices?
- 53. Build ‘Always On’ Services Rely on Fault Tolerant Broker
- 54. Load Balance Services Load Balance Services (with strong ordering)
- 55. Fault Tolerant Services Services automatically fail over (retaining ordering)
- 56. Services can return back to old messages in the log Rewind & Replay
- 58. Lets take a little example
- 59. Getting Exchange Rates Exchange Rate Service USD/GBP = 0.71 EUR/GBP = 0.77 USD/INR = 67.7 USD/AUD = 1.38 EUR/JPY = 114.41 … I need exchange rates!
- 60. Option1: Request Response rate for USD/GBP? 0.71 Exchange Rate Service I need exchange rates!
- 61. Option 2: Publish Subscribe Exchange Rate Service Accumulate current state ETL I need exchange rates!
- 62. Option 3: Accumulate in Compacted Stream Exchange Rate Service Get all exchange rates Publish to clients USD/GBP = 0.71 EUR/GBP = 0.77 USD/INR = 67.7 USD/AUD = 1.38 EUR/JPY = 114.41 … Broker retains latest versions Publish all rate events
- 63. Is it a stream or is it a table? transitory stateful
- 64. Datasets can live in the broker! trades books risk results ex- rates
- 65. Service Backbone Scalable, Fault Tolerant, Concurrent, Strongly Ordered, Stateful
- 66. … lets add in stream processing
- 67. Max(price) From orders where ccy=‘GBP’ over 1 day window emitting every second What is stream processing? Continuous Queries.
- 68. What is stream processing engine? Data Index Query Engine Query Engine vs Database Finite, well defined source Stream Processor Infinite, poorly defined source
- 69. Windowing For unordered or unpredictable streams Sliding Fixed (tumbling)
- 70. Features: similar to database query engine JoinFilter Aggr- egate View Window
- 71. KStreams & KTables stream Compacted stream Join Streaming Data Stored Data KStream KTable
- 73. Buying Lunch Abroad Payments Service Exchange Rates Service Buy Notification Service Amount in ££ $$ $$ Text Message: ££ $$
- 74. Request-Response Option Payments Service Exchange Rates Service Buy Amount in ££ Join etc Text Message: ££ Iterative join over the network
- 75. ETL Option Payments Service Exchange Rates Service Buy Amount in ££ ETL ETL Join etc Text Message: ££
- 76. Stream Processor Option Payments Service Exchange Rates Service Buy Stream Processor join etc Text Message: ££
- 77. Buying Lunch Abroad Payments Exchange Rates Looks like a table (compacted stream) Looks like an infinite stream KStream KTable
- 78. Buying Lunch Abroad Payments Exchange Rates • Filter(ccy<>’GBP’) • Join on ccy • Calculate GBP • Send text message buffering
- 79. Local DB (fast joins) Topic Compacted Topic KStream pre-populate
- 80. KTables can also be written to - they’re backed by the broker Manage intermediary state KStream KTable Topic Compacted Topic
- 81. Scales Out (MPP)
- 82. These tools are pretty handy for managing decentralised services
- 83. Talk our own data model Data Stream View Query
- 84. Handle Unpredictability 9am 5pm Late trades
- 86. Duality between Stream and Table Join KStream KTable
- 87. More Complex Use Cases Trades Valuations Books Customers General Ledger
- 88. trades books risk results ex- rates Practical mechanism for managing data intensive, loosely coupled services • Stateful streams live inside the Log • Data extracted quickly! • Fast, local joins, over large datasets • HA pre-caching • Manage intermediary state • Just a simple library (over Kafka)
- 89. There is much more to stream processing it is grounded in the world of big-data analytics
- 90. Simple Approaches Just a library (over Kafka)
- 92. Big Global Bag of State in the Sky Problem: No BGBSS
- 93. How to you provide the accuracy of this
- 94. In this?
- 95. Centralised vs Federated Centralised consistency model Distributed consistency model
- 96. One problem is failure
- 97. Duplicate messages are inevitable have I seen this before?
- 98. Make Services Idempotent try 1 try 2 try 3 try 4
- 99. Stream processors have to solve this problem
- 100. Exactly Once not available in Kafka… yet
- 101. So what do we have?
- 103. Queued Delivery System Ordered queue
- 104. Scales Horizontally
- 105. Scales Horizontally
- 106. Scales Horizontally
- 107. Scales Horizontally
- 108. Built In Fault Tolerance
- 109. Runs Always On
- 110. For Services Too
- 113. Scales Horizontally with history stored in the Log
- 114. Scales Horizontally Extending to any number of services
- 115. Scales Horizontally With any data throughput
- 116. Scales Horizontally With any data throughput
- 117. Scales Horizontally With any data throughput
- 118. Scales Horizontally powerful tools for slicing and dicing streams
- 119. Scales Horizontally the declarative processing of data join filter aggregate
- 120. at any throughput
- 122. Scales Horizontally backed up to the log
- 125. trades books risk results ex- rates with data living in the stream
- 126. but retaining loose coupling trades books risk results ex- rates
- 127. Scales Horizontally with strong ordering and repeatability guarantees (eventually)
- 128. so…
- 129. Microservices push us away from shared, mutable state
- 130. Big Global Bag of State in the Sky Away from BGBSS’s
- 131. This means data is increasingly remote
- 132. Sure, you can collect it all copy copy copy copy copy copy copy ETL ETL ETL ETL ETL ETL
- 133. can be a lot of work
- 134. Or you can look it all up get get get get get get get get, get, get, get
- 135. but that doesn’t scale well (with system complexity or with data throughput)
- 137. We need a decentralised toolset to do this trades books risk results ex- rates
- 138. Keep it simple, Keep it moving