2. Microservices

Todo

Przepisanie microservices jako osobny katalog z podziałem na tematy

Todo

Przepisanie microservices jako osobne szkolenie

Todo

Reactive manifesto, reactive programming

Todo

spock framework

Todo

Blockchain uruchamianie kodu

Todo

Function as a Service

Todo

Database sharding

Todo

Przykład edok w cloud i bazy po stronie klienta

2.1. Spojrzenie na Mikroserwisy z perspektywy biznesu

  • szybkie wypuszczanie MVP nowych produktów
  • ROI wdrożenia
  • spójność systemów

2.2. Cechy rozproszonych systemów

  • Niezależne domeny awarii
  • Możliwość pisania w wielu językach
  • Równoległość komponentów (concurrency)
  • Brak globalnego zegara i możliwości jednoznacznego określenia czasu i kolejności

2.3. 8 błędnych założeń

The Eight Fallacies of Distributed Computing – Peter Deutsch, 1991
  • sieć jest niezawodna:

    • sieć w serwerowni jest niezawodna
    • MTBF routera jest 50k h
    • netsplit w publicznych cloudach są normalne
    • zwiększa się latency
  • opóźnienia w sieci są zerowe

  • przepustowość sieci jest nieskończona

  • sieć jest bezpieczna:

    • większość aplikacji jest chroniona z zewnątrz
    • brak szyfrowania wewnątrz sieci
  • Topologia sieci się nie zmienia:

    • przeliczenie BGP i zmiana spanning tree
    • ścieżki sieciowe się zmieniają
    • pojawiają się nowe instancje
  • Istnieje tylko jeden administrator:

    • różni ludzie z różną wiedzą
    • inaczej konfigurują maszyny
    • jeden serwer może być lepiej skonfigurowany
  • Koszt transportu jest zerowy

    • narzut czasowy na serializację, deserializację, stos TCP
    • czas transportu po medium jest niezerowy
  • Sieć jest jednorodna

    • sieć składa się z różnych urządzeń
    • mogą być różnie stabilne
    • mogą mieć różne charakterystyki

2.4. Poświęcenie

  • zapewnienie spójności kosztem dostępności

  • zapewnienie wysokiej dostępności kosztem spójności

  • wzajemnie się wykluczające

  • nie ma ACID!:

    • Atomicity
    • Consistency
    • Isolation
    • Durability

Todo

dwufazowe kommity

2.5. BASE

  • Basically:

    • Available (w większości możemy wykonać pewne operacje)
    • Soft State (tylko operacje, których stan możemy odbudować, np. przez przegenerowanie cache)
    • Eventually consistent (system jest pomiędzy stanem spójnym i niespójnym)

2.6. Cechy systemów

  • Brak transakcyjności
  • Zastosować mechanizm rekompensacji (np. raz w nocy usuwać zduplikowane dane)
  • Brak gwarancji, że komunikat wysłany do hosta zostanie wysłany tylko raz (np. jeżeli dwa razy zostanie wysłany komunikat przez bankomat o naliczeniu opłaty, to operacja zostanie wykonana przez bank tylko raz)

2.7. Choreografia > Orkiestracja

  • Choreografia:

    • informujemy system o zdarzeniu
    • system subskrybuje się do eventów
    • system reaguje na zmiany stanów
  • Orkiestracja:

    • usługa jest odpowiedzialna za informację o zmianie stanu

2.7.1. Hermes

  • https://github.com/allegro/hermes
  • usługa subskrybuje się do danego topicu
  • gdy zajdzie zdarzenie
  • system wypycha je do subskrybentów
  • nakładka na Apache Kafka
  • zarządza dostarczaniem wiadomości only once policy
  • throttling
  • load ballancing
  • security policy dla wiadomości
../_images/microservices-hermes.png

Fig. 2.1. Architektura systemu Hermes

  • można zapchać sieć, gdy ma się zcentralizowaną infrastrukturę
  • wykorzystanie HTTP/2.0 (multipleksowanie połączeń http, kompresja nagłówków, TLS)

Note

Jeżeli jedna usługa pada i to pociąga za sobą cały system, to nie jest to architekura Microservices.

2.8. Przepisywanie architektury

../_images/microservices-sidecar.png

