Hallo! Mein Name ist Konstantin Evteev, ich arbeite in Avito als Leiter der DBA-Einheit. Unser Team entwickelt Avito-Speichersysteme, hilft bei der Auswahl oder Ausgabe von Datenbanken und der zugehörigen Infrastruktur, unterstützt das Service Level Objective für Datenbankserver und ist auch für die Ressourceneffizienz und -überwachung verantwortlich, berät beim Design und entwickelt möglicherweise Microservices. gebunden an Speichersysteme oder Dienste für die Entwicklung der Plattform im Kontext der Speicherung.
Ich möchte erläutern, wie wir eine der Herausforderungen der Microservice-Architektur gelöst haben - die Durchführung von Geschäftstransaktionen in der Infrastruktur von Diensten, die mithilfe der Datenbank pro Dienstmuster erstellt wurden. Ich habe auf der Highload ++ Siberia 2018- Konferenz eine Präsentation zu diesem Thema gehalten.
Theorie So kurz wie möglich
Ich werde die Theorie der Sagen nicht im Detail beschreiben. Ich werde Ihnen nur eine kurze Einführung geben, damit Sie den Kontext verstehen.
Wie zuvor (von Beginn von Avito bis 2015 - 2016): Wir lebten in einem Monolithen mit monolithischen Basen und monolithischen Anwendungen. Irgendwann hinderten uns diese Bedingungen daran zu wachsen. Einerseits sind wir auf die Leistung eines Servers mit einer Hauptdatenbank gestoßen, aber dies ist nicht der Hauptgrund, da das Leistungsproblem beispielsweise durch Sharding gelöst werden kann. Auf der anderen Seite hat der Monolith eine sehr komplexe Logik, und in einem bestimmten Wachstumsstadium wird die Bereitstellung von Änderungen (Releases) sehr lang und unvorhersehbar: Es gibt viele nicht offensichtliche und komplexe Abhängigkeiten (alles ist eng miteinander verbunden), es ist auch schwierig zu testen, im Allgemeinen gibt es viele Probleme. Die Lösung besteht darin, auf die Microservice-Architektur umzusteigen. Zu diesem Zeitpunkt hatten wir eine Frage zu Geschäftstransaktionen, die stark an ACIDs gebunden waren, die von einer monolithischen Basis bereitgestellt wurden: Es ist nicht klar, wie diese Geschäftslogik migriert werden soll. Bei der Arbeit mit Avito gibt es viele verschiedene Szenarien, die von mehreren Diensten implementiert werden. Wenn die Integrität und Konsistenz der Daten sehr wichtig ist, z. B. Kauf eines Premium-Abonnements, Abbuchung von Geld, Anwendung von Diensten auf einen Benutzer, Kauf von VAS-Paketen - bei unvorhergesehenen Umständen oder Unfällen kann es sein, dass nicht alles unerwartet verläuft nach Plan. Wir haben die Lösung in den Sagen gefunden.
Ich mag die technische Beschreibung der Sagen im Jahr 1987 von Kenneth Salem und Hector Garcia-Molina, einem der derzeitigen Mitglieder des Oracle Board of Directors. Wie das Problem formuliert wurde: Es gibt eine relativ kleine Anzahl langlebiger Transaktionen, die lange Zeit die Ausführung kleiner, weniger ressourcenintensiver und häufigerer Vorgänge verhindern. Als gewünschtes Ergebnis können Sie ein Beispiel aus dem Leben geben: Sicherlich standen viele von Ihnen in der Schlange, um Dokumente zu kopieren, und der Kopierer, wenn er die Aufgabe hatte, ein ganzes Buch oder nur viele Kopien zu kopieren, machte von Zeit zu Zeit Kopien von anderen Mitgliedern der Warteschlange. Die Entsorgung von Ressourcen ist jedoch nur ein Teil des Problems. Die Situation wird durch langfristige Sperren bei der Ausführung ressourcenintensiver Aufgaben verschärft, deren Kaskade in Ihrem DBMS erstellt wird. Darüber hinaus können während einer langen Transaktion Fehler auftreten: Die Transaktion wird nicht abgeschlossen und der Rollback beginnt. Wenn die Transaktion lang war, dauert der Rollback ebenfalls lange, und die Anwendung wird wahrscheinlich erneut versucht. Im Allgemeinen "ist alles sehr interessant." Die in der technischen Beschreibung von SAGAS vorgeschlagene Lösung besteht darin, eine lange Transaktion in Teile aufzuteilen.
Es scheint mir, dass viele sich dem näherten, ohne dieses Dokument überhaupt zu lesen. Wir haben wiederholt über unseren Defproc gesprochen (verzögerte Prozeduren, die mit pgq implementiert wurden). Wenn wir beispielsweise einen Benutzer wegen Betrugs blockieren, führen wir schnell eine kurze Transaktion durch und antworten dem Kunden. In dieser kurzen Transaktion, einschließlich, stellen wir die Aufgabe in eine Transaktionswarteschlange und dann asynchron in kleinen Stapeln, z. B. blockieren zehn Anzeigen ihre Anzeigen. Dazu haben wir Transaktionswarteschlangen von Skype implementiert.
Aber unsere heutige Geschichte ist etwas anders. Wir müssen diese Probleme von der anderen Seite betrachten: Einen Monolithen in Mikrodienste sägen, die unter Verwendung der Datenbank pro Dienstmuster erstellt wurden.
Einer der wichtigsten Parameter für uns ist das Erreichen der maximalen Schnittgeschwindigkeit. Aus diesem Grund haben wir uns entschlossen, die alte Funktionalität und die gesamte Logik auf Microservices zu übertragen, ohne etwas zu ändern. Zusätzliche Anforderungen, die wir erfüllen mussten:
- Stellen Sie abhängige Datenänderungen für geschäftskritische Daten bereit
- in der Lage sein, eine strenge Reihenfolge festzulegen;
- hundertprozentige Konsistenz einhalten - Daten auch bei Unfällen koordinieren;
- garantieren den Betrieb von Transaktionen auf allen Ebenen.
Unter den oben genannten Anforderungen ist die Lösung in Form einer orchestrierten Saga am besten geeignet.
Implementierung einer orchestrierten Saga als PG Saga-Dienst
So sieht der PG Saga-Service aus.
PG im Namen, da synchrones PostgreSQL als Service-Repository verwendet wird. Was ist noch drin:
- API
- Testamentsvollstrecker;
- checker;
- Gesundheitsprüfer;
- Kompensator.
Das Diagramm zeigt auch den Dienstbesitzer der Sagen. Nachfolgend sind die Dienste aufgeführt, die die Schritte der Saga ausführen. Sie können unterschiedliche Repositorys haben.
Wie funktioniert es?
Betrachten Sie das Beispiel des Kaufs von VAS-Paketen. VAS (Values-Added Services) - kostenpflichtige Services für die Anzeigenwerbung.
Zunächst muss der Servicebesitzer der Saga die Erstellung der Saga im Saga-Service registrieren
Danach wird bereits mit Payload eine Saga-Klasse generiert.
Darüber hinaus nimmt der Executor bereits im Sag-Service den zuvor erstellten Saga-Aufruf aus dem Store entgegen und beginnt mit der schrittweisen Ausführung. Der erste Schritt in unserem Fall ist der Kauf eines Premium-Abonnements. In diesem Moment ist Geld im Abrechnungsservice reserviert.
Dann werden im Dienst des Benutzers VAS-Operationen angewendet.
Dann sind die VAS-Dienste bereits vorhanden und Ihre Pakete werden erstellt. Weitere Schritte sind weiter möglich, aber für uns nicht so wichtig.
Abstürze
Unfälle können in jedem Dienst auftreten, aber es gibt bekannte Tricks, wie man sich darauf vorbereitet. In einem verteilten System ist es wichtig, diese Techniken zu kennen. Eine der wichtigsten Einschränkungen ist beispielsweise, dass das Netzwerk nicht immer zuverlässig ist. Ansätze, die die Interaktionsprobleme in verteilten Systemen lösen:
- Wir versuchen es erneut.
- Wir markieren jede Operation mit einem idempotenten Schlüssel. Dies ist erforderlich, um Doppelarbeit zu vermeiden. Weitere Informationen zu idempotenten Schlüsseln finden Sie in diesem Artikel.
- Wir kompensieren Transaktionen - eine für Sagen charakteristische Aktion.
Transaktionskompensation: Wie es funktioniert
Für jede positive Transaktion müssen wir die umgekehrten Aktionen beschreiben: ein Geschäftsszenario des Schritts für den Fall, dass etwas schief geht.
In unserer Implementierung bieten wir folgendes Vergütungsszenario an:
Wenn ein Schritt der Saga erfolglos war und wir viele Wiederholungsversuche unternommen haben, besteht die Möglichkeit, dass die letzte Wiederholung der Operation erfolgreich war, aber wir haben einfach keine Antwort erhalten. Wir werden versuchen, die Transaktion zu kompensieren, obwohl dieser Schritt nicht erforderlich ist, wenn der Service Executor des Problemschritts wirklich zusammengebrochen ist und vollständig unzugänglich ist.
In unserem Beispiel sieht es so aus:
- Schalten Sie VAS-Pakete aus.
- Brechen Sie den Benutzervorgang ab.
- Wir stornieren die Reservierung von Geldern.
Was tun, wenn die Entschädigung nicht funktioniert?
Offensichtlich müssen wir ungefähr das gleiche Szenario anwenden. Wenden Sie erneut idempotente Wiederholungsschlüssel an, um Transaktionen zu kompensieren. Wenn diesmal jedoch nichts herauskommt, z. B. der Dienst nicht verfügbar ist, müssen Sie sich an den Dienstbesitzer der Saga wenden und Sie darüber informieren, dass die Saga fehlgeschlagen ist. Weitere schwerwiegendere Maßnahmen: Eskalieren Sie das Problem, z. B. für einen manuellen Test oder starten Sie die Automatisierung, um solche Probleme zu lösen.
Was wichtiger ist: Stellen Sie sich vor, dass ein Schritt des Saga-Dienstes nicht verfügbar ist. Sicher wird der Initiator dieser Aktionen einige Wiederholungsversuche durchführen. Und am Ende macht Ihr Saga-Service den ersten Schritt, den zweiten Schritt, und sein Executor ist nicht verfügbar. Sie brechen den zweiten Schritt ab, brechen den ersten Schritt ab, und es kann auch Anomalien geben, die mit dem Mangel an Isolation verbunden sind. Im Allgemeinen ist der Saga-Dienst in dieser Situation mit nutzloser Arbeit beschäftigt, die immer noch eine Last und Fehler erzeugt.
Wie geht das? Healthchecker sollte die Dienste befragen, die die Durchhangschritte ausführen, und prüfen, ob sie funktionieren. Wenn der Dienst nicht mehr verfügbar ist, gibt es zwei Möglichkeiten: Sie können die in Betrieb befindlichen Sagen kompensieren und verhindern, dass neue Sagen neue Instanzen (Aufrufe) erstellen, oder sie erstellen, ohne sie als Executer zu verwenden, damit der Dienst dies nicht tut unnötige Aktionen.
Ein weiteres Unfallszenario
Stellen Sie sich vor, wir machen wieder das gleiche Premium-Abonnement.
- Wir kaufen VAS-Pakete und reservieren Geld.
- Wir wenden Dienstleistungen auf den Benutzer an.
- Wir erstellen VAS-Pakete.
Es scheint gut zu sein. Nach Abschluss der Transaktion stellt sich jedoch plötzlich heraus, dass im Benutzerdienst eine asynchrone Replikation verwendet wird und auf der Master-Basis ein Unfall aufgetreten ist. Es kann mehrere Gründe für eine Verzögerung des Replikats geben: Eine bestimmte Belastung des Replikats, die entweder die Geschwindigkeit der Replikationswiedergabe verlangsamt oder die Replikationswiedergabe blockiert. Außerdem kann die Quelle (Master) überlastet werden, und auf der Quellseite tritt eine Verzögerung beim Senden von Änderungen auf. Im Allgemeinen blieb die Replik aus irgendeinem Grund zurück, und die Änderungen des erfolgreich abgeschlossenen Schritts nach dem Unfall verschwanden plötzlich (Ergebnis / Zustand).
Dazu implementieren wir eine weitere Komponente im System - wir verwenden Checker. Checker durchläuft alle Schritte erfolgreicher Sagen in einer Zeit, die bekanntermaßen größer ist als alle möglichen Verzögerungen (z. B. nach 12 Stunden), und prüft, ob sie noch erfolgreich abgeschlossen wurden. Wenn der Schritt plötzlich fehlschlägt, rollt die Saga zurück.
Es kann auch Situationen geben, in denen nach 12 Stunden bereits nichts mehr abzubrechen ist - alles ändert sich und bewegt sich. In diesem Fall kann die Lösung anstelle des Stornierungsszenarios darin bestehen, dem Service des Saga-Besitzers zu signalisieren, dass dieser Vorgang nicht abgeschlossen wurde. Wenn der Stornierungsvorgang beispielsweise nicht möglich ist, müssen Sie nach dem Aufladen des Benutzers eine Stornierung vornehmen, und sein Guthaben ist bereits Null, und das Geld kann nicht abgeschrieben werden. Wir haben solche Szenarien immer in Richtung des Benutzers gelöst. Möglicherweise haben Sie ein anderes Prinzip, das mit den Vertretern des Produkts übereinstimmt.
Wie Sie vielleicht bemerkt haben, müssen Sie daher an verschiedenen Stellen für die Integration in den Sag-Service viele verschiedene Logikfunktionen implementieren. Wenn Kundenteams eine Saga erstellen möchten, haben sie daher eine sehr große Anzahl von nicht offensichtlichen Aufgaben. Zunächst erstellen wir eine Saga, damit die Duplizierung nicht funktioniert. Dazu arbeiten wir mit einer idempotenten Operation zum Erstellen einer Saga und ihrer Verfolgung. In Diensten ist es auch erforderlich, die Fähigkeit zu realisieren, jeden Schritt jeder Saga zu verfolgen, um sie einerseits nicht zweimal auszuführen und andererseits zu beantworten, ob sie tatsächlich abgeschlossen wurde. Und all diese Mechanismen müssen irgendwie gewartet werden, damit die Service-Repositorys nicht überlaufen. Darüber hinaus gibt es viele Sprachen, in denen Dienste geschrieben werden können, und eine große Auswahl an Repositorys. In jeder Phase müssen Sie die Theorie verstehen und all diese Logik in verschiedenen Teilen implementieren. Wenn Sie dies nicht tun, können Sie eine ganze Reihe von Fehlern machen.
Es gibt viele richtige Wege, aber es gibt nicht weniger Situationen, in denen Sie sich selbst ein Glied schießen können. Damit die Sagen korrekt funktionieren, müssen Sie alle oben genannten Mechanismen in Client-Bibliotheken kapseln, die sie für Ihre Clients transparent implementieren.
Ein Beispiel für die Logik zur Saga-Generierung, die in der Client-Bibliothek ausgeblendet werden kann
Es kann anders gemacht werden, aber ich schlage den folgenden Ansatz vor.
- Wir erhalten die Anforderungs-ID, mit der wir die Saga erstellen müssen.
- Wir gehen zum Durchhangdienst, erhalten seine eindeutige Kennung und speichern ihn im lokalen Speicher in Verbindung mit der Anforderungs-ID von Punkt 1.
- Führen Sie die Saga mit Nutzlast im Durchhangdienst aus. Eine wichtige Nuance: Ich schlage vor, lokale Operationen des Dienstes, der die Saga erstellt, als ersten Schritt der Saga zu entwerfen.
- Es gibt eine bestimmte Rasse, in der der Saga-Dienst diesen Schritt ausführen kann (Punkt 3), und unser Backend, das die Erstellung der Saga initiiert, wird ihn ebenfalls ausführen. Dazu führen wir überall idempotente Operationen durch: Eine Person führt sie aus, und der zweite Anruf erhält einfach „OK“.
- Wir rufen den ersten Schritt (Punkt 4) auf und antworten erst danach dem Kunden, der diese Aktion initiiert hat.
In diesem Beispiel arbeiten wir mit der Saga als Datenbank. Sie können eine Anfrage senden, und dann wird die Verbindung möglicherweise unterbrochen, aber die Aktion wird ausgeführt. Dies ist ungefähr der gleiche Ansatz.
Wie man alles überprüft
Es ist notwendig, den gesamten Service von Durchhangtests abzudecken. Höchstwahrscheinlich werden Sie Änderungen vornehmen, und die zu Beginn geschriebenen Tests helfen, unerwartete Überraschungen zu vermeiden. Außerdem müssen die Sagen selbst überprüft werden. Zum Beispiel, wie wir das Testen des Durchhangdienstes und das Testen der Durchhangsequenz in einer Transaktion arrangieren. Es gibt verschiedene Testblöcke. Wenn wir über den Durchhangdienst sprechen, weiß er, wie man positive Transaktionen und Vergütungstransaktionen durchführt. Wenn die Vergütung nicht funktioniert, informiert er den Durchhangbesitzer des Dienstes. Wir schreiben allgemein Tests für die Arbeit mit einer abstrakten Saga.
Auf der anderen Seite sind positive Transaktionen und Vergütungstransaktionen für Services, die Durchhangschritte ausführen, eine einfache API, und die Tests dieses Teils liegen in der Verantwortung des Teams, dem dieser Service gehört.
Und dann schreibt das Team der Saga-Besitzer End-to-End-Tests, bei denen überprüft wird, ob die gesamte Geschäftslogik bei der Ausführung der Saga ordnungsgemäß funktioniert. Der End-to-End-Test wird in einer vollständigen Entwicklungsumgebung ausgeführt, alle Dienstinstanzen, einschließlich des Sag-Dienstes, werden ausgelöst, und dort wird bereits ein Geschäftsszenario getestet.
Gesamt:
- schreibe mehr Unit-Tests;
- Integrationstests schreiben;
- Schreiben Sie End-to-End-Tests.
Der nächste Schritt ist CDC. Die Microservice-Architektur wirkt sich auf die Besonderheiten von Tests aus. In Avito haben wir den folgenden Ansatz zum Testen der Microservice-Architektur gewählt: Consumer-Driven Contracts. Dieser Ansatz hilft zunächst, Probleme hervorzuheben, die in End-to-End-Tests identifiziert werden können, aber der End-to-End-Test ist „sehr teuer“.
Was ist die Essenz von CDC? Es gibt einen Dienst, der einen Vertrag bereitstellt. Er hat eine API - dies ist ein Anbieter. Und es gibt einen anderen Dienst, der die API aufruft, dh den Vertrag verwendet - Consumer.
Der Verbraucherservice schreibt Tests für den Vertrag des Anbieters, und Tests, die nur vom Vertrag überprüft werden, sind keine Funktionstests. Es ist wichtig, dass wir sicherstellen, dass beim Ändern der API die Schritte in diesem Kontext nicht unterbrochen werden. Nachdem wir die Tests geschrieben haben, wird ein weiteres Element des Service Brokers angezeigt - Informationen zu CDC-Tests werden darin aufgezeichnet. Jedes Mal, wenn der Provider-Dienst geändert wird, wird eine isolierte Umgebung erstellt und die vom Verbraucher geschriebenen Tests ausgeführt. Was ist das Endergebnis: Das Team, das die Sagen erstellt, schreibt Tests für alle Schritte der Geschichte und registriert sie.
Über die Implementierung des CDC-Ansatzes durch Avito zum Testen von Mikrodiensten sprach Frol Kryuchkov auf der RIT ++. Abstracts finden Sie auf der Website Backend.conf - Ich empfehle Ihnen, sich vertraut zu machen.
Arten von Sagen
In der Reihenfolge der Funktionsaufrufe
a) ungeordnet - die Funktionen der Saga werden in beliebiger Reihenfolge aufgerufen und warten nicht darauf, dass sie sich gegenseitig abschließen;
b) geordnet - die Funktionen der Saga werden in der angegebenen Reihenfolge nacheinander aufgerufen, die nächste wird erst aufgerufen, wenn die vorherige abgeschlossen ist;
c) gemischt - für einen Teil der Funktionen wird die Reihenfolge festgelegt, für den Teil jedoch nicht, sondern vor oder nach den Stufen, in denen sie ausgeführt werden sollen.
Stellen Sie sich ein bestimmtes Szenario vor. Im gleichen Szenario wie beim Kauf eines Premium-Abonnements besteht der erste Schritt darin, Geld zu reservieren. Jetzt können wir Änderungen am Benutzer vornehmen und parallel Premium-Pakete erstellen. Wir werden den Benutzer erst benachrichtigen, wenn diese beiden Schritte abgeschlossen sind.
Indem Sie das Ergebnis des Funktionsaufrufs erhalten
a) synchron - das Ergebnis der Funktion ist sofort bekannt;
b) asynchron - Die Funktion gibt sofort "OK" zurück und das Ergebnis wird später durch einen Rückruf an die Sag-Service-API vom Client-Service zurückgegeben.
Ich möchte Sie vor einem Fehler warnen: Es ist besser, keine synchronen Schritte der Sagen auszuführen, insbesondere wenn Sie eine orchestrierte Saga implementieren. Wenn Sie synchrone Durchhangschritte ausführen, wartet der Durchhangdienst, bis dieser Schritt abgeschlossen ist. Dies ist eine zusätzliche Belastung, zusätzliche Probleme im Dienst von Sagen, da es eines ist und es viele Teilnehmer an Sagen gibt.
Durchhangskalierung
Die Skalierung hängt von der Größe des von Ihnen geplanten Systems ab. Betrachten Sie die Option mit einer einzelnen Speicherinstanz:
- Ein Saga-Step-Handler verarbeitet die Schritte mit Chargen.
- In Handlern implementieren wir einen „Kamm“ - wir unternehmen Schritte für den Rest der Division: Wenn jeder Executor seine eigenen Schritte erhält.
- n Handler und Skip Locked - werden noch effizienter und flexibler.
Und nur dann, wenn Sie im Voraus wissen, dass Sie auf die Leistung eines Servers in einem DBMS stoßen, müssen Sie Sharding-n-Datenbankinstanzen ausführen, die mit ihrem Datensatz funktionieren. Sharding kann hinter der Sag-Service-API versteckt werden.
Mehr Flexibilität
Darüber hinaus kann in diesem Muster zumindest theoretisch der Client-Service (der den Saga-Schritt ausführt) auf den Sag-Service zugreifen und in diesen passen, und die Teilnahme an der Saga kann ebenfalls optional sein. Möglicherweise gibt es auch ein anderes Szenario: Wenn Sie bereits eine E-Mail gesendet haben, kann die Aktion nicht kompensiert werden. Sie können den Brief nicht zurücksenden. Aber Sie können einen neuen Brief senden, dass der vorherige falsch war, und es sieht so aus. Es ist besser, ein Szenario zu verwenden, in dem die Saga nur vorwärts ohne Kompensation gespielt wird. Wenn es nicht vorwärts abgespielt wird, muss der Service des Saga-Besitzers über das Problem informiert werden.
Wann brauchen Sie ein Schloss
Ein kleiner Exkurs über die Sagen im Allgemeinen: Wenn Sie Ihre Logik ohne die Saga machen können, dann tun Sie es. Sagen sind schwer. Bei der Sperre ist es ungefähr dasselbe: Es ist besser, Sperren immer zu vermeiden.
Als ich zum Abrechnungsteam kam, um über Sagen zu sprechen, sagten sie, dass sie ein Schloss brauchten. Ich konnte ihnen erklären, warum es besser ist, darauf zu verzichten und wie man es macht. Wenn Sie jedoch noch ein Schloss benötigen, sollte dies im Voraus vorgesehen werden. Vor dem Sag-Service haben wir bereits Sperren im Rahmen eines DBMS implementiert. Ein Beispiel mit defproc und einem Skript zum asynchronen Blockieren von Anzeigen und zum synchronen Blockieren eines Kontos, wenn wir zuerst einen Teil des Vorgangs synchron ausführen und die Sperre setzen und dann den Rest der Arbeit mit Stapeln asynchron beenden.
Wie kann man das machen? , , , , , - , . . . : , , .
-, , . , , . , , . . — , , .
ACID —
, , . . — durability. . . , . - , - - ,
— - , - , , - , . , - , - .
— .
:
- , , , , .
- , . , , , , , .
- .
- payload . eventual consistency — , , , . , , , -.
Überwachung
. , . . checker. . , .
(50%, 75%, 95%, 99%), , - .
, — , . . , - . , — .
. , - ( ) . healthchecker endpoint' info (keep-alive) .
. -. -, - , - . , , , end-to-end. - . , , — .
. .
:
, healthchecker, - , . , . .
, . , , . . choreography — - . , choreography- , . choreography , . , . , , , .
. , , . , + .
API
, - - ( API ), , API. API . — . API , , 100% .
, , , , . — , , . .
, , , . ( ) .
, , , , .
. , , .
saga call ID
. API , .
—
- legacy . , ( «» ). « »? - , , , , - , . , , , . , « », , -. . — . , .
, , . , , , , . , , . .
, . .