Pros and Cons of push and pull
| push | pull | |
|---|---|---|
| Most Common, rest/rpc, default | ||
| mechanism | Client makes push task to server to execute | Server request work from Client, usually client has a task queue, Server pull work from the task queue |
| adv | 1. for request-response operations, usually involves a persistent connection over which both the request and the response travel easy response matching, over the same connection 2. greedy routing, rather than blindly send to LB, client can pick locally better server(low error rate, fast response, distance closer, like same DC/region) | 1. message queue to distribute tasks, improve scalability, multiple worker(server) process at the same time 2. with message queue, no service discovery needed |
| disadv | 1. maintainance for list of server address - LB endpoints - DNS names, - service discovery system(Zookeeper) 2. Load balancing? | 1. trouble to recv response: - add http server to send address with msg - broadcast response and client pick they want 2. don’t support for complex routing |
push model
pull model
Service Mesh: the clients just need to know how to make a basic request, and the service mesh can handle
- routing,
- service discovery,
- retries,
- circuit breakers,
- instrumentation, and more.
ref: https://medium.com/@_JeffPoole/thoughts-on-push-vs-pull-architectures-666f1eab20c2