Microservices

A Microservice Architektur - eine Variante der SOA (Serviceorientierte Architektur) Strukturstil - arrangiert eine Anwendung als Sammlung von locker verbunden Dienstleistungen. In einer Microservices-Architektur sind die Dienste feinkörnig und die Protokolle sind Leicht. Das Ziel ist, dass Teams ihre Dienste unabhängig von anderen zum Leben erwecken können. Lose Kupplung reduziert alle Arten von Abhängigkeiten und die Komplexität, da Serviceentwickler sich nicht um die Benutzer des Dienstes kümmern müssen, sondern dass sie ihre Änderungen nicht auf Benutzer des Dienstes zwingen.[1][Klarstellung erforderlich] Daher ermöglicht es Unternehmen, die Software entwickeln, schnell und groß zu wachsen, sowie leichtere Nutzungsdienste. Die Kommunikationsanforderungen werden reduziert. Diese Vorteile sind Kosten für die Aufrechterhaltung der Entkopplung. Schnittstellen müssen sorgfältig entwickelt und als öffentliche API behandelt werden. Eine Technik, die verwendet wird, besteht darin, mehrere Schnittstellen für denselben Dienst oder mehrere Versionen desselben Dienstes zu haben, um vorhandene Benutzer des Codes nicht zu stören.

Einführung

Es gibt keine einzige Definition für Microservices. Eine Konsensansicht hat sich im Laufe der Zeit in der Branche entwickelt. Einige der häufig zitierten definierenden Eigenschaften sind:

Ein Microservice ist keine Schicht innerhalb einer monolithischen Anwendung (Beispiel, Webcontroller oder Backend-for-Frontend).[8] Es handelt sich vielmehr um ein in sich geschlossenes Unternehmensfunktionalität mit klaren Schnittstellen und kann durch eigene interne Komponenten eine geschichtete Architektur implementieren. Aus strategischer Sicht folgt die Microservice -Architektur im Wesentlichen der Unix -Philosophie von "Mach eins und mach es gut".[9] Martin Fowler Beschreibt eine auf Microservices basierende Architektur als folgende Eigenschaften:[2]

Es ist üblich, dass Microservices -Architekturen eingesetzt werden, für die Cloud-native Anwendungen, Serverloses Computerund Anwendungen mit Leichtgewicht Container Einsatz. Laut Fowler aufgrund der großen Anzahl (im Vergleich zu monolithischen Anwendungen) von Diensten, dezentrale kontinuierliche Lieferung und DevOps Bei ganzheitlicher Serviceüberwachung sind die solchen Anwendungen effektiv zu entwickeln, zu warten und zu betreiben.[12] Eine Folge von (und Begründung) nach diesem Ansatz ist, dass die einzelnen Mikrodienste individuell skaliert werden können. Im monolithischen Ansatz müsste eine Anwendung, die drei Funktionen unterstützt, vollständig skaliert werden, auch wenn nur eine dieser Funktionen eine Ressourcenbeschränkung hätte.[13] Bei Microservices muss nur der Microservice, der die Funktion mit Ressourcenbeschränkungen unterstützt, skaliert werden, wodurch Ressourcen- und Kostenoptimierungsvorteile bieten.[14]

Geschichte

Es gibt zahlreiche Behauptungen über den Ursprung des Begriffs Microservices. Während Vizepräsident von Gedankenwerke Im Jahr 2004 begann Fred George an Prototyp -Architekturen zu arbeiten, basierend auf den nach Jeff Bay benannten "baysischen Prinzipien".[15]

Bereits 2005 führte Peter Rodgers den Begriff "Mikro-Internetdienste"Während einer Präsentation auf der Web Services Edge Conference. gegen konventionelles Denken und auf dem Höhepunkt der SEIFE SOA Architektur Hype -Kurve Er hat sich gestritten "SICH AUSRUHEN-Services "und auf Folie 4 der Konferenzpräsentation, diskutiert er"Softwarekomponenten sind Mikro-Web-Dienste ".[16] Er fährt fort: "Mikrodienste werden mit Verwendung komponiert Unix-ähnliche Pipelines (das Netz trifft Unix = true lose Kopplung). Dienste können Dienste (+mehrfach Sprachlaufzeiten) anrufen. Komplexe Service -Baugruppen sind hinter einfach abstrahiert Uri Schnittstellen. Jeder Dienst kann in jeder Granularität freigelegt werden. "Er beschrieb, wie eine gut gestaltete Microservices-Plattform" die zugrunde liegenden architektonischen Prinzipien der Anstrengungen anwendet Netz und REST-Dienste zusammen mit Unix-ähnlichen Planung und Pipelines, um radikale Flexibilität und verbesserte Einfachheit in serviceorientierten Architekturen zu bieten.[17]

