Laufender Lagom in Produktion

Question

Ich arbeite an der Einrichtung einer Lagom-Anwendung in der Produktion. Ich habe versucht, Lightbend für ConductR-Lizenz in Verbindung zu treten, aber habe in Jahren nicht mehr gehört. Also, jetzt suche ich nach einem alternativen Ansatz. Ich habe mehrere Fragen.

Da der Umfang der Anwendung im Moment ziemlich klein ist, denke ich, dass die Verwendung eines statischen Service Locators für mich jetzt funktioniert (offen für andere Alternativen). Außerdem verwende ich MySQL als meinen Ereignisspeicher anstelle der Standardkonfiguration von Cassandra (Gründe, die für diesen Thread nicht relevant sind).

Cassandra und Lagom des Service Locator zu unterdrücken, habe ich die folgenden Zeilen zu meinem build.sbt hinzugefügt:

lagomCassandraEnabled in ThisBuild := false 

ich das folgende Stück meiner application.conf mit service1-impl-Modul haben ebenfalls hinzugefügt. mit sbt runAll in einer tmux Sitzung

lagom.services { 
    service1 = "http://0.0.0.0:8080" 
} 

Für die Entwickler-Umgebung konnte ich erfolgreich meine Anwendung auszuführen. Bei dieser Konfiguration wird kein Service Locator auf dem Standard-8000-Port ausgeführt, aber ich kann Service1 auf 8080-Port einzeln treffen. (Nicht sicher, ob dies das erwartete Verhalten ist. Kommentare?)

Ich lief sbt dist, um eine Zip-Datei zu erstellen und entpackte es dann und lief die ausführbare Datei dort. Interessanterweise wurde die Zip im Ordner service1-impl erstellt. Also, wenn ich mehrere Module (Dienste?) Habe, wird sbt dist individuelle Zip-Dateien für jeden der Dienste erstellen?

Wenn ich die ausführbare Datei über sbt dist ausführe, versucht es, eine Verbindung zu Cassandra herzustellen, und startet auch einen Service-Locator und ignoriert die statische Service-Locator-Konfiguration, die ich hinzugefügt habe. Im Grunde sieht es so aus, als ob es die Zeilen ignoriert, die ich zu build.sbt hinzugefügt habe. Wer kann das erklären?

Zuletzt, wenn ich 2 Dienste, service1 und service2, und 2 Knoten im Cluster mit Knoten 1, der service1 und Knoten 2 ausgeführt beide Dienste, wie würde meine statische Service Locator in der application.conf aussehen würde und da jeder Dienst eine eigene application.conf hätte, müsste ich die selbe Konfiguration kopieren Statischer Service Locator in allen application.confs?

Würde es so etwas sein?

lagom.services { 
    service1 = "http://0.0.0.0:8080" 
    service1 = "http://1.2.3.4:8080" 
    service2 = "http://1.2.3.4:8081" 
} 

Da jeder spezifische Schauspieler würde auf einem der Knoten hervorgebracht werden, wie wäre es mit diesem Service-Locator-Konfiguration arbeiten?

Auch ich möchte dies nicht in einer tmux-Sitzung in der Produktion ausführen. Was wäre der beste Weg, diesen Code endlich in der Produktion zu verwenden?

Answer 1

Sie können mit dem ConductR im Dev-Modus sofort kostenlos beginnen, ohne sich mit dem Verkauf in Verbindung zu setzen. Anweisungen sind unter: https://www.lightbend.com/product/conductr/developer Sie müssen sich registrieren (lesen Sie: eine gültige E-Mail) und akzeptieren TnC für den Zugriff auf diese Seite. Die Sandbox kann heute für den Dev-Modus verwendet werden. So können Sie schnell und einfach feststellen, ob ConductR für Sie geeignet ist.

Für die Produktion bin ich begeistert zu sagen, dass Sie bald bis zu 3 Knoten in der Produktion bereitstellen können, wenn Sie sich mit Lightbend.com (wie oben) registrieren und einen Lizenzschlüssel für die 'freie Stufe' generieren .

Lagom ist eine Meinung über Microservices. Es gibt immer Akka und Play, wenn diese Meinungen nicht von einem Projekt geteilt werden.Teil dieser Meinung ist, dass die Bereitstellung einfach sein sollte. Gute Werkzeuge fühlen sich "richtig" in der Hand an. Natürlich können Sie die App frei einrichten, wie Sie möchten, aber seien Sie bereit, auf den markierten Wegen mehr Polyfill zu produzieren.

In Bezug auf Service-Lookup stellt ConductR Umleitung für HTTP-Service-Lookups für die Verwendung mit 'withFollowRedirects' auf Play WS [1] In Bezug auf sbt dist jedes Teilprojekt Service wird ein Paket sein. Sie können dies im Chirper-Beispiel [2] sehen, auf dem sbt dist chirp-impl.zip, friend-impl.zip, activity-stream-impl usw. generiert, wie in der Chirper-Datei build.sbt auf der obersten Ebene zu sehen ist. Da das ConductR der saubere und beleuchtete Pfad ist, können Sie sich darauf beziehen, wie es funktioniert, um besser zu verstehen, wie Sie Lagoms Deployment-Poly-W/Ihre eigenen ersetzen können. Das ist die Schnittstelle, die Lagom am besten kennt. Viel von ConductR außer dem Kern ist bereits OSS, so kann Github versuchen, wenn die Dokumente etwas nicht abdecken.

Disclosure: Ich bin ein ConductR-ing Lightbender.

1. http://conductr.lightbend.com/docs/1.1.x/ResolvingServices

2. git@github.com: lagom/Aktivator-lagom-java-chirper.git