Download as PDF, PPTX
Uploaded byBen Stopford
Microservices for a Streaming World
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.
More Related Content
Similar to Microservices for a Streaming World
![[Meetup ms] Kafka Streams](https://cdn.slidesharecdn.com/ss_thumbnails/meetup-mskafkastreams-180704165301-thumbnail.jpg?width=640&height=640&fit=bounds)
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
Microservices for a Streaming World
- 1.
- 2. There are manygood reasons for building service-based systems • Loose Coupling • Bounded Contexts • Autonomy • Ease of scaling • Composability
- 3. But when wedo, we’re building a distributed system
- 4. This can bea bit tricky
- 5. Monolithic & Centralised Approaches Shared,mutable state
- 6.
- 8. Stream Processing is abit different batch analytics => real time => at scale => accurately
- 9. and comes withan interesting toolset
- 10.
- 11. Some fundamental patterns ofdistributed systems
- 12.
- 13.
- 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 MessageBroker Event Based Request/Response
- 17.
- 18. Combinations Withdraw £100 Account Service General Ledger Customer Statements Fraud Detection Check Funds AsyncMessage Broker I need moneyReST
- 19. Services generally eschew shared,mutable state
- 20. How do weput these things together?
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. Point to Point ServiceA Service B
- 27. Load Balancing Instance 2 Instance1 Single message allocation has scalability issues
- 28. Batched Allocation Instance 1 Instance2 Throughput!
- 29. Lose Ordering Guarantees Fail! Instance1 Instance 2
- 30.
- 31.
- 32. Topics Retain Ordering Trades Buys Sells BrokerInstance 1 Instance 2
- 33. Even when servicesfail Trades Buys Sells Fail! Broker We retain ordering, but we have to detect & reprovision Instance 1 Instance 2
- 34.
- 35. Queues Lose Ordering Guaranteesat Scale Fail! Worker 1 Worker 2
- 36.
- 37.
- 38. Is there anotherway?
- 39. A Distributed Log Kafkais one example
- 40. Think back tothe queue example Batch Batch
- 41. Shard on theway in
- 42. Each shard isa queue Strong Ordering (in shard). Good concurrency.
- 43. Each consuming serviceis assigned a “personal set” of queues each little queue is sent to only one service in a group
- 44. Services instances naturally rebalanceon failure Service instance dies, data is redirected, ordering guarantees remain
- 45. Very Scalable, VeryHigh Throughput Sharded In, Sharded Out
- 46. Reduces to aglobally ordered queue
- 47.
- 48. The Log Single seek& scan Append only messages don’t need to be transient!
- 49. Cleaning the Log Deleteold segments
- 50. Cleaning the Log Deleteold 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 isthis useful for microservices?
- 53. Build ‘Always On’Services Rely on Fault Tolerant Broker
- 54. Load Balance Services LoadBalance Services (with strong ordering)
- 55. Fault Tolerant Services Servicesautomatically fail over (retaining ordering)
- 56. Services can returnback to old messages in the log Rewind & Replay
- 57.
- 58. Lets take alittle 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 ratefor USD/GBP? 0.71 Exchange Rate Service I need exchange rates!
- 61. Option 2: PublishSubscribe Exchange Rate Service Accumulate current state ETL I need exchange rates!
- 62. Option 3: Accumulatein 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 astream or is it a table? transitory stateful
- 64. Datasets can livein the broker! trades books risk results ex- rates
- 65. Service Backbone Scalable, FaultTolerant, Concurrent, Strongly Ordered, Stateful
- 66. … lets addin stream processing
- 67. Max(price) From orders where ccy=‘GBP’ over1 day window emitting every second What is stream processing? Continuous Queries.
- 68. What is streamprocessing engine? Data Index Query Engine Query Engine vs Database Finite, well defined source Stream Processor Infinite, poorly defined source
- 69. Windowing For unordered orunpredictable streams Sliding Fixed (tumbling)
- 70. Features: similar to databasequery engine JoinFilter Aggr- egate View Window
- 71. KStreams & KTables stream Compacted stream Join StreamingData Stored Data KStream KTable
- 72.
- 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.
- 77. Buying Lunch Abroad Payments Exchange Rates Lookslike 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 (fastjoins) Topic Compacted Topic KStream pre-populate
- 80. KTables can alsobe written to - they’re backed by the broker Manage intermediary state KStream KTable Topic Compacted Topic
- 81.
- 82. These tools arepretty handy for managing decentralised services
- 83. Talk our owndata model Data Stream View Query
- 84.
- 85.
- 86. Duality between Streamand Table Join KStream KTable
- 87. More Complex UseCases Trades Valuations Books Customers General Ledger
- 88. trades books risk results ex- rates Practicalmechanism 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 muchmore to stream processing it is grounded in the world of big-data analytics
- 90. Simple Approaches Just alibrary (over Kafka)
- 91.
- 92. Big Global Bagof State in the Sky Problem: No BGBSS
- 93. How to youprovide the accuracy of this
- 94.
- 95. Centralised vs Federated Centralised consistencymodel Distributed consistency model
- 96. One problem isfailure
- 97. Duplicate messages are inevitable haveI seen this before?
- 98. Make Services Idempotent try1 try 2 try 3 try 4
- 99. Stream processors haveto solve this problem
- 100. Exactly Once not availablein Kafka… yet
- 101. So what dowe have?
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 108. Built In FaultTolerance
- 109.
- 110.
- 111.
- 112.
- 113. Scales Horizontally with historystored in the Log
- 114. Scales Horizontally Extending toany number of services
- 115. Scales Horizontally With anydata throughput
- 116. Scales Horizontally With anydata throughput
- 117. Scales Horizontally With anydata throughput
- 118. Scales Horizontally powerful tools forslicing and dicing streams
- 119. Scales Horizontally the declarative processingof data join filter aggregate
- 120.
- 121.
- 122. Scales Horizontally backed upto the log
- 123.
- 124.
- 125. trades books risk results ex- rates withdata living in the stream
- 126. but retaining loose coupling tradesbooks risk results ex- rates
- 127. Scales Horizontally with strongordering and repeatability guarantees (eventually)
- 128.
- 129. Microservices push usaway from shared, mutable state
- 130. Big Global Bagof State in the Sky Away from BGBSS’s
- 131. This means datais increasingly remote
- 132. Sure, you cancollect it all copy copy copy copy copy copy copy ETL ETL ETL ETL ETL ETL
- 133. can be alot of work
- 134. Or you canlook it all up get get get get get get get get, get, get, get
- 135. but that doesn’tscale well (with system complexity or with data throughput)
- 136.
- 137. We need adecentralised toolset to do this trades books risk results ex- rates
- 138. Keep it simple, Keepit moving