Rodgers 'Arbeiten entstand 1999 mit dem Dexter -Forschungsprojekt bei Hewlett Packard Labs, dessen Ziel es war, Code weniger spröde zu machen und große, komplexe Softwaresysteme herzustellen robust wechseln.[18] Letztendlich führte dieser Forschungsweg zur Entwicklung von Ressourcenorientiertes Computer (ROC), eine verallgemeinerte Berechnungsabstraktion, bei der Ruhe eine spezielle Teilmenge ist.

Im Jahr 2007 in seinem Schreiben Juval Löwy[19] und sprechen[20][21] forderte nach Bausystemen, in denen jede Klasse ein Dienst war. Löwy hat erkannt Windows Communication Foundation (WCF) genau das tun,[22][23] Nehmen Sie jede Klasse und behandeln Sie sie als Service und halten Sie das konventionelle Programmiermodell von Klassen.

Im Jahr 2005 Alistair Cockburn geschrieben über Sechseckige Architektur (Software) Dies ist ein Software -Designmuster, das zusammen mit den Microservices verwendet wird. Dieses Muster ermöglicht das Design des Microservice, da es in Schichten die Geschäftslogik aus den Hilfsdiensten isoliert, die benötigt werden, um den Microservice vollständig unabhängig von anderen bereitzustellen und auszuführen.

Ein Workshop von Software -Architekten in der Nähe von Venedig im Mai 2011 verwendete den Begriff "Microservice", um zu beschreiben, was die Teilnehmer als gemeinsamen architektonischen Stil ansah, den viele von ihnen kürzlich untersucht hatten.[24] Im Mai 2012 entschied sich dieselbe Gruppe für "Microservices" als den am besten geeigneten Namen. James Lewis präsentierte einige dieser Ideen als Fallstudie Im März 2012 am 33. Grad in Kraków in Microservices - Java, The Unix Way,[25] ebenso wie Fred George[26] Etwa zur gleichen Zeit. Adrian Cockcroft, ehemaliger Direktor für die Cloud Systems bei Netflix,[27] beschrieben diesen Ansatz als "feinkörniger SOA", wie viele der anderen, die in diesem Artikel erwähnt wurden-Joe Walnes, Dan North, Evan Bottcher und Graham Tackley, Pionier.[28]

Microservices ist eine Spezialisierung eines Implementierungsansatzes für Service-orientierte Architekturen (SOA) zum Aufbau flexibler, unabhängig einsetzbarer Erstellung Softwaresysteme.[5] Der Microservices -Ansatz ist die erste Erkenntnis von SOA, die auf die Einführung der Einführung von DevOps und wird immer beliebter für den Bau kontinuierlich eingesetzt Systeme.[29]

Im Februar 2020 prognostizierte der Marktforschungsbericht von Cloud Microservices, dass die globale Marktgröße für Microservice -Architektur in a zunehmen wird CAGR von 21,37% von 2019 bis 2026 und bis 2026 3,1 Milliarden US -Dollar.[30]

Service -Granularität

Ein wesentlicher Schritt zur Definition einer Microservice -Architektur besteht darin, herauszufinden, wie groß ein einzelner Microservice sein muss. Es gibt keinen Konsens- oder Lackmustest dafür, da die richtige Antwort vom Geschäft und dem organisatorischen Kontext abhängt.[31] Zum Beispiel, Amazonas verwendet a Serviceorientierte Architektur Wo der Service oft 1: 1 mit einem Team von 3 bis 10 Ingenieuren ist.[32] Im Allgemeinen geht die Terminologie als solche: Dienstleistungen, die einer einzelnen Aufgabe gewidmet sind, z. Atomdienste. In ähnlicher Weise werden Dienste, die solche Atomdienste anrufen, um eine Ausgabe zu konsolidieren, aufgerufen zusammengesetzte Dienste.

Es wird als schlechte Praxis angesehen, den Service zu klein zu machen, da dann die Laufzeitaufwand und die betriebliche Komplexität die Vorteile des Ansatzes überwältigen können. Wenn die Dinge zu feinkörnig werden, müssen alternative Ansätze berücksichtigt werden - beispielsweise die Funktion als Bibliothek und Verschieben der Funktion in andere Microservices.[5]

Wenn die Domänengetriebenes Design wird zur Modellierung der Domäne eingesetzt, für die das System gebaut wird, und dann könnte ein Microservice so klein wie ein Aggregat oder so groß wie ein begrenzter Kontext sein.[33]

