Client pro MicroService vs Generic Client | Wer ist für den Microservice-Client verantwortlich?
Ich habe eine microService-Architektur mit 10 microServices, von denen jeder einen Client bereitstellt. Innerhalb dieses Clients, der vom microService-Team verwaltet / gesteuert wird, erhalten wir nur die Parameter und leiten sie an einen generischen http-Aufrufer weiter, der den Endpunkt und die N-Parameter empfängt und dann den Aufruf ausführt. Alle microService verwenden http und Web-API (ich denke, Technologie spielt keine Rolle).
Für mich macht es keinen Sinn, das MicroService-Team einen Client zur Verfügung zu stellen, sollte die Verantwortung des Verbrauchers sein, wenn sie Abstraktionen erstellen oder direkt aufrufen möchten, ist ihr Problem, kein MicroService-Problem. Und die Art, wie ich eine Web-API sehe, ist ein Vertrag. Ich denke, wir sollten alle Clients auf der microService-Seite löschen (Verantwortung an die Verbraucher weitergeben) und auf der Verbraucherseite eine Service-Schicht erstellen, die den generischen Aufrufer verwendet, um die Endpunkte zu erreichen.
Das Bild unten stellt alle Komponenten dar, bei denen die rote Linie die Grenzen definiert, wer ist für was verantwortlich:
- Das Gateway verfügt über eine Adapterschicht
- Adapter-Layer verweist auf das microService-Client-Paket
- Das MicroService-Client-Paket verweist auf das generische HTTP-Aufrufpaket
Die andere Seite davon ist, weil wir vielleicht eine Anzahl von N Verbrauchern haben und sie alle den Code des Kunden wiederholen. Und wenn der microService einen Client bereitstellt, haben wir einen einzigartigen / zentralen Ort, um dies zu kontrollieren.
Welcher Ansatz ist richtig? Ist der Kunde verantwortlich für den microService oder den Verbraucher?
Dies ist ein internes Produkt.
1 Antwort
Ich habe ein ähnliches Setup bei der Arbeit, mit mehreren Microservices (~ 40) und einem Dutzend Teams. Ich wurde mehrmals dieselbe Frage gestellt, und meine Antwort lautet: Der Konsument ist verantwortlich für den Konsum . Wenn die API wie geplant und erwartet funktioniert, ist es sinnlos, das bereitstellende Team für irgendetwas verantwortlich zu machen.
Das Team, das den Service anbietet (Team a), kann einen Kunden bereitstellen, wenn er dies wünscht (im Zweifel, ohne Garantie). Das konsumierende Team (Team B) kann den Kunden verwenden, wenn er möchte (unter Berücksichtigung aller Risiken). Der einzige Vertrag sollte die API sein, alles andere sollte ein Goodie sein, das ein Team an der Spitze bereitstellen kann. Wenn Team einen Client bereitstellt, warum stellen sie dann überhaupt eine API bereit?
Da beide Teams lose miteinander verbunden sind und unterschiedliche Technologien (oder z. B. verschiedene Springframework-Versionen) verwenden können, führt die Bereitstellung einer Clientbibliothek für das andere Team zu mehr Problemen als zur Lösung von Problemen. In einer Java + Spring-Boot-Welt, z.B. Sie geraten sehr schnell in Abhängigkeitsprobleme, besonders wenn Sie mehrere Clients aus verschiedenen Service-Bereitstellungsteams einschließen, die sich zeitlich unterschiedlich entwickeln.
Und noch schlimmer: Was, wenn die Client-Bibliothek von Team A das System von Team B instabil macht und Bugs einführt? Wer ist dafür verantwortlich, das jetzt zu beheben?
Wenn Sie die Arbeit, die für Ihre konsumierenden Teams erforderlich ist, reduzieren möchten, weil die Umcodierung des Clients so viel Arbeit kostet, ist Ihre API möglicherweise zu komplex und / oder Ihr Microservice ist möglicherweise kein Microservice mehr. Stellen Sie sich vor, Sie verwenden HATEOAS für eine restliche API - einen Client zu schreiben, das sind nur ein paar Zeilen Code, sogar mit dem enthaltenen API-Browser, Dokumentation und so weiter. Siehe z.B. Spring-Rest-Dokumente, Hal-Browser, Swagger und verschiedene andere Technologien, die das Lesen / Durchsuchen / Dokumentieren einer API und die Implementierung eines Clients zum Kinderspiel machen.
Die obigen Fälle werden mit zwei Teams beschrieben, stellen Sie sich das mit 10. Wir hatten eine "Client-Bibliothek", die von einem Team bereitgestellt wurde und von vier anderen Teams verwendet wurde. Sie können raten, wie schnell es zu einem kompletten Chaos wurde, bis es gerade gelöscht wurde:)
Tags und Links distributed-computing microservices