\nEnvoi de la requ\u00eate<\/p>\n
<\/p>\n
messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).<\/code><\/pre>\n<\/p>\n
\u00c9change<\/em> \u2012 nom unique du point d'\u00e9changeResponseMatchingTag<\/em> \u2012 \u00e9tiquette locale pour le traitement de la r\u00e9ponse. Par exemple, dans le cas de l'envoi de plusieurs requ\u00eates identiques appartenant \u00e0 diff\u00e9rents utilisateurs.RequestDefinition<\/em> \u2012 corps de la requ\u00eateHandlerProcess<\/em> \u2012 PID du gestionnaire. Ce processus recevra la r\u00e9ponse du serveur.<\/p>\n\n<\/li>\n
\nTraitement de la r\u00e9ponse<\/p>\n
<\/p>\n
handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)<\/code><\/pre>\n<\/p>\n
ResponsePayload<\/em> \u2012 r\u00e9ponse du serveur.<\/p>\n\n<\/li>\n<\/ol>\n
<\/p>\n
Pour le serveur, le processus se compose \u00e9galement de 2 phases :<\/p>\n
<\/p>\n
\nInitialisation du point d'\u00e9change<\/li>\n Traitement des requ\u00eates entrantes<\/li>\n<\/ol>\n<\/p>\n
Illustrons ce mod\u00e8le par du code. Supposons que nous devions impl\u00e9menter un service simple fournissant une m\u00e9thode pour obtenir l'heure exacte.<\/p>\n
<\/p>\n
Code du serveur<\/h4>\n <\/p>\n
D\u00e9pla\u00e7ons la d\u00e9finition de l'API du service dans api.hrl :<\/p>\n
<\/p>\n
%% =====================================================\n%% entit\u00e9s\n%% =====================================================\n-record(time, {\n unixtime :: non_neg_integer(),\n datetime :: binary()\n}).\n\n-record(time_error, {\n code :: non_neg_integer(),\n error :: term()\n}).\n\n%% =====================================================\n%% m\u00e9thodes\n%% =====================================================\n-record(time_req, {\n opts :: term()\n}).\n-record(time_resp, {\n result :: #time{} | #time_error{}\n}).<\/code><\/pre>\n<\/p>\n
D\u00e9finissons le contr\u00f4leur du service dans time_controller.erl<\/p>\n
<\/p>\n
%% L'exemple montre seulement le code significatif. En l'ins\u00e9rant dans le mod\u00e8le gen_server, vous pouvez obtenir un service fonctionnel.\n\n%% initialisation du gen_server\ninit(Args) ->\n %% connexion au point d'\u00e9change\n messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())\n {ok, #{}}.\n\n%% traitement de l'\u00e9v\u00e9nement de perte de connexion avec le point d'\u00e9change. Cet \u00e9v\u00e9nement se produit \u00e9galement si le point d'\u00e9change n'a pas encore d\u00e9marr\u00e9.\nhandle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->\n erlang:send(self(), monitor_exchange),\n {noreply, State};\n\n%% traitement de l'API\nhandle_info(#time_req{opts = _Opts}, State) ->\n messaging:response_once(Client, #time_resp{\nresult = #time{ unixtime = time_utils:unixtime(now()), datetime = time_utils:iso8601_fmt(now())}\n });\n {noreply, State};\n\n%% fin de travail du gen_server\nterminate(_Reason, _State) ->\n messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),\n ok.<\/code><\/pre>\n<\/p>\n
Code client<\/h4>\n <\/p>\n
Pour envoyer une requ\u00eate au service, vous pouvez appeler l'API de requ\u00eate messaging de n'importe quel endroit du client :<\/p>\n
<\/p>\n
case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of\n ok -> ok;\n _ -> %% logique de r\u00e9p\u00e9tition ou d'\u00e9chec\nend<\/code><\/pre>\n<\/p>\n
Dans un syst\u00e8me distribu\u00e9, la configuration des composants peut \u00eatre tr\u00e8s vari\u00e9e et, au moment de la requ\u00eate, messaging peut ne pas encore \u00eatre en cours d'ex\u00e9cution, ou le contr\u00f4leur du service peut ne pas \u00eatre pr\u00eat \u00e0 traiter la requ\u00eate. Il est donc n\u00e9cessaire de v\u00e9rifier la r\u00e9ponse de messaging et de g\u00e9rer le cas d'\u00e9chec.
<\/p>\n
handle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time{unixtime = Utime}}}, State) ->\n ?debugVal(Utime),\n {noreply, State};\n\nhandle_info(#'$msg'{exchange = ?EXCHANGE, tag = tag, message = #time_resp{result = #time_error{code = ErrorCode}}}, State) ->\n ?debugVal({error, ErrorCode}),\n {noreply, State};<\/code><\/pre>\n<\/p>\n
Request-Chunked Response<\/h3>\n <\/p>\n
Il est pr\u00e9f\u00e9rable d'\u00e9viter de transmettre d'\u00e9normes messages. Cela affecte la r\u00e9activit\u00e9 et la stabilit\u00e9 de l'ensemble du syst\u00e8me. Si la r\u00e9ponse \u00e0 une demande occupe beaucoup de m\u00e9moire, il est n\u00e9cessaire de la diviser en parties.<\/p>\n
<\/p>\n
<\/p>\n
Je vais donner quelques exemples de ces cas:<\/p>\n
<\/p>\n
\nLes composants \u00e9changent des donn\u00e9es binaires, comme des fichiers. Diviser la r\u00e9ponse en petites parties permet de traiter efficacement les fichiers de toute taille, sans provoquer de d\u00e9bordement de m\u00e9moire.<\/li>\n Listages. Par exemple, nous devons s\u00e9lectionner toutes les entr\u00e9es d'une immense table dans la base de donn\u00e9es et les transmettre \u00e0 un autre composant.<\/li>\n<\/ul>\n<\/p>\n
J'appelle ces r\u00e9ponses des trains. En tout cas, 1024 messages de 1 Mo sont pr\u00e9f\u00e9rables \u00e0 un seul message de 1 Go. <\/p>\n
<\/p>\n
Dans un cluster Erlang, nous obtenons un avantage suppl\u00e9mentaire - une r\u00e9duction de la charge sur le point d'\u00e9change et le r\u00e9seau, car les r\u00e9ponses sont imm\u00e9diatement envoy\u00e9es au destinataire, contournant le point d'\u00e9change.<\/p>\n
<\/p>\n
Response with Request<\/h3>\n <\/p>\n
C'est une modification plut\u00f4t rare du mod\u00e8le RPC pour construire des syst\u00e8mes de dialogue.<\/p>\n
<\/p>\n
<\/p>\n
Publication-abonnement (arbre de distribution de donn\u00e9es)<\/h3>\n <\/p>\n
Les syst\u00e8mes orient\u00e9s \u00e9v\u00e9nements livrent les donn\u00e9es aux consommateurs d\u00e8s qu'elles sont pr\u00eates. Ainsi, les syst\u00e8mes sont plus enclins \u00e0 un mod\u00e8le de push qu'\u00e0 un mod\u00e8le de pull ou de poll. Cette caract\u00e9ristique \u00e9vite de gaspiller des ressources en interrogeant constamment et en attendant des donn\u00e9es.
<\/p>\n
<\/p>\n
Des exemples classiques de l'utilisation de ce mod\u00e8le incluent la diffusion de l'\u00e9tat : monde de jeu dans les jeux vid\u00e9o, donn\u00e9es de march\u00e9 sur les bourses, informations utiles dans les flux de donn\u00e9es.<\/p>\n
<\/p>\n
Examinons le code du souscripteur :<\/p>\n
<\/p>\n
init(_Args) ->\n %% nous nous abonnissons \u00e0 l'\u00e9change, cl\u00e9 = key\n messaging:subscribe(?SUBSCRIPTION, key, tag, self()),\n {ok, #{}}.\n\nhandle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->\n %% si le point d'\u00e9change n'est pas disponible, nous essayons de nous reconnecter\n messaging:subscribe(?SUBSCRIPTION, key, tag, self()),\n {noreply, State};\n\n%% nous traitons les messages re\u00e7us\nhandle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->\n ?debugVal(Msg),\n {noreply, State};\n\n%% lors de l'arr\u00eat du consommateur - nous nous d\u00e9connectons du point d'\u00e9change\nterminate(_Reason, _State) ->\n messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),\n ok.<\/code><\/pre>\n<\/p>\n
La source peut appeler la fonction de publication de message \u00e0 tout moment :<\/p>\n
<\/p>\n
messaging:publish_message(Exchange, Key, Message).<\/code><\/pre>\n<\/p>\n
\u00c9change<\/em> \u2012 nom du point d'\u00e9change,Cl\u00e9<\/em> \u2012 cl\u00e9 de routageMessage<\/em> \u2012 charge utile<\/p>\n<\/p>\n
Inverted Publish-subscribe<\/h2>\n <\/p>\n
<\/p>\n
En d\u00e9ployant pub-sub, on peut obtenir un mod\u00e8le pratique pour la journalisation. L'ensemble des sources et des consommateurs peut \u00eatre compl\u00e8tement diff\u00e9rent. L'illustration montre un cas avec un seul consommateur et plusieurs sources.<\/p>\n
<\/p>\n
Mod\u00e8le de distribution de t\u00e2ches<\/h2>\n <\/p>\n
Dans presque chaque projet, des t\u00e2ches de traitement diff\u00e9r\u00e9 se pr\u00e9sentent, telles que la g\u00e9n\u00e9ration de rapports, l'envoi de notifications, ou l'acquisition de donn\u00e9es depuis des syst\u00e8mes tiers. La capacit\u00e9 du syst\u00e8me ex\u00e9cutant ces t\u00e2ches peut \u00eatre facilement \u00e9volu\u00e9e en ajoutant des gestionnaires. Tout ce qu'il nous reste \u00e0 faire, c'est de former un cluster de gestionnaires et de r\u00e9partir \u00e9quitablement les t\u00e2ches entre eux.<\/p>\n
<\/p>\n
Consid\u00e9rons les situations qui se pr\u00e9sentent avec 3 gestionnaires. D\u00e8s la phase de r\u00e9partition des t\u00e2ches, la question de l'\u00e9quit\u00e9 de la distribution et de la surcharge des gestionnaires se pose. L'\u00e9quit\u00e9 sera g\u00e9r\u00e9e par une distribution round-robin, et pour \u00e9viter la saturation des gestionnaires, nous introduirons une limite prefetch_limit<\/em>. En modes transitoires, prefetch_limit<\/em> cela emp\u00eachera un gestionnaire de recevoir toutes les t\u00e2ches.<\/p>\n<\/p>\n
Messaging g\u00e8re les files d'attente et la priorit\u00e9 de traitement. Les gestionnaires re\u00e7oivent les t\u00e2ches au fur et \u00e0 mesure de leur arriv\u00e9e. L'ex\u00e9cution d'une t\u00e2che peut se terminer par un succ\u00e8s ou un \u00e9chec :<\/p>\n
<\/p>\n
\nmessaging:ack(Tack)<\/code> \u2012 est appel\u00e9 en cas de traitement r\u00e9ussi du message<\/li>\nmessaging:nack(Tack)<\/code> \u2012 est appel\u00e9 dans toutes les situations anormales. Apr\u00e8s le retour d'une t\u00e2che, messaging la transmettra \u00e0 un autre gestionnaire.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Supposons qu'en traitant trois t\u00e2ches, une d\u00e9faillance complexe se soit produite : le gestionnaire 1 est tomb\u00e9 apr\u00e8s avoir re\u00e7u une t\u00e2che, sans avoir eu le temps de communiquer quoi que ce soit au point d'\u00e9change. Dans ce cas, le point d'\u00e9change, apr\u00e8s le d\u00e9passement du d\u00e9lai d'ack, transmettra la t\u00e2che \u00e0 un autre gestionnaire. Le gestionnaire 3 a refus\u00e9 la t\u00e2che pour une raison quelconque et a envoy\u00e9 un nack, en cons\u00e9quence, la t\u00e2che a \u00e9galement \u00e9t\u00e9 transf\u00e9r\u00e9e \u00e0 un autre gestionnaire qui l'a ex\u00e9cut\u00e9e avec succ\u00e8s.<\/p>\n
<\/p>\n
Bilan pr\u00e9liminaire<\/h2>\n <\/p>\n
Nous avons pass\u00e9 en revue les principaux \u00e9l\u00e9ments des syst\u00e8mes distribu\u00e9s et avons acquis une compr\u00e9hension de base de leur application en Erlang\/Elixir.<\/p>\n
<\/p>\n
En combinant des mod\u00e8les de base, on peut construire des paradigmes complexes pour r\u00e9soudre les t\u00e2ches \u00e9mergentes.<\/p>\n
<\/p>\n
Dans la derni\u00e8re partie de la s\u00e9rie, nous aborderons les questions g\u00e9n\u00e9rales sur l'organisation des services, le routage et l'\u00e9quilibrage, ainsi que la partie pratique de la scalabilit\u00e9 et de la r\u00e9silience des syst\u00e8mes.<\/p>\n
<\/p>\n
Fin de la deuxi\u00e8me partie.<\/p>\n
<\/p>\n
Photo Marius Christensen<\/noindex>Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u043f\u0440\u043e\u0448\u043b\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u043b\u0438 \u0442\u0435\u043e\u0440\u0435\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u043e\u0441\u043d\u043e\u0432\u044b \u0440\u0435\u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u041f\u0440\u0438\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u043f\u043e\u0442\u043e\u043a\u0430\u0445 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u0443\u0442\u044f\u0445 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u0440\u0435\u0430\u043a\u0442\u0438\u0432\u043d\u044b\u0445 Erlang\/Elixir \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0448\u0430\u0431\u043b\u043e\u043d\u0430\u0445 \u043e\u0431\u043c\u0435\u043d\u0430 \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 \u0432 \u043d\u0438\u0445: Request-response Request-Chunked Response Response with Request Publish-subscribe Inverted Publish-subscribe Task distribution SOA, MSA \u0438 \u043e\u0431\u043c\u0435\u043d \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f\u043c\u0438 SOA, MSA \u2013 \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0435 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b, \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u044f\u044e\u0449\u0438\u0435 \u043f\u0440\u0430\u0432\u0438\u043b\u0430 \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c, \u0432 \u0442\u043e \u0432\u0440\u0435\u043c\u044f \u043a\u0430\u043a […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30908","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Les](\"\/wp-content\/uploads\/2019\/04\/7ef485e452075775ce317b557671274c.jpg\")
<\/p>\n