In der Granularität der Microservices -Diskussion gibt es ein Spektrum, an einem Ende gibt es die anämischen Dienste, die keine große Anzahl von Verantwortlichkeiten haben, und am anderen Ende das modulare Monolith, die große Module eines Systems sind.

Vorteile

Der Vorteil des Zersetzens einer Anwendung in verschiedene kleinere Dienste ist zahlreich:

  • Modularität: Dies erleichtert die Anwendung leichter zu verstehen, zu entwickeln, zu testen und widerstandsfähiger gegen die Architekturerosion.[6] Dieser Vorteil wird im Vergleich zur Komplexität monolithischer Architekturen häufig argumentiert.[34]
  • Skalierbarkeit: Da Microservices unabhängig voneinander implementiert und bereitgestellt werden, d. H. Sie werden in unabhängigen Prozessen ausgeführt, können sie unabhängig überwacht und skaliert werden.[35]
  • Integration von heterogenem und Legacy -Systeme: Microservices gilt als praktikables Mittel zur Modernisierung der vorhandenen monolithischen Softwareanwendung.[36][37] Es gibt Erfahrung in mehreren Unternehmen, die ihre vorhandene Software erfolgreich durch Microservices ersetzt haben oder dabei dabei sind.[38] Der Prozess für Software -Modernisierung von Legacy -Anwendungen erfolgt unter Verwendung eines inkrementellen Ansatzes.[39]
  • Verteilte Entwicklung: es parallel zu Entwicklung durch die Entwicklung kleiner autonomer Teams, um sich zu entwickeln, einsetzen und skalieren Sie ihre jeweiligen Dienstleistungen unabhängig.[40] Es ermöglicht auch die Architektur eines individuellen Dienstes durch kontinuierlich Refactoring.[41] Architekturen auf Microservice-basierter Erleichterung kontinuierliche Integration, kontinuierliche Lieferung und Bereitstellung.[42]

Kritik und Bedenken

Der Microservices -Ansatz unterliegt kritisch für eine Reihe von Themen:

  • Dienstleistungen Forminformationsbarrieren.[43]
  • Inter-Service-Aufrufe über ein Netzwerk haben in Bezug auf die Netzwerklatenz und die Nachrichtenverarbeitungszeit höhere Kosten als In-Process Anrufe innerhalb eines monolithisch Serviceprozess.[2]
  • Testen und Einsatz sind komplizierter.[44][45]
  • Die Verantwortung zwischen Diensten ist schwieriger.[6] Es kann die Kommunikation zwischen verschiedenen Teams beinhalten, die Funktionalität in einer anderen Sprache umschreiben oder sie in eine andere Infrastruktur einfügen.[2] Microservices können jedoch unabhängig vom Rest der Anwendung eingesetzt werden, während Teams, die an Monolithen arbeiten, synchronisieren müssen, um gemeinsam bereitzustellen.[39]
  • Das Betrachten der Größe der Dienstleistungen als primärer Strukturierungsmechanismus kann zu zu vielen Diensten führen, wenn die Alternative der internen Modularisierung zu einem einfacheren Design führen kann.[46] Dies erfordert das Verständnis der Gesamtarchitektur der Anwendungen und Interdependenzen zwischen Komponenten.[47]
  • Zweiphasiertes Commits gelten als Anti-Muster in Architekturen auf Mikroservices basierend, da dies zu einer engeren Kopplung aller Teilnehmer innerhalb der Transaktion führt. Das Fehlen dieser Technologie verursacht jedoch unangenehme Tänze, die von allen Transaktionsteilnehmern implementiert werden müssen, um die Datenkonsistenz aufrechtzuerhalten.[48]
  • Die Entwicklung und Unterstützung vieler Dienste ist schwieriger, wenn sie mit unterschiedlichen Tools und Technologien aufgebaut sind. Dies ist insbesondere ein Problem, wenn sich die Ingenieure häufig zwischen Projekten bewegen.[49]
  • Das Protokoll, das typischerweise mit Microservices (HTTP) verwendet wurde, wurde für öffentliche Dienste entwickelt und ist als solche für die Arbeit interner Mikrodienste, die häufig tadellos zuverlässig sein müssen, nicht geeignet.[50]
  • Obwohl die Zersetzungsmethode nicht spezifisch für Microservices ist, verwendet sie häufig eine funktionale Zerlegung, die keine Änderungen der Anforderungen behandelt und gleichzeitig die Komplexität der Dienste hinzufügt.[50]
  • Das Konzept von Microservice ist irreführend, da es nur Dienste gibt. Es gibt keine solide Definition, wenn ein Dienst beginnt oder ein Microservice nicht mehr ist.[50]
  • Datenaggregation. Um eine vollständige Sicht auf ein Arbeitssystem zu haben, muss Datensätze aus den Microservices -Repositorys extrahiert und in ein einzelnes Schema zusammengefasst werden. Zum Beispiel in der Lage sein, Betriebsberichte zu erstellen, die mit einem einzigen Microservice -Repository nicht möglich sind.

