Náš hlavní produkt — informační systém pro středně velké firmy — je klasický monolit. Jeden WAR, jeden GlassFish, jedna Oracle databáze. Funguje, klienti jsou spokojení. Tak proč do toho šaháme? Protože každý nový feature trvá déle, deployment jedné změny vyžaduje nasazení celé aplikace a tým se rozrostl. Microservices vypadají jako cesta ven.
Proč ne „přepišme to cel锶
Prvním impulzem bylo zahodit monolit. Naštěstí nás kolega odkázal na článek Martina Fowlera o Strangler Pattern — postupné nahrazování částí monolitu novými službami. Evoluce, ne revoluce.
Definovali jsme bounded contexty (DDD terminologie): fakturace, uživatelský management, notifikace, reporting. Začali jsme s notifikacemi — nejmenší riziko, jasný scope.
Notifikační služba — náš první microservice¶
Nový notification service: standalone Spring Boot aplikace (ano, opustili jsme Java EE pro microservices). REST API, šablony v databázi, asynchronní doručení přes frontu. Stack: Spring Boot 1.2, embedded Tomcat, PostgreSQL, RabbitMQ. Celá služba ~3000 řádků kódu, deployuje se nezávisle.
REST API — kontrakt je zákon¶
API definujeme ve Swagger. Specifikace v gitu, změny prochází review. Klientský kód generujeme ze Swaggeru. Verzování: /api/v1/notifications. Pro synchronní operace REST, pro asynchronní eventy RabbitMQ.
Deployment — Docker v produkci (skoro)¶
Docker 1.5 je stabilnější. Docker Compose pro lokální vývoj. Orchestrace? Zatím nemáme. O Kubernetes jsem slyšel z Google — vypadá zajímavě, ale pro 3 služby je to kanón na vrabce. Jeden server = jedna služba, nginx load balancer. Primitivní, ale funkční.
Co jsme podcenili¶
Distribuované logování. S pěti službami potřebujete centrální logging. ELK stack + correlation ID — zabralo dva sprinty.
Síťové selhání. HTTP call přes síť není spolehlivý. Circuit breaker (Hystrix od Netflixu) je nutnost. První produkční incident byl timeout cascading přes celý systém.
Testování. Unit testy jednoduché. Integrační testy přes služby jsou noční můra. Contract testing (Pact) pomáhá, ale end-to-end testy přes 4 služby jsou křehké.
Stojí to za to?¶
Po roce: 4 microservices a zmenšený monolit. Deployment notification service trvá 2 minuty. Nové features dodáváme 3× rychleji. Ale overhead je reálný — víc infrastruktury, monitoring, komplexity. Pro tým pod 5 vývojářů bych microservices nedoporučoval.
Evoluce, ne revoluce¶
Microservices nejsou silver bullet. Vyměníte komplexitu uvnitř aplikace za komplexitu mezi aplikacemi. Ale pokud monolit brzdí, postupná dekompozice má smysl. Začněte malým, okrajovým service.