Fig. 2.2. Architektura systemu zgodna z Sidecar

  • Anti Corruption Layer (ACL)

  • Tworzenie nowych funckonalności na nowej platformie

  • zapewnienie spójności systemów

  • kontrola czy dane w nowym systemie są spójne z nowym

  • przepisywanie całości

  • wdrożenie ludzi:

    • zatrudnianie w nowej technologii
    • konwersja obecnych pracowników
../_images/microservices-anti-corruption-layer.png

Fig. 2.3. Anti Corruption Layer

2.8.1. Tworzenie nowej usługi

  • end to end:

    • założenie repo w Bitbucket
    • projekt w JIRA
    • CI/CD
    • Deployment
    • Repozytorium artefaktów
    • Publikowanie metryk
    • Testy security
    • Monitoring i logowanie
  • one-click-project

  • automatyzacja powtarzających się czynności za pomocą pluginów (gradle i axion)

2.9. Platforma uruchamiania

  • Usługi uruchamiane w różnych datacenter jednocześnie
  • Wykorzystanie public i private cloud jednocześnie

2.9.1. Mesos

  • Tworznie logicznego klastra, który przykrywa infrastrukturę
  • Możliwość dzielenia klastra na biznesowe komponenty i przydzielenia im zasobów
  • Możliwość definiowania wykorzystywanych zasobów przez usługę
  • Dynamiczne alokowanie zasobów
../_images/microservices-platform-path.png

Fig. 2.4. Ścieżka rozwoju platform uruchomieniowych w architekturze mikrousługowej

2.10. Monitoring

  • automatyczne zapinanie metryk do usług
  • raportowanie poziomu SLA
  • alerting
  • definiowanie progów alertownia
  • wykrywanie anomalii (na podstawie dotychczasowej historii, machine learning)

2.11. Poziom organizacyjny

  • powiązania pomiędzy usługami
  • przepływy danych

2.11.1. Domain Driven Design

  • Poziom Strategiczny i Taktyczny

  • Wzorce Strategiczne: Domain Distillation, Bounded Context

  • nauka Product Ownerów

  • DDD na poziomie strategicznym

  • definicja corowych usług

  • ułożenie biznesu i IT

  • podział na domeny:

    • Lead PO dla domeny
    • Solutions Archtect pomiędzy domenami
  • DDD na poziomie taktycznym do decyzji zespółu

2.11.2. Polyglog Programming i Polyglog Persistance

  • overhead związany z wielością usług

  • nowe technologie

  • różne działające równoległe wersje np. baz danych

  • Deprecation policy

    • Przykład Webapi
    • Przykład Visual Fox Pro -> Java
    • Przykład Twitter API

2.11.3. Ludzie

  • poziom wiedzy jest nierówny

  • różna wiedza na temat spójności systemów

  • różne doświadczenie

  • zmiana zespołów

  • próg wejścia

  • wdrożenie ludzi:

    • zatrudnianie w nowej technologii
    • konwersja obecnych pracowników
    • zmiana przyzwyczajeń
    • zmiana języka programowania i technologii
  • Ludzie muszą testować

  • Wymiana wiedzy pomiędzy ludźmi (eurowizja)

  • Hackatony wdrożeniowe

2.11.4. Handoff

  • ze względu na bardzo rozproszone środowisko ludzie uruchamiają swoje usługi sami
  • duża i rozproszona wiedza na temat działania systemu
  • utrzymywanie przez zespół
  • przekazywania usług
  • zmiany HRowe
  • dyżury w każdym zespole

2.12. Wiązanie usług (coupling)

  • zaprzecza systemowi wysyłania eventów
  • ze względu na rozwój domen w różnym tempie pojawia się pokusa, aby obejść usługę i samemu zaimplementować funkcjonalność

2.13. Audyt i Compliance

  • problemy z monitotowaniem

  • problemy z rozproszoną wiedzą

  • sprawdzanie czy wszystko się liczy poprawnie

  • wyciąganie raportów i danych audytowych:

    • monolit - jedno zapytanie do bazy dancyh i joiny
    • microservices - dane są rozproszone (różne systemy, bazy danych, technologie)
  • tworzenie audit logów

  • przygotowanie systemu od początku pod audyty

