Nothing wrong with "Http pull" as used in micro service i) Pull with 2 services both with a service they can push to each other sometimes with pub sub eg WS-Eventing ii) As far as HTTP goes , nothing wrong there either in nearly all t cases http cost is insignificant .
Architectural design is far more important. The key to these services is to ensure all calls are chunky and that logical concepts are grouped in a single service .. If you go through 1M customers looking up the address on an address service it will be dog slow whether you use zeroMQ or HTTP ie you cant do CRUD row based calls across services . Regards, Ben On Wed, Apr 23, 2014 at 4:52 PM, Pieter Hintjens <[email protected]> wrote: > On Wed, Apr 23, 2014 at 9:33 AM, techbird <[email protected]> wrote: > > > The main article focuses on using http - atom/json with a pull model, for > > Internet scale collaboration . > > It's a simple and widely-used approach, yet very poor. It basically > enforces the thin-client fat-server model, where clients hang off > specific servers. I don't think it's acceptable in 2014 to propose > HTTP-style pull as a basis. Indeed, large-scale service providers are > working very hard to escape that (websockets, HTTP2, SPDY, etc.) > > A different, still simple model, is to treat every tasks as an > event-driven actor that can receive messages from any source, be it > another thread in the same process, or a box on the other side of the > world. In this model, tasks do not poll or pull; they receive messages > asynchronously from any number of sources. > > On top of that you can build pub-sub, push-pull, request-reply etc. as > multi-message protocols. You can even recreate RESTful semantics quite > simply. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