Kognitive Belastung

Die Architektur führt zu einer zusätzlichen Komplexität und neuen Problemen, mit denen man sich befassen muss, wie z. Netzwerk-Latenz, Nachrichtenformat Entwurf,[51] Backup/Verfügbarkeit/Konsistenz (BAC),[52] Lastverteilung und Fehlertoleranz.[45] All diese Probleme müssen im Maßstab angegangen werden. Die Komplexität von a Monolithische Anwendung verschwindet nicht, wenn es als eine Reihe von Mikrodiensten neu implementiert wird. Ein Teil der Komplexität wird in eine operative Komplexität übersetzt.[53] Andere Orte, an denen sich die Komplexität manifestiert, sind verstärkter Netzwerkverkehr und führen zu einer langsameren Leistung. Eine Anwendung, die aus einer beliebigen Anzahl von Mikrodiensten besteht Ökosystem, was die architektonische Komplexität erhöht.[54] Verschiedene Organisationsprinzipien (wie z. Hassoas, Schnittstellen- und Datenmodelldokumentation, die über erfasst wurden Stolzierenusw.) wurden angewendet, um die Auswirkungen einer solchen zusätzlichen Komplexität zu verringern.

Technologien

Computermikrodienste können in verschiedenen Programmiersprachen implementiert werden und verwenden möglicherweise unterschiedliche Infrastrukturen. Daher sind die wichtigsten technologischen Auswahlmöglichkeiten die Art und Weise, wie Microservices miteinander kommunizieren (synchron, asynchron, UI -Integration) und die für die Kommunikation verwendeten Protokolle (RESTFUL HTTP, Messaging, Graphql ...). In einem traditionellen System wirken sich die meisten technologischen Auswahlmöglichkeiten wie die Programmiersprache auf das gesamte System aus. Daher ist der Ansatz zur Auswahl von Technologien ganz anders.[55]

Das Eclipse Foundation hat eine Spezifikation zur Entwicklung von Mikrodiensten, Eclipse -Mikroprofile, veröffentlicht.[56][57]

Service -Netz

Siehe auch: Service -Netz

In einem Service -Netz wird jede Serviceinstanz mit einer Instanz eines Reverse -Proxy -Servers gepaart, der als Service Proxy, Sidecar Proxy oder Sidecar bezeichnet wird. Die Serviceinstanz und der Sidecar -Proxy teilen sich einen Container, und die Container werden von einem Container -Orchestrierungs -Tool wie z. B. verwaltet Kubernetes, Nomad, Docker Schwarm, oder DC/OS. Die Service -Proxys sind für die Kommunikation mit anderen Serviceinstanzen verantwortlich und können Funktionen wie Service (Instance), Lastausgleich, Authentifizierung und Autorisierung, sichere Kommunikation und andere unterstützen.

In einem Service -Mesh sollen die Service -Instanzen und ihre Sidecar -Proxys die Datenebene bilden, die nicht nur das Datenmanagement, sondern auch die Verarbeitung und Reaktion anfordert. Das Service -Netz enthält auch eine Kontrollebene für die Verwaltung der Interaktion zwischen Diensten, die durch ihre Sidecar -Proxys vermittelt wird.

Ein Vergleich von Plattformen

Die Implementierung einer Microservice -Architektur ist sehr schwierig. Es gibt viele Bedenken (siehe Tabelle unten), die jede Microservice -Architektur beheben muss. Netflix entwickelte ein MicroService-Framework, um ihre internen Anwendungen zu unterstützen, und dann Open-Sourcing[58] viele Teile dieses Rahmens. Viele dieser Tools wurden über die populär gemacht Federgerüst -Sie wurden als federbasierte Werkzeuge unter dem Dach der Federwolke neu implementiert[59] Projekt. Die folgende Tabelle zeigt einen Vergleich einer Implementierungsfunktion aus der Kubernetes Ökosystem mit einem Äquivalent aus der Frühlingswolkenwelt.[60] Ein bemerkenswerter Aspekt des Frühlings-Cloud-Ökosystems ist, dass sie alle Java-basierte Technologien sind, während Kubernetes eine Polyglot-Laufzeitplattform ist.

