🈚️ 👫 ♑️ Zusammenfassung des Buches "Erstellen von Microservices" 🏅 📍 👩🏾‍💼

Ich verstehe nichts über Microservice-Architektur und habe mich daher entschlossen, Sam Newmans Buch "Creating Microservices" zu lesen und zu skizzieren. Meiner Meinung nach war es eine gute Einführung für Leute, die anfangen, sich mit diesem Thema zu beschäftigen.

Microservices

Die Idee der Microservice-Architektur basiert auf mehreren Konzepten: themenorientiertes Design, kontinuierliche Bereitstellung, On-Demand-Virtualisierung, Infrastrukturautomatisierung, kleine eigenständige Teams und skalierbare Systeme. Microservice ist ein kleiner (in zwei Wochen vollständig umgeschriebener) autonomer Dienst, der nur eine Aufgabe ausführt. Gleichzeitig werden die Grenzen von Microservices auf der Grundlage von Geschäftsgrenzen gebildet.

Vorteile des Ansatzes:

technologische Heterogenität ist möglich;
eleganter Abbau ist leicht zu erreichen;
einzelne Teile des Systems skalieren unabhängig voneinander;
unabhängige Bereitstellung von Diensten;
einfache Aufteilung der Verantwortlichkeiten zwischen den Teams.

Es scheint möglich zu sein, die Microservice-Architektur zu ersetzen, indem der Code einfach in Bibliotheken abgelegt wird. Dies löst jedoch nur einen Teil der Probleme - technische Heterogenität, einfache Skalierung und unabhängige Bereitstellung sind nicht möglich. Außerdem bleibt das Problem der unkontrollierten Konnektivität bestehen.

In einigen Sprachen (z. B. Erlang) können einzelne Teile des Programms (Module) unabhängig voneinander skaliert und bereitgestellt werden. Dies ist jedoch eher eine Ausnahme von der Regel.

Microservices sind keine Wunderwaffe. Sie unterliegen allen Problemen verteilter Systeme. Es ist wichtig zu lernen, wie ein solches System qualitativ bereitgestellt, getestet und überwacht wird. Die Microservice-Architektur ist nicht für alle Unternehmen geeignet.

Entwicklungsarchitekt

Bei der Entwicklung eines Systems, das aus vielen Diensten besteht, nimmt die Rolle des Architekten zu.

. . , , . — . , , , .

— , , .

;
;
.

( ) .

— , . , , .

. , . .

( DDD) — .

, , . . , , — .

« », -.

. : , , - . , -.

- ;
();
.

-, , — . , . — . , — .

, «» , , . , - . . , .

, . . «-», .

— . . , ( ). ( ).

, — RPC REST. RPC — , , . REST — , ( REST-).

. - ( ATOM) . , , .

. : , — . -, .

— ( 1.5.3 2.0.0) . URI (, /v1/createUser/, /v2/createUser/), , HTTP, .

( 1.5.3 2.0.0), — , . , .

, . .

— . , , .

— API-, . , ( ).

— backend-for-frontend (BFF). (, ) API- .

, API-.

(, CMS CRM). . — , API.

. , , .

. — . , , . : ; .

, . — . . , (, , ).

. . :

;
;
, ;
( Netflix).

. , (, ) . (-).

( , , ). . . .

, . , Chef, Puppet Ansible. — , . — , deb-. . , . — .

LXC- — . . Docker — , , Kubernetes.

- , , . , , -. E2e , .

- - — (), (). . — Mountebank.

(e2e) . CI, , . CDC ( ).

- . ( ).

. .

-, .

- : — . . -.

( - ) — . (, , - -). , . , . , .

-, , . , .

-, . , (, logstash) (, Kibana) .

( , ) -. , - .

: - .

. , .

. — , , . — , . . , .

, :

. , - - . , — , .
HTTP(S) Basic Auth. -, HTTPS, SSL-. -, ( Basic Auth).
. , — , , .
. , .
- (HMAC). , , . ( JWT) . — , .
API-. , , API-. , , .

. , .

. , IP- . .

. , .

«, , , »

, , , .

— , , - . , .

: , , . . , , .

— (graceful degradation).

— . , - .

— . , , , . , , - .

— , . , , ( ), . . «», , .

, .

— . . .

— . . - , .

— , (), . . .

. , .

, -, :

, , ;
- , , , , ;
, , , .

, , .

HTTP . cache-control expires ETag . HTTP, , .

. , . , , - . , .

— . ( , , ) . , .

CAP

: , . .

Am einfachsten ist es, DNS zu verwenden. Wenn seine Fähigkeiten nicht ausreichen, können Sie Dinge wie Zookeeper, Consul oder Eureka verwenden.

Dokumentation

API-Services müssen dokumentiert werden. Es ist sehr wünschenswert, dass der Code und die Dokumentation miteinander verbunden sind und dass es unmöglich ist, eine Sache zu ändern. Zum Beispiel können Sie Swagger oder HAL nehmen.