Timeline for Microservice Communication: Enforce RPC?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 22, 2018 at 16:28 | comment | added | Ewan | @9000 sure there are ways you can deal with it, but they are are much more complicated than just running the code locally with a try catch | |
| Jan 22, 2018 at 16:24 | comment | added | 9000 | @Ewan: for relatively infrequent and high-value messages, I'd consider a two-way, two-phase protocol. A successful processing should be acknowledged, and only then the message should be considered processed. If you can redo from start after a prolonged consumer downtime, or the message ceases to be valuable after a prolonged downtime, you can opt for TCP-like sequence numbers + resend requests. | |
| Jan 21, 2018 at 22:09 | comment | added | Auf Zug | Okay now I see what you meant with timeout. Let me think. Of course I'm missing a lot of subtleties thats why I'm asking here to find out | |
| Jan 21, 2018 at 22:06 | comment | added | Ewan | hmm, I think you are missing some of the subtleties of these problems. so for example when your heavy process dies the intermediate state was in a message that was consumed by the process that crashed. You need some cleverness if you want to pick that message up again. Similarly with the timeout, for all the calling process knows the message is still being processed somewhere. do you send another or wait longer? | |
| Jan 21, 2018 at 22:01 | comment | added | Auf Zug | For Error Handling my thoughts are: heavyComputation() is called, which calls a couple of other methods in the same process and while the last one is running... DANG. Process dies. All the work is lost. When all of these methods would have been called through a message queue, all the intermediate results were persisted and it would be trivial to re-schedule just the missing step(s). Am I wrong? | |
| Jan 21, 2018 at 21:57 | comment | added | Auf Zug | Regarding 1): The receiving instances are auto-scaled based on how long the queue is, so timeouts shouldn't happen if sufficiently long for high load when auto scaling is blocked by budget. Regarding 4) Each zone has its own queue cluster so when a whole zone goes down the others still operate. | |
| Jan 21, 2018 at 21:44 | comment | added | Auf Zug | Thanks for your answer!I'm thinking method I/O spec to be immutable. When expected input or output changes, it is copied and gets a new name like resizePicture -> resizePicture2 and the old version stays in new releases so that switch is trivial: For each existing instance, start a new one. Notify old instances to stop receiving messages, terminate when buffered work is done. No problem when someone still uses the old version. | |
| Jan 21, 2018 at 20:49 | history | answered | Ewan | CC BY-SA 3.0 |