====== Architektura mikroslužeb ======

**Architektura mikroslužeb** rozděluje komplexní aplikaci na řadu modulárních služeb. Každá služba se zaměřuje na jednu konkrétní obchodní funkci (např. platba, katalog produktů, správa uživatelů) a může být vyvíjena, nasazována a škálována nezávisle na ostatních.

===== 1. Monolit vs. Mikroslužby =====



==== Monolitická architektura ====
Všechny funkce aplikace (UI, databáze, logika) jsou propojeny do jednoho celku.
  * **Výhody:** Jednodušší vývoj na začátku, snadné testování a nasazení.
  * **Nevýhody:** S růstem aplikace se kód stává nepřehledným ("Big Ball of Mud"), jakákoliv malá změna vyžaduje znovunasazení celé aplikace, omezená škálovatelnost.

==== Architektura mikroslužeb ====
Aplikace je tvořena autonomními službami.
  * **Výhody:** Možnost použít různé technologie pro různé služby, nezávislé nasazování (CI/CD), lepší odolnost (pád jedné služby nemusí shodit celou aplikaci).
  * **Nevýhody:** Vysoká náročnost na orchestraci, složitější monitoring a konzistence dat.

---

===== 2. Klíčové principy a komponenty =====

Aby systém mikroslužeb fungoval, vyžaduje specifickou infrastrukturu:

  * **API Gateway:** Jednotný vstupní bod pro klienty. Směruje požadavky na správné mikroslužby a řeší bezpečnost (autentizaci).
  * **Service Discovery:** Mechanismus, díky kterému služby vědí, na jakých IP adresách běží ostatní služby (např. Consul nebo Kubernetes).
  * **Databáze pro každou službu:** Každá mikroslužba by měla mít vlastní databázi, aby byla zajištěna volná vazba (Loose Coupling).
  * **Komunikace:**
    * **Synchronní:** Pomocí protokolu HTTP/REST nebo gRPC.
    * **Asynchronní:** Pomocí front zpráv nebo streamování dat (např. [[it:sw:apache_kafka|Apache Kafka]]).



---

===== 3. Technologie v ekosystému =====

^ Oblast ^ Nástroje ^
| **Kontejnerizace** | **Docker** (izolace služeb a jejich závislostí) |
| **Orchestrace** | **Kubernetes** (správa stovek kontejnerů v cloudu) |
| **Komunikace** | [[it:sw:rest_api|REST]], gRPC, [[it:sw:apache_kafka|Kafka]], RabbitMQ |
| **Monitoring** | Prometheus, Grafana, ELK Stack (Logstash, Elasticsearch, Kibana) |
| **Tracing** | Jaeger, Zipkin (sledování cesty požadavku napříč službami) |

---

===== 4. Výzvy a úskalí =====

Přechod na mikroslužby není "zadarmo" a přináší nové problémy:
  * **Distribuovaná data:** Je těžké udržet data konzistentní napříč více databázemi (často se řeší pomocí vzoru Saga).
  * **Network Latency:** Komunikace přes síť je pomalejší než volání funkcí v paměti monolitu.
  * **Složitost týmu:** Vyžaduje pokročilé dovednosti v oblasti **DevOps** a automatizace.

> **Pravidlo palce:** Pokud nemáte velmi komplexní systém a velký vývojový tým, začněte raději s "modulárním monolitem". Mikroslužby zavádějte až ve chvíli, kdy monolit přestane být řiditelný.

----
//Související články://
  * [[it:sw:dot_net_core|.NET Core v mikroslužbách]]
  * [[it:sw:apache_kafka|Apache Kafka: Asynchronní komunikace]]
  * [[it:sw:rest_api|REST API: Standard komunikace]]

//Tagy: {{tag>architecture microservices cloud-native devops docker kubernetes}}//