1

Topic: Microservices routing

The colleagues, Probably many faced a problem and there are any decisions already ready. It is necessary to make routing. That is microservice 1 made the operation and  the message in queue that is ready. The second should react to this message and the third. The fourth reacts to results of operation of the second etc. How to do such routing? It is similar on workflow and upon it and is.

2

Re: Microservices routing

Hello, Gattaka, you wrote: G> Colleagues, G> Probably many faced a problem and there are any decisions already ready. It is necessary to make routing. That is microservice 1 made the operation and  the message in queue that is ready. The second should react to this message and the third. The fourth reacts to results of operation of the second etc. How to do such routing? It is similar on workflow and upon it and is. At each microservice - own output queue. Creation big kol-va queues, their administration and authentification dares through automation .

3

Re: Microservices routing

Hello, Gattaka, you wrote: G> Probably many faced a problem and there are any decisions already ready. It is necessary to make routing. That is microservice 1 made the operation and  the message in queue that is ready. The second should react to this message and the third. The fourth reacts to results of operation of the second etc. How to do such routing? It is similar on workflow and upon it and is. In SOA (which Service-oriented architecture) there are two approaches how the sheaf of services becomes: Service choreography - when each service transfers control to the following, that to the following and .. Thus there is no what central node which would track that who when and with what data receives control. Service orchestration - when there is a central service (business-process management, workflow, ESB...) Which builds all process of operation: there, normally is a certain description (often - graphic) sequences of interaction of services (and normal practice when process is initiated by reversal to any service) Actually, dance from here. If titles of specific libraries/products it is necessary to learn at first your conditions are necessary to you (than use where ...). P.S. On my sensations the choreography where is more difficult in support if the number of services starts to grow, at orchestration because all process is described in one place, to do open changes much easier. But this central node it becomes normal a bottleneck.

4

Re: Microservices routing

Hello, Gattaka, you wrote: G> Probably many faced a problem and there are any decisions already ready. It is necessary to make routing. That is microservice 1 made the operation and  the message in queue that is ready. The second should react to this message and the third. The fourth reacts to results of operation of the second etc. How to do such routing? It is similar on workflow and upon it and is. Any service of queues, from 0mq to Amazon SQS.

5

Re: Microservices routing

Hello, Michael Romanov, you wrote: > Service choreography - when each service transfers control to the following, that to the following and .. Thus there is no what central node which would track that who when and with what data receives control. > Service orchestration - when there is a central service (business-process management, workflow, ESB...) which all process of operation builds: there, normally there is a certain description (often - graphic) sequences of interaction of services (and normal practice when process is initiated by reversal to any service) And how both variants will be organized technically? Is where to esteem more in detail?

6

Re: Microservices routing

7

Re: Microservices routing

I will add about ESB - the main problem , besides high-speed performance, it . Finishings of services involve finishings of rules ESB on which all services are fastened. It means what break, basically, any functionality in any microservice can. I consider that good microservice should be to as much as possible insulated and useful indirect developers without access to source codes, and ESB is the actual monolith covered with a fig leaflet of rules of routing of messages.

8

Re: Microservices routing

Hello, scf, you wrote: scf> At each microservice - own output queue. Creation big kol-va queues, their administration and authentification dares through automation . It works exactly until, while for you the linear chain of services. It works in variety . If it is slightly more difficult than a game rule (it is for example necessary rekvest-replaj,  and ) begins  and finally we can receive the unsupported monster.

9

Re: Microservices routing

Hello, Gattaka, you wrote: G> Colleagues, G> Probably many faced a problem and there are any decisions already ready. It is necessary to make routing. That is microservice 1 made the operation and  the message in queue that is ready. The second should react to this message and the third. The fourth reacts to results of operation of the second etc. How to do such routing? It is similar on workflow and upon it and is. Decisions  are. But without knowing details difficult  in what direction to move. I would recommend to begin with it, then to pass to what a thread of type of it or here it and is then confident  it well and control in a head. Then some years of practice, tamping of cones - and all turns out