2.14. Microdata

  • eksport danych do Hadoopa

  • normalizacja danych z różnych technologii i baz danych

  • brak informacji na świecie jak to robić

  • inny sposób dostępu do danych dla analityki (dostęp do miliardów rekordów po HTTP i API nie jest optymalny)

    • Replikacja baz danych
    • BSON
    • Protocol Buffers (Protobuf)
    • Trhift

2.15. SLA usług

  • Definiowanie SLA

  • Koszt inwestycji w zwiększenie dostępności np. z 4 na 5 dziewiątek)

  • ROI z wprowadzenia poszczególnych usług

    • zmienjszone latency
    • większa stabilność
    • większa redundantność
  • Każdy system może mieć inną charakterystykę i inne cechy

2.17. Architecture

  • Duży próg wejścia:

    • Wymaga bardzo dobrego ekosystemu narzędziowego
    • Wymaga automatyzacji
    • Wymaga stworzenia i wdrożenia wielu różnych technologii
    • Tworzenie technologii, które skalują się horyzontalnie
    • Zmiana myślenia
    • Wdrożenie ludzi
  • Dla większości firm nie przynosi to korzyści (sic!)

  • SOA zrobiona porządnie (wywalone tematy związane z Enterprise)

2.17.1. Monolithic architecture

Build an application with a monolithic architecture. For example:

  • a single Java WAR file.
  • a single directory hierarchy of Rails or NodeJS code
../_images/microservices-monolithic-application.jpg

Fig. 2.5. Monolithic architecture

2.17.2. Microservices architecture

  • Architect the application by applying the Scale Cube (specifically y-axis scaling) and functionally decompose the application into a set of collaborating services. Each service implements a set of narrowly, related functions. For example, an application might consist of services such as the order management service, the customer management service etc.
  • Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP.
  • Services are developed and deployed independently of one another.
  • Each service has its own database in order to be decoupled from other services. When necessary, consistency is between databases is maintained using either database replication mechanisms or application-level events.
../_images/microservices-architecture.jpg

Fig. 2.6. Microservices Architecture

2.18. API

2.18.1. Cechy API

  • Werisonowane
  • Stabilne
  • Deprecation policy
  • HTTP
  • REST
  • JSON

Todo

przykład stabilności webapi i mobilnych stron

Todo

wersjonowanie w nagłówkach HTTP i q=…

Todo

POST, PUT, PATCH, GET, DELETE

2.18.2. API gateway

  • Implement an API gateway that is the single entry point for all clients. The API gateway handles requests in one of two ways. Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services.
  • Rather than provide a one-size-fits-all style API, the API gateway can expose a different API for each client. For example, the Netflix API gateway runs client-specific adapter code that provides each client with an API that’s best suited to it’s requirements.
  • The API gateway might also implement security, e.g. verify that the client is authorized to perform the request
  • Netflix API gateway, Zuur
../_images/microservices-api-gateway.jpg

Fig. 2.7. Microservices API gateway

2.19. Service discovery

2.19.1. Client-side discovery

  • When making a request to a service, the client obtains the location of a service instance by querying a Service Registry, which knows the locations of all service instances.
  • Eureka is a Service Registry
  • Ribbon Client is an HTTP client that queries Eureka to route HTTP requests to an available service instance
../_images/microservices-client-side-discovery.jpg

Fig. 2.8. Microservices client side discovery

2.19.2. Server-side discovery

  • When making a request to a service, the client makes a request via a router (a.k.a load balancer) that runs at a well known location. The router queries a service registry, which might be built into the router, and forwards the request to an available service instance.
  • AWS Elastic Load Balancer (ELB), Kubernetes, Marathon
../_images/microservices-server-side-discovery.jpg

Fig. 2.9. Server side-discovery

2.20. Service registry

  • Implement a service registry, which is a database of services, their instances and their locations. Service instances are registered with the service registry on startup and deregistered on shutdown. Client of the service and/or routers query the service registry to find the available instances of a service.
  • Eureka, Apache Zookeeper, Consul, Etcd

2.21. Self registration

  • A service instance is responsible for registering itself with the service registry. On startup the service instance registers itself (host and IP address) with the service registry and makes itself available for discovery. The client must typically periodically renew it’s registration so that the registry knows it is still alive. On shutdown, the service instance unregisters itself from the service registry.
  • Apache Zookeeper, Netflix Eureka