Microservices Sorge Spring Cloud & Netflix OSS Kubernetes
Konfigurationsverwaltung: Die Konfiguration für eine MicroService -Anwendung muss aus dem Code externalisiert und über einen einfachen Serviceanruf abgerufen werden. Spring Config Server, Netflix Archaius unterstützt beide ein Git-Repository-basierter Speicherort für die Konfiguration. Archaius unterstützt die Datenmeldung der Konfiguration. Kubernetes configMaps enthält die in etcd gespeicherte Konfiguration über Dienste. Kubernetes Secrets unterstützt die servicebasierte sichere Bereitstellung und Verwendung sensibler Konfigurationsinformationen (wie Passwörter, Zertifikate usw.).
Service -Entdeckung: Verwalten Sie eine Liste von Serviceinstanzen, die für die Arbeit in einer Microservice -Domäne verfügbar sind. Mit Spring Cloud Eureka können sich Clients daran registrieren, einen Herzschlag mit registrierten Clients unterhält und Servicenamen für Kunden für Clients, die nach Servicenamen suchen, nach HostNames sorgen. Kubernetes-Dienste bieten eine Registrierung von Diensten für die Bereitstellung von Diensten, die im Cluster intern verfügbar sind. Ingress ist ein Mechanismus, bei dem ein Service Kunden außerhalb des Clusters ausgesetzt sein kann.
Lastausgleich: Der Schlüssel zur Skalierung eines verteilten Systems besteht darin, mehr als eine Instanz einer Komponente auszuführen. Die Last muss dann über einen Lastausgleich über diese Instanzen verteilt werden. Das Spring Cloud Ribbon bietet Service -Clients die Möglichkeit, Gleichgewicht über Instanzen des Dienstes zu laden. Der Kubernetes-Service bietet die Möglichkeit, dass der Service über Serviceinstanzen hinweg geladen wird. Dies ist nicht das Äquivalent zu dem, was das Band bietet.
API -Gateway: Die Granularität der von Microservices bereitgestellten APIs unterscheidet sich häufig von dem, was ein Service -Client benötigt. API -Gateways implementieren Fassaden und bieten zusätzliche Dienste wie Proxying und Protokollübersetzung und andere Verwaltungsfunktionen an. Spring Cloud Zuul bietet konfigurationsbasierte API-Fassaden Kubernetes Service und Ingress Resources, Istio, Botschafter sind Lösungen, die sowohl Nord -Süd -Out (Verkehr in und außerhalb des Rechenzentrums) als auch Ost -West -API -Gateway -Funktionen (Verkehr über Rechenzentren oder Wolken oder Regionen) bereitstellen. Zuul kann auch zusammen mit Kubernetes implementiert werden, was auf individuelle Serviceebene eine Konfiguration bereitstellt.
Sicherheitsbedenken: Viele Sicherheitsbedenken werden in die Implementierung der API -Gateway gedrängt. Bei verteilten Microservice -Anwendungen ist es sinnvoll, das Sicherheitsrad nicht neu zu erfinden und die Richtliniendefinition und -implementierung in Komponenten zu ermöglichen, die von allen Diensten gemeinsam genutzt werden. Spring Cloud Security befasst sich mit vielen Sicherheitsbedenken durch Spring Cloud Zuul Das Kubernetes -Ökosystem bietet Service -Maschen wie Istio, die in der Lage sind, durch ihre API -Gateway -Mechanismen Sicherheit zu bieten.
Zentralisierte Protokollierung: Es ist wichtig, dass eine zentrale Infrastruktur für Protokoll -Sammel- und Analyse eine Vielzahl von Diensten verwaltet - von denen viele verteilt arbeiten. Elchstapel (Elasticsarch, Logstash, Kibana)) EFK -Stack (Elasticsarch, Fließend, Kibana))
Zentralisierte Metriken: Ein zentraler Bereich, in dem die Gesundheit und Leistung der einzelnen Dienste und des Gesamtsystems überwacht werden können, ist für die ordnungsgemäßen Vorgänge von wesentlicher Bedeutung. Frühlingszuschauer & Atlas Heapster, Prometheus & Grafana
Verteilte Verfolgung: Die Protokollierung von Prozess und die metrische Überwachung haben ihren Platz, aber auch nicht die komplexen Pfade rekonstruieren, die Transaktionen bei der Ausbreitung über ein verteiltes System einnehmen. Die verteilte Verfolgung ist ein wesentliches Werkzeug für eine Microservices -Plattform. Frühlingswolke Sleuth Hawkular, Jaeger
Resilienz und Fehlertoleranz: Verteilte Systeme müssen in der Lage sein, Fehler um Fehler zu machen, und können Anforderungen an die Serviceinstanz weiterleiten, die eine optimale Antwort bieten. Frühlingshystrix, Turbine und Band Gesundheitskontrolle, Service -Netze (Beispiel: Istio)[61]
Autoscaling und Selbstheilung: Verteilte Systeme reagieren auf eine höhere Belastung durch horizontaler Skalierung: Die Plattform muss solche Bedingungen erkennen und automatisch beantworten. Darüber hinaus muss das System Fehler erkennen und automatisch ohne Bedienereingang versuchen. - Gesundheitsprüfung, Selbstheilung und automatische Skalierung
Verpackung, Bereitstellung und Planung: Große Systeme erfordern ein robustes Paketmanagement und Bereitstellungssysteme, um rollende oder blaugrüne Bereitstellungen und Rollbacks zu verwalten. Ein Scheduler hilft zu bestimmen, welcher bestimmte Ausführungsknoten eine neue Reihe von Diensten basierend auf den aktuellen Bedingungen bereitgestellt werden kann. Spring Boot, Apache Maven. Das Spring Cloud -System hat keinen echten Scheduler. Docker, Rkt, Kubernetes Scheduler & Deployment, Helm[62]
Jobverwaltung: Geplante Berechnungen, die von einzelnen Benutzeranfragen getrennt sind. Frühlingsstapel Kubernetes -Jobs und geplante Jobs
Singleton -Anwendung: Begrenzen Sie einen bestimmten Dienst so, dass er als einzige Instanz dieses Dienstes innerhalb des gesamten Systems ausgeführt wird. Frühlingswolkencluster Kubernetes Pods

