\nAnfrage senden<\/p>\n
<\/p>\n
messaging:request(Exchange, ResponseMatchingTag, RequestDefinition, HandlerProcess).<\/code><\/pre>\n<\/p>\n
Austausch<\/em> \u2012 einzigartiger Name des AustauschpunktsResponseMatchingTag<\/em> \u2012 lokales Tag zur Verarbeitung der Antwort. Zum Beispiel im Fall der Sendung mehrerer identischer Anfragen, die verschiedenen Benutzern geh\u00f6ren.RequestDefinition<\/em> \u2012 Anfragek\u00f6rperHandlerProcess<\/em> \u2012 PID des Handlers. Dieser Prozess erh\u00e4lt die Antwort vom Server.<\/p>\n\n<\/li>\n
\nAntwortverarbeitung<\/p>\n
<\/p>\n
handle_info(#'$msg'{exchange = EXCHANGE, tag = ResponseMatchingTag,message = ResponsePayload}, State)<\/code><\/pre>\n<\/p>\n
ResponsePayload<\/em> \u2012 Serverantwort.<\/p>\n\n<\/li>\n<\/ol>\n
<\/p>\n
F\u00fcr den Server besteht der Prozess ebenfalls aus 2 Phasen:<\/p>\n
<\/p>\n
\nInitialisierung des Austauschpunkts<\/li>\n Verarbeitung der eingehenden Anfragen<\/li>\n<\/ol>\n<\/p>\n
Illustrieren wir dieses Muster mit code. Angenommen, wir m\u00fcssen einen einfachen Dienst implementieren, der eine einzige Methode zur genauen Zeit bereitstellt.<\/p>\n
<\/p>\n
Servercode<\/h4>\n <\/p>\n
Lass uns die API-Definition des Dienstes in api.hrl auslagern:<\/p>\n
<\/p>\n
%% =====================================================\n%% entities\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%% methods\n%% =====================================================\n-record(time_req, {\n opts :: term()\n}).\n-record(time_resp, {\n result :: #time{} | #time_error{}\n}).<\/code><\/pre>\n<\/p>\n
Definieren wir den Dienst-Controller in time_controller.erl<\/p>\n
<\/p>\n
%% Im Beispiel wird nur der wesentliche Code gezeigt. Indem wir ihn in das gen_server-Muster einf\u00fcgen, k\u00f6nnen wir einen funktionierenden Dienst erhalten.\n\n%% Initialisierung von gen_server\ninit(Args) ->\n %% Verbindung zum Austauschpunkt\n messaging:monitor_exchange(req_resp, ?EXCHANGE, default, self())\n {ok, #{}}.\n\n%% Verarbeitung des Ereignisses eines Verbindungsverlusts zum Austauschpunkt. Dasselbe Ereignis tritt auf, wenn der Austauschpunkt noch nicht gestartet ist.\nhandle_info(#exchange_die{exchange = ?EXCHANGE}, State) ->\n erlang:send(self(), monitor_exchange),\n {noreply, State};\n\n%% Verarbeitung der 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%% Beendigung der gen_server-Arbeit\nterminate(_Reason, _State) ->\n messaging:demonitor_exchange(req_resp, ?EXCHANGE, default, self()),\n ok.<\/code><\/pre>\n<\/p>\n
Client-Code<\/h4>\n <\/p>\n
Um eine Anfrage an den Dienst zu senden, kann an beliebiger Stelle im Client die messaging request API aufgerufen werden:<\/p>\n
<\/p>\n
case messaging:request(?EXCHANGE, tag, #time_req{opts = #{}}, self()) of\n ok -> ok;\n _ -> %% Wiederholungs- oder Fehlerlogik\nend<\/code><\/pre>\n<\/p>\n
In einem verteilten System kann die Konfiguration der Komponenten unterschiedlich sein und zum Zeitpunkt der Anfrage kann die messaging noch nicht gestartet sein oder der Dienst-Controller ist m\u00f6glicherweise nicht bereit, die Anfrage zu bearbeiten. Daher m\u00fcssen wir die Antwort der messaging \u00fcberpr\u00fcfen und den Fall eines Fehlers behandeln.
<\/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
Es ist besser, keine riesigen Nachrichten zu \u00fcbermitteln. Das beeinflusst die Reaktionsf\u00e4higkeit und die stabile Funktionsweise des gesamten Systems. Wenn die Antwort auf eine Anfrage viel Speicher ben\u00f6tigt, ist eine Aufteilung in Teile erforderlich.<\/p>\n
<\/p>\n
<\/p>\n
Hier sind ein paar Beispiele f\u00fcr solche F\u00e4lle:<\/p>\n
<\/p>\n
\nKomponenten tauschen Bin\u00e4rdaten, wie Dateien, aus. Die Aufteilung der Antwort in kleinere Teile hilft, effizient mit Dateien jeder Gr\u00f6\u00dfe zu arbeiten und ein Speicher\u00fcberlauf zu vermeiden.<\/li>\n Listen. Zum Beispiel m\u00fcssen wir alle Datens\u00e4tze aus einer riesigen Tabelle in der Datenbank ausw\u00e4hlen und an eine andere Komponente \u00fcbermitteln.<\/li>\n<\/ul>\n<\/p>\n
Ich nenne solche Antworten einen Zug. In jedem Fall sind 1024 Nachrichten zu je 1 MB besser als eine einzige Nachricht von 1 GB. <\/p>\n
<\/p>\n
In einem Erlang-Cluster erzielen wir einen zus\u00e4tzlichen Vorteil \u2013 die Reduzierung der Belastung an der Austauschstelle und im Netzwerk, da die Antworten sofort an den Empf\u00e4nger gesendet werden, ohne die Austauschstelle zu passieren.<\/p>\n
<\/p>\n
Response mit Request<\/h3>\n <\/p>\n
Dies ist eine recht seltene Modifikation des RPC-Musters zum Aufbau dialogorientierter Systeme.<\/p>\n
<\/p>\n
<\/p>\n
Publish-Subscribe (Datenverteilung Baum)<\/h3>\n <\/p>\n
Ereignisgesteuerte Systeme liefern Daten an Verbraucher, sobald sie bereit sind. Dadurch tendieren die Systeme eher zu einem Push-Modell als zu Pull- oder Poll-Modellen. Diese Eigenschaft verhindert, dass Ressourcen unn\u00f6tig verschwendet werden, indem st\u00e4ndig Daten angefordert und erwartet werden.
<\/p>\n
<\/p>\n
Klassische Beispiele f\u00fcr die Verwendung dieses Musters sind die Verbreitung von Zust\u00e4nden: Spielwelten in Computerspielen, Marktdaten an B\u00f6rsen, n\u00fctzliche Informationen in Datenfeeds.<\/p>\n
<\/p>\n
Betrachten wir den Code des Abonnenten:<\/p>\n
<\/p>\n
init(_Args) ->\n %% wir abonnieren den Austausch, Schl\u00fcssel = key\n messaging:subscribe(?SUBSCRIPTION, key, tag, self()),\n {ok, #{}}.\n\nhandle_info(#exchange_die{exchange = ?SUBSCRIPTION}, State) ->\n %% wenn die Austauschstelle nicht verf\u00fcgbar ist, versuchen wir, uns erneut zu verbinden\n messaging:subscribe(?SUBSCRIPTION, key, tag, self()),\n {noreply, State};\n\n%% wir verarbeiten die eingehenden Nachrichten\nhandle_info(#'$msg'{exchange = ?SUBSCRIPTION, message = Msg}, State) ->\n ?debugVal(Msg),\n {noreply, State};\n\n%% beim Stoppen des Verbrauchers trennen wir uns von der Austauschstelle\nterminate(_Reason, _State) ->\n messaging:unsubscribe(?SUBSCRIPTION, key, tag, self()),\n ok.<\/code><\/pre>\n<\/p>\n
Die Quelle kann die Funktion zum Ver\u00f6ffentlichen von Nachrichten an beliebiger Stelle aufrufen:<\/p>\n
<\/p>\n
messaging:publish_message(Exchange, Key, Message).<\/code><\/pre>\n<\/p>\n
Austausch<\/em> \u2012 Name des Austauschpunkts,Schl\u00fcssel<\/em> \u2012 Routing-Schl\u00fcsselNachricht<\/em> \u2012 Payload<\/p>\n<\/p>\n
Inverted Publish-Subscribe<\/h2>\n <\/p>\n
<\/p>\n
Durch die Einf\u00fchrung von Pub-Sub kann ein Muster erzielt werden, das sich zum Logging eignet. Die Sammlung von Quellen und Verbrauchern kann vollkommen unterschiedlich sein. Im Bild ist ein Fall mit einem Verbraucher und mehreren Quellen dargestellt.<\/p>\n
<\/p>\n
Task-Verteilungsmuster<\/h2>\n <\/p>\n
In fast jedem Projekt gibt es Aufgaben zur verz\u00f6gerten Verarbeitung, wie zum Beispiel das Erstellen von Berichten, das Versenden von Benachrichtigungen und das Abrufen von Daten aus externen Systemen. Die Kapazit\u00e4t des Systems, das diese Aufgaben ausf\u00fchrt, kann leicht durch das Hinzuf\u00fcgen von Handlern skaliert werden. Alles, was wir tun m\u00fcssen, ist, einen Cluster von Handlern zu bilden und die Aufgaben gleichm\u00e4\u00dfig zwischen ihnen zu verteilen.<\/p>\n
<\/p>\n
Betrachten wir die auftretenden Situationen am Beispiel von 3 Handlern. Bereits in der Phase der Aufgabenverteilung stellt sich die Frage der Fairness der Verteilung und der \u00dcberlastung der Handler. F\u00fcr die Fairness wird eine Round-Robin-Verteilung sorgen, um \u00dcberlastung der Handler zu vermeiden, f\u00fchren wir eine Begrenzung ein prefetch_limit<\/em>. In \u00dcbergangsmodi prefetch_limit<\/em> wird es einem Handler nicht erm\u00f6glichen, alle Aufgaben zu erhalten.<\/p>\n<\/p>\n
Messaging verwaltet Warteschlangen und Priorit\u00e4ten bei der Verarbeitung. Handler erhalten Aufgaben, sobald sie anfallen. Die Ausf\u00fchrung einer Aufgabe kann erfolgreich abgeschlossen werden oder fehlschlagen:<\/p>\n
<\/p>\n
\nmessaging:ack(Tack)<\/code> \u2012 wird im Falle einer erfolgreichen Verarbeitung der Nachricht aufgerufen<\/li>\nmessaging:nack(Tack)<\/code> \u2012 wird in allen Ausnahmef\u00e4llen aufgerufen. Nach der R\u00fcckgabe der Aufgabe wird messaging sie an einen anderen Handler weitergeben.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Angenommen, w\u00e4hrend der Verarbeitung von drei Aufgaben tritt ein komplexer Fehler auf: Handler 1 f\u00e4llt nach dem Erhalt der Aufgabe aus, ohne der Austauschstelle etwas mitgeteilt zu haben. In diesem Fall wird die Austauschstelle nach Ablauf der Ack-Timeout die Aufgabe an einen anderen Handler weitergeben. Handler 3 hat aus irgendeinem Grund die Aufgabe abgelehnt und nack gesendet, sodass die Aufgabe ebenfalls an einen anderen Handler \u00fcbergeben wurde, der sie erfolgreich ausgef\u00fchrt hat.<\/p>\n
<\/p>\n
Vorl\u00e4ufiges Ergebnis<\/h2>\n <\/p>\n
Wir haben die grundlegenden Bausteine verteilter Systeme behandelt und ein grundlegendes Verst\u00e4ndnis ihrer Anwendung in Erlang\/Elixir gewonnen.<\/p>\n
<\/p>\n
Durch die Kombination grundlegender Muster k\u00f6nnen komplexe Paradigmen zum L\u00f6sen auftretender Aufgaben aufgebaut werden.<\/p>\n
<\/p>\n
Im abschlie\u00dfenden Teil des Zyklus werden wir allgemeine Fragen zur Organisation von Diensten, zur Routenf\u00fchrung und zum Lastenausgleich sowie zur praktischen Seite der Skalierbarkeit und Ausfallsicherheit von Systemen er\u00f6rtern.<\/p>\n
<\/p>\n
Ende des zweiten Teils.<\/p>\n
<\/p>\n
Foto Marius Christensen<\/noindex>Quelle: 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
![\"Bausteine](\"\/wp-content\/uploads\/2019\/04\/7ef485e452075775ce317b557671274c.jpg\")
<\/p>\n