2.22. 3rd party registration

  • A 3rd party registrar is responsible for registering and unregistering a service instance with the service registry. When the service instance starts up, the registrar registers the service instance with the service registry. When the service instance shuts downs, the registrar unregisters the service instance from the service registry.
  • Netflix Prana - a “side car” application that runs along side a non-JVM application and registers the application with Eureka.
  • AWS Autoscaling Groups automatically (un)registers EC2 instances with Elastic Load Balancer
  • Joyent’s Container buddy runs in a Docker container as the parent process for the service and registers it with the registry
  • Registrator - registers and unregisters Docker containers with various service registries
  • Clustering frameworks such as Kubernetes and Marathon (un)register service instances with the built-in/implicit registry

2.23. Instancje

2.23.1. Multiple service instances per host

  • Run multiple instances of different services on a host (Physical or Virtual machine).
  • There are various ways of deploying a service instance on a shared host including:
  • Deploy each service instance as a JVM process. For example, a Tomcat or Jetty instances per service instance.
  • Deploy multiple service instances in the same JVM. For example, as web applications or OSGI bundles.

2.23.2. Single service instance per host

  • Deploy each single service instance on it’s own host

2.23.3. Service instance per VM

  • Package the service as a virtual machine image and deploy each service instance as a separate VM

2.23.4. Service instance per Container

  • Package the service as a (Docker) container image and deploy each service instance as a container
  • Kubernetes, Marathon/Mesos, Amazon EC2 Container Service

2.24. Serverless deployment

  • Use a deployment infrastructure that hides any concept of servers (i.e. reserved or preallocated resources)- physical or virtual hosts, or containers. The infrastructure takes your service’s code and runs it. You are charged for each request based on the resources consumed.
  • To deploy your service using this approach, you package the code (e.g. as a ZIP file), upload it to the deployment infrastructure and describe the desired performance characteristics.
  • The deployment infrastructure is a utility operated by a public cloud provider. It typically uses either containers or virtual machines to isolate the services. However, these details are hidden from you. Neither you nor anyone else in your organization is responsible for managing any low-level infrastructure such as operating systems, virtual machines, etc.
  • AWS Lambda, Google Cloud Functions, Azure Functions

2.25. Baza danych

2.25.1. Database per Service

  • Keep each microservice’s persistent data private to that service and accessible only via its API.
../_images/microservices-database-per-service.png

Fig. 2.10. Database per Service

Todo

Wiele baz danych w jednej usłudze

Todo

Mieszane, usługi mają jedną bazę danych

2.25.2. Shared database

  • Use a (single) database that is shared by multiple services. Each service freely accesses data owned by other services using local ACID transactions.
../_images/microservices-database-shared.png

Fig. 2.11. Shared database

2.25.3. Database triggers

  • Reliably publish events whenever state changes by using database triggers. Each trigger inserts an event into an EVENTS table, which is polled by a separate process that publishes the events.
  • Czy są ok?
  • Czym się różni struct od Class

2.26. Microservice chassis

  • Build your microservices using a microservice chassis framework, which handles cross-cutting concerns
  • Spring Boot, Spring Cloud, Dropwizard

2.27. Zdarzenia

2.27.1. Event-driven architecture

  • Use an event-driven, eventually consistent approach. Each service publishes an event whenever it update it’s data. Other service subscribe to events. When an event is received, a service updates it’s data.

2.27.2. Event sourcing

  • Reliably publish events whenever state changes by using Event Sourcing. Event Sourcing persists each business entity as a sequence of events, which are replayed to reconstruct the current state.
../_images/microservices-event-sourcing.png

Fig. 2.12. Event sourcing

2.27.3. Application events

  • Reliably publish events whenever state changes by having the application insert events into an EVENTS table as part of the local transaction. A separate process polls the EVENTS table and publishes the events to a message broker.

2.28. CQRS - Command Query Responsibility Segregation

  • Split the system into two parts. The command side handles create, update and delete requests. The query side handles queries using one or more materialized views of the application’s data.

2.29. Transaction log tailing

  • Reliably publish events whenever state changes by tailing the transaction log.