Siehe auch

Verweise

  1. ^ "Microservice -Architekturen: Mehr als die Summe ihrer Teile?". Ionos digitalguide. Abgerufen 2022-03-29.
  2. ^ a b c d Martin Fowler. "Microservices". Archiviert Aus dem Original am 14. Februar 2018.
  3. ^ Newman, Sam (2015-02-20). Microservices bauen. O'Reilly Media. ISBN 978-1491950357.
  4. ^ Wolff, Eberhard (2016-10-12). Microservices: Flexible Softwarearchitekturen. ISBN 978-0134602417.
  5. ^ a b c Pautasso, Cesare (2017). "Microservices in der Praxis, Teil 1: Reality Check and Service Design". IEEE -Software. 34 (1): 91–98. doi:10.1109/ms.2017.24. S2CID 5635705.
  6. ^ a b c d Chen, Lianping (2018). Microservices: Architektur für kontinuierliche Lieferung und DevOps. Die IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  7. ^ a b I. Nadareishvili, R. Mitra, M. McLarty, M. Amundsen, Microservice -Architektur: Ausrichtung von Prinzipien, Praktiken und Kultur, O'Reilly 2016
  8. ^ "Backends für Frontends -Muster". Microsoft Azure Cloud Design Musters. Microsoft.
  9. ^ Lucas Krause. Microservices: Muster und Anwendungen. WIE IN B00vj3np4a.
  10. ^ Entwerfen von Mikrodiensten: kontinuierliche Integration Microsoft Abgerufen am 9. Januar 2018 abgerufen
  11. ^ Josuttis, N. (2007). SOA in der Praxis. Sebastopol, CA, USA: O'Reilly. ISBN978-0-596-52955-0.
  12. ^ Martin Fowler. "Microservice -Voraussetzungen".
  13. ^ Richardson, Chris (November 2018). "1.4.1 Scale Cube und Microservices". Microservice -Muster. Manning Publikationen. ISBN 9781617294549.
  14. ^ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (2019-10-16). "Entwicklung selbstadaptiver Microservice-Systeme: Herausforderungen und Richtungen". IEEE -Software. 38 (2): 70–79. Arxiv:1910.07660. doi:10.1109/ms.2019.2955937. S2CID 204744007.
  15. ^ "Diese Tech -Show: Der Großvater von Microservices, Fred George".
  16. ^ Rodgers, Peter. "Service-orientierte Entwicklung von Netkernel-Mustern, Prozessen und Produkten zur Reduzierung der Systemkomplexität Web Services Edge 2005 East: CS-3". CloudComputingExpo 2005. Sys-con tv. Archiviert von das Original am 20. Mai 2018. Abgerufen 3. Juli 2017.
  17. ^ Rodgers, Peter. "Service-orientierte Entwicklung von Netkernel-Mustern, Prozessen und Produkten zur Reduzierung der Systemkomplexität". CloudComputingExpo. Sys-Con Media. Archiviert von das Original am 20. Mai 2018. Abgerufen 19. August 2015.
  18. ^ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "Architektur und Design einer XML -Anwendungsplattform". HP Technische Berichte. p. 62. Abgerufen 20. August 2015.
  19. ^ Löwy, Juval (2007). Programmierung WCF Services, 1. Aufl.. O’Reilly Media. S. 543–553. ISBN 978-0-596-52699-3.
  20. ^ Juval Löwy "Jeder WCF -Dienst der Klasse A". (Channel9, Arcast.TV, Oktober 2007).
  21. ^ Juval Löwy "Jede Klasse als Service"(Microsoft Teched Conference, Mai 2009), SOA206. Archiviert aus dem Original zu 2010.
  22. ^ Löwy, Juval (2007). Programmierung WCF Services, 1. Aufl.. O’Reilly Media. S. 48–51. ISBN 978-0-596-52699-3.
  23. ^ Löwy, Juval (2010). Programmierung WCF Services, 3. Aufl.. O’Reilly Media. S. 74–75. ISBN 978-0-596-80548-7.
  24. ^ Dragoni, Nicola; Giallorenzo, Saverio; Lafuente, Alberto Lluch; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2017). "Microservices: Gestern, heute und morgen". Gegenwart und Gebührsoftwaretechnik: 195–216. Arxiv:1606.04036. doi:10.1007/978-3-319-67425-4_12. ISBN 978-3-319-67424-7. S2CID 14612986.
  25. ^ James Lewis. "Micro Services - Java, The Unix Way".
  26. ^ Fred George (2013-03-20). "Microservice Architecture: Eine persönliche Entdeckungsreise".
  27. ^ Farrow, Rik (2012). "Netflix geht in die Wolken" (PDF).
  28. ^ James Lewis und Martin Fowler. "Microservices".
  29. ^ "Kontinuierliche Bereitstellung: Strategien". javacodegeeks.com. 10. Dezember 2014. Abgerufen 28. Dezember 2016.
  30. ^ Forschung, verifizierter Markt. "Cloud Microservices Market 2020 Trends, Marktanteil, Branchengröße, Chancen, Analyse und Prognose bis 2026 - Sofortiger Tech -Marktnachrichten". Abgerufen 2020-02-18.
  31. ^ O. Zimmermann, domänenspezifische Service-Dekoration mit Microservice-API-Mustern, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/tzimmerman.pdf
  32. ^ "Amazon SOA Mandat". 13. Oktober 2011.
  33. ^ Vaughn, Vernon (2016). Domänengetriebenes Design destilliert. Addison-Wesley Professional. ISBN 978-0-13-443442-1.
  34. ^ Yousif, Mazin (2016). "Microservices". IEEE Cloud Computing. 3 (5): 4–5. doi:10.1109/mcc.2016.101.
  35. ^ Dragoni, Nicola; Lanese, Ivan; Larsen, Stephan Thordal; Mazzara, Manuel; Mustafin, Ruslan; Safina, Larisa (2017). "Microservices: So machen Sie Ihre Anwendungsskala" (PDF). Internationale Andrei Ershov Memorial Conference über Perspektiven der Systeminformatik. Vorlesungsnotizen in Informatik. 10742: 95–104. Arxiv:1702.07149. Bibcode:2017ArXIV170207149d. doi:10.1007/978-3-319-74313-4_8. ISBN 978-3-319-74312-7. S2CID 1643730.
  36. ^ Newman, Sam (2015). Microservices bauen. O'Reilly. ISBN 978-1491950357.
  37. ^ Wolff, Eberhard (2016). Microservices: Flexible Softwarearchitektur. Addison Wesley. ISBN 978-0134602417.
  38. ^ Knoche, Holger; Hasselbring, Wilhelm (2019). "Treiber und Hindernisse für die Einführung von Microservice - Eine Umfrage unter Fachleuten in Deutschland". Architekturen für Unternehmensmodellierung und Informationssysteme. 14: 1: 1–35–1: 1–35. doi:10.18417/emisa.14.1.
  39. ^ a b Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). "Microservices in der agilen Softwareentwicklung: Eine Workshop-basierte Studie zu Themen, Vorteilen und Nachteilen". Verfahren der XP2017 Scientific Workshops. doi:10.1145/3120459.3120483. S2CID 28134110.
  40. ^ Richardson, Chris. "Microservice -Architekturmuster". microservices.io. Abgerufen 2017-03-19.
  41. ^ Chen, Lianping; Ali Babar, Muhammad (2014). "Auf dem Weg zu einem evidenzbasierten Verständnis der Entstehung der Architektur durch kontinuierliches Refactoring in der agilen Softwareentwicklung". Proceedings Working Working IEEE/IFIP -Konferenz zur Softwarearchitektur 2014 WICSA 2014. Die 11. Arbeits-/IFIP -Konferenz über Softwarearchitektur (WICSA 2014). IEEE. doi:10.1109/WICSA.2014.45.
  42. ^ Balalaie, Armin; Heydarnoori, Abbas; Jamshidi, Pooyan (Mai 2016). "Microservices Architecture ermöglicht DevOps: Migration zu einer Cloud-nativen Architektur" (PDF). IEEE -Software. 33 (3): 42–52. doi:10.1109/ms.2016.64. HDL:10044/1/40557. ISSN 0740-7459. S2CID 18802650.
  43. ^ Stenberg, Januar (11. August 2014). "Erfahrungen aus dem Versagen mit Microservices".
  44. ^ Calandra, Mariano (7. April 2021). "Warum Unit -Tests nicht ausreichen, wenn es um Microservices geht".
  45. ^ a b "Entwicklung von Microservices für PaaS mit Frühlings- und Cloud -Gießerei".
  46. ^ Tilkov, Stefan (17. November 2014). "Wie klein sollte Ihr Microservice sein?". Innoq. Abgerufen 4. Januar 2017.
  47. ^ Lanza, Michele; Ducasse, Stéphane (2002). "Verständnis der Softwareentwicklung mithilfe einer Kombination aus Softwarevisualisierung und Software -Metriken" (PDF). In Proceedings of LMO 2002 (Langages et Modèles à Objets): 135–149.
  48. ^ Richardson, Chris (November 2018). Microservice -Muster. Kapitel 4. Verwaltung von Transaktionen mit SAGAS: Manning Publications. ISBN 978-1-61729454-9.{{}}: CS1 Wartung: Standort (Link)
  49. ^ "- Youtube". Youtube.
  50. ^ a b c Löwy, Juval (2019). Richtige Software 1. ED. Addison-Wesley Professional. S. 73–75. ISBN 978-0136524038.
  51. ^ Pautasso, Cesare (2017). "Microservices in der Praxis, Teil 2: Service -Integration und Nachhaltigkeit". IEEE -Software. 34 (2): 97–104. doi:10.1109/ms.2017.56. S2CID 30256045.
  52. ^ Pautasso, Cesare (2018). "Konsistente Katastrophenwiederherstellung für Microservices: The BAC -Theorem". IEEE Cloud Computing. 5 (1): 49–59. doi:10.1109/mcc.2018.011791714. S2CID 4560021.
  53. ^ Fowler, Martin. "Microservice-Kompromisse".
  54. ^ "Brass Building Resource Adaptive Softwaresysteme". US Regierung. DARPA. 7. April 2015. "Der Zugriff auf Systemkomponenten und die Schnittstellen zwischen Clients und ihren Anwendungen werden jedoch über eine Reihe von häufig nicht verwandten Mechanismen vermittelt, einschließlich informell dokumentiert Anwendungsprogrammierschnittstellen (APIS), eigenwillige Fremdfunktion Schnittstellen, komplexe schlecht verstärkte Modelldefinitionen oder ad hoc Datenformate. Diese Mechanismen bieten normalerweise nur ein teilweise und unvollständiges Verständnis der Semantik der Komponenten selbst. In Gegenwart einer solchen Komplexität ist es nicht überraschend, dass Anwendungen in der Regel viele Annahmen über das erwartete Verhalten des Ökosystems einbauen, mit dem sie interagieren. "
  55. ^ Wolff, Eberhard (2018-04-15). Microservices - ein praktischer Leitfaden. ISBN 978-1717075901.
  56. ^ Swart, Stephanie (14. Dezember 2016). "Eclipse -Mikroprofile". Projects.eclipse.org.
  57. ^ "Mikroprofil" ". Mikroprofile. Abgerufen 2021-04-11.{{}}: CS1 Wartung: URL-Status (Link)
  58. ^ Netflix OSS, Git Hub
  59. ^ Wolke, Frühling
  60. ^ "Springwolke für Microservices im Vergleich zu Kubernetes", Entwickler, Red Hat, 2016-12-09
  61. ^ Verwalten von Microservices mit dem ISTIO Service Mesh, Kubernetes, Mai 2017
  62. ^ Der Kubernetes -Paketmanager, Helm

Weitere Lektüre