10

Re: Microservices routing

Hello, itslave, you wrote: I> It works exactly until, while for you the linear chain of services. It works in variety . If it is slightly more difficult than a game rule (it is for example necessary rekvest-replaj,  and ) begins  and finally we can receive the unsupported monster. Well, with  all is good, I do not see special problems to read to several receivers from one queue (if the acute problem of removal of the old data from queue is not necessary). About rekvest-replaj through queues - this cactus is chewed by many banks since the distributed architecture on JMS durable queue with transactions is well worked theoretically and  practically. My judgement - that queues are necessary only there where there is a necessity given to buffer - for example if  wants to give and  the data faster, than  is capable to process them.

11

Re: Microservices routing

Hello, scf, you wrote: scf> My judgement - that queues are necessary only there where there is a necessity given to buffer - for example if  wants to give and  the data faster, than  is capable to process them. Your judgement  is interesting, but there are dudes who with you do not agree. In what I support them hardly  than completely.

12

Re: Microservices routing

Hello, itslave, you wrote: I> Hello, scf, you wrote: scf>> My judgement - that queues are necessary only there where there is a necessity given to buffer - for example if  wants to give and  the data faster, than  is capable to process them. I> your judgement  is interesting, but there are dudes who with you do not agree. In what I support them hardly  than completely. To this book already 5 years, and a current trend of microservice architecture - http/rest, thrift, grpc. However, the book did not read, I will be corrected. edit: read  "Why Use Messaging?". Judging by a dial-up of arguments, the book and truth became outdated. The part of arguments is applicable and to RPC, the part rests on absence of asynchrony and  in RPC (for a long time it is made), the part starts with reliability of iron and unreliability of a network (in modern  to the world iron is unreliable!) And remaining enter into a category "to us it is really necessary to store the data since speed of the sender above speed of the receiver". RPC it is abrupt that it stateless - we do not need to store anything. Service of queues demands attention DBA, as well as a database. Queue can be overflowed, the data from queue can be lost (who does  queues?), at problems in system it is necessary to look contents of queues (for  parts of systems of such possibility are not present).

13

Re: Microservices routing

Hello, scf, you wrote: scf> to This book already 5 years, and a current trend of microservice architecture - http/rest, thrift, grpc. However, the book did not read, I will be corrected. And what changed for five years in HTTP/REST?

14

Re: Microservices routing

Hello, scf, you wrote: scf> to This book already 5 years, and a current trend of microservice architecture - http/rest, thrift, grpc. However, the book did not read, I will be corrected. In this book that the described patterns is not necessary  manually became outdated only, simply to select the necessary service a bass. All. scf> edit: read  "Why Use Messaging?". Judging by a dial-up of arguments, the book and truth became outdated. The part of arguments is applicable and to RPC, the part rests on absence of asynchrony and  in RPC (for a long time it is made), the part starts with reliability of iron and unreliability of a network (in modern  to the world iron is unreliable!) And remaining enter into a category "to us it is really necessary to store the data since speed of the sender above speed of the receiver". In  microservice  to the world the network as is unreliable as well as at dinosaurs rpc. And the book esteem on . scf> Queue can be overflowed, the data from queue can be lost (who does  queues?), at problems in system it is necessary to look contents of queues (for  parts of systems of such possibility are not present). If it is short, esteem about SLA queues. Some of them  go as a service in .

15

Re: Microservices routing

Hello, Nikolay_Ch, you wrote: N_C> And what changed for five years in HTTP/REST? There were asynchronous clients and asynchronous servers. The amount of parallel connections any more is not restriction, hundreds and thousand simultaneous connections - are cheap. Concept Future/Promise was final issued. The difficult asynchronous code any more so is added. Who wrote logic  with  and an other tinsel me understands. There are normal libraries for operation with a network both for clients, and for servers. Able , ,  with various behavior. The modern stacks json/http can process thousand requests a second without the considerable overhead projector.

16

Re: Microservices routing

Hello, itslave, you wrote: I> In this book that the described patterns is not necessary  manually became outdated only, simply to select the necessary service a bass. All. ESB is for elite, I do not carry myself to them. I> in  the microservice virtual world the network as is unreliable as well as at dinosaurs rpc. Unreliability of a network, it, the right, such insignificant problem in comparison with unreliability of data storage... I> If it is short, esteem about SLA queues. Some of them  go as a service in . SLA  resources and people who will provide it. Forces of a command - it is expensive. I two hands for as a service, since most  data store - business uneasy and demanding constant supervision. But besides purely technical questions (works not how we want) there are still questions financial - that in case of surge of usage of resources turns out or , or the account from a hoster on the arbitrary total.

17

Re: Microservices routing

Hello, scf, you wrote: scf> Hello, Nikolay_Ch, you wrote: N_C>> And what changed for five years in HTTP/REST? scf> There were asynchronous clients and asynchronous servers. The amount of parallel connections any more is not restriction, hundreds and thousand simultaneous connections - are cheap. At me for you the bad news. The problem 10 has been formulated almost 20 back and since then exchanged nothing - want to process more than 10000 simultaneous  - it is necessary to squat, without dependence from a programming language. scf> concept Future/Promise was final issued. The difficult asynchronous code any more so is added. Who wrote logic  with  and an other tinsel me understands. Asynchrony has been invented in 60, on a platform x86 it was implemented by interruptions. About int 21h you for certain did not hear scf> the Modern stacks json/http can process thousand requests a second without the considerable overhead projector. Exactly too most it was possible to do 20 years ago. Only instead of json was xml. , youth.....

18

Re: Microservices routing

Hello, scf, you wrote: scf> Hello, itslave, you wrote: I>> In this book that the described patterns is not necessary  manually became outdated only, simply to select the necessary service a bass. All. scf> ESB is for elite, I do not carry myself to them. Not clearly why ESB - for elite. But , is still shaft simply service bus, without a prefix enterprise. scf> Unreliability of a network, it, the right, such insignificant problem in comparison with unreliability of data storage... , it is so insignificant that led only CAP to the theorem, a failure from ACID in favor of BASE, (partially) to event-driven to model.... scf> I two hands for as a service, since most  data store - business uneasy and demanding constant supervision. But besides purely technical questions (works not how we want) there are still questions financial - that in case of surge of usage of resources turns out or , or the account from a hoster on the arbitrary total. Well time is surge - business means works, gets profit. To give a small part to a hoster it is not a pity.

19

Re: Microservices routing

Hello, itslave, you wrote: I in perplexity. About 10 - you read the last paragraph? select/IOCP it not knee-bends, it already a mainstream. IO on  in 2017 should not to become. int21h in  is a software interrupt for a call of services DOS and there was it **. Hardware interrupts are at all that and anybody to the user software does not allow to redefine the handler. To whom in 1997 the XML-services processing 1000 requests in second were necessary and in what language them wrote? Google states that service bus is ESB. The CAP-theorem about ** also concerns only stateful . There is no data - there are no problems with consistency, write AP and rejoice lives. Loading on system! = profit. It can be DoS, it can be a bug in system, in case of queues under loading the volume of the storable data depends not on loading, and from the relation of speeds of operation of the sender and the receiver (that generally it is difficult to predict in dynamics)

20

Re: Microservices routing

Hello, scf, you wrote: scf> Hello, itslave, you wrote: scf> I in perplexity. About 10 - you read the last paragraph? select/IOCP it not knee-bends, it already a mainstream. IO on  in 2017 should not to become. Yes as a matter of fact still in 70 the people very accurately understood distinction between asynchrony and a multithreading. And then still invented absolutely different mechanisms for these cases and successfully used all this time. If someone in 2010 used  a pool for asynchrony emulation... That at me for this person is to steam of the bad news.  the avalanche grew  the industries and as consequence - qualification reduction  imported the mite, but same at all an occasion to tell about what that new fulfillments in 2017. Yes, syntactic sugar added, an input threshold reduced.... And all scf> int21h in  is a software interrupt for a call of services DOS and there was it **. Hardware interrupts are at all that and anybody to the user software does not allow to redefine the handler. And then it also it was not necessary. But developers of operating systems very accurately understood that asynchrony is not a multithreading and  interfaces, actual for the time. scf> to whom in 1997 the XML-services processing 1000 requests in second were necessary and in what language them wrote? On with ++ . And they were necessary, there was rather a lot of software for such cases, as a rule , the finance... scf> Google states that service bus is ESB. It says lies. Everyones , mules from apaches and even  basses are not absolutely  (there there are monsters from , , ). scf> the CAP-theorem about ** also concerns only stateful . There is no data - there are no problems with consistency, write AP and rejoice lives. Well here normally suddenly it turns out that services are necessary to dataless nobody. scf> loading on system! = profit. It can be DoS, it can be a bug in system, in case of queues under loading the volume of the storable data depends not on loading, and from the relation of speeds of operation of the sender and the receiver (that generally it is difficult to predict in dynamics) If loading! = the profit it is a bug which should be repaired. And all. Yes, the fix of some bugs which have been not revealed in time, costs very expensively. Here to unwinding the bug with the antenna in  4 (or 3 or 5) was recalled. It would Seem a trifle, but how many it cost... PS what that the chaotic post quitted. Probably because answered the message in which a heap horses, people too mixed up...

21

Re: Microservices routing

Hello, Gattaka, you wrote: G> Probably many faced a problem and there are any decisions already ready. It is necessary to make routing. That is microservice 1 made the operation and  the message in queue that is ready. The second should react to this message and the third. The fourth reacts to results of operation of the second etc. How to do such routing? From personal experience: 0) And can  microservices not are necessary? 1) these ESB and mega-orkestratory suck all. Very deeply suck. 2) direct calls of one service of another suck less, but at any awkward driving it is possible to receive dynamic unstable system. 3) systems on messages suck unusually. They should be avoided so, how much generally it is possible. From the pleasant: https://linkerd.io/- allows to write services which are steady against many dynamic , and thus it is perfectly combined with normal direct requests. Plus to it is remarkable system of monitoring.

22

Re: Microservices routing

Hello, Cyberax, you wrote: a C> From the pleasant: https://linkerd.io/- allows to write services which are steady against many dynamic , and thus it is perfectly combined with normal direct requests. Plus to it is remarkable system of monitoring. Even there was a candidate who does not suck. It is fine. Esteemed to dock on . I correctly understand, what  it does not give, delivery - does not guarantee, the sequence of delivery - does not guarantee?

23

Re: Microservices routing

Hello, Cyberax, you wrote: a C> From the pleasant: https://linkerd.io/- allows to write services which are steady against many dynamic , and thus it is perfectly combined with normal direct requests. Plus to it is remarkable system of monitoring. Used? Multiplexing of requests (within the limits of one TCP connections) is able to do some requests?

24

Re: Microservices routing

Hello, scf, you wrote: scf> Used? Multiplexing of requests (within the limits of one TCP connections) is able to do some requests? If is able -    . Therefore as  the task of transport level also is already solved in http/2 Which  at the very least  servers much a web.

25

Re: Microservices routing

Hello, itslave, you wrote: I> If is able -    . Therefore as  the task of transport level also is already solved in http/2 I> Which  at the very least  servers much a web. HTTP/1.1 pipelining (on which you sent the link) not panacea since it fixes the order of obtaining of answers to requests: 8.1.2.2 Pipelining A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. http/2 java-clients and servers still the crude. It is too new technology that on it to be fastened. grpc, by the way, uses http/2 as the protocol and many complained of various problems with it. Besides, http/2 it is more difficult and it is necessary to study usage  and storage under loading - http/1.1 can appear more cheaply.