Skip to content

Instantly share code, notes, and snippets.

@0xd61

0xd61/Distributed Systems.md

Last active July 6, 2017 19:14
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save 0xd61/554a196b308af676004d720f764efac4 to your computer and use it in GitHub Desktop.
Save 0xd61/554a196b308af676004d720f764efac4 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Distributed Systems.md

Fehler oder Fehlendes bitte in den Kommentaren anmerken! :)

General Cloud

  • immer und überall verfügbar
  • unendlich skalierbar
  • keine Down-Time
  • kostet weniger - pay-per-use
  • keine maintain Kosten für physische Rechner
  • Kunden müssen keine Updates installieren (Updates können direkt deployed werden)
  • Einfach mit anderen Services verbinden (APIs)
  • Nachteil: Daten sind irgendwo auf einem Server
  • Nachteil: Manche Dinge können nicht selbst Kontrolliert werden (Kontrolle abgeben)

Definition

  • Auslieferung von Computing as a Service (kein Produkt). Es wird Rechenzeit, Software, Daten Zugriffe und Speicher zu Verfügung gestellt, ohne dass User den Ort der Infrastruktur kennen.
  • Daten sind auf Servern an einer remote-location gespeichert.
  • Provider möchten besseren Service und Performance geben, als lokal installierte Programme.
  • Ziel: Zusammenführung von Infrastruktur und Geteilte Services
  • Es wird besondere Software- architektur, technologie und tools benötigt, als die von lokaler Softwareentwicklung

Charakterisik

  • Scalable/Elastic
  • Available/Reliable
  • Performance Optimaization
  • Accessability/Portability
  • Manageable (automatation, monitoring, ...)

Challenges

  • Security & Privacy
  • Integration mit Legacy Software
  • Service Qualität und Downtime (sind die Daten sicher? Können Transaktionen genutzt werden?, wie hoch ist die latenz)
  • Probleme mit Rechlichen Auflagen (dürfen Daten im Ausland gespeichert werden?
  • Können der Angestellten

Buzzwords

  • Utility Computing - Computers as a Service (Pay what you Use)
  • Distributed Computing - Computer sind über Netzwerk miteinander verbunden und Kommunizieren über Nachrichten.
  • Grid computing - Computer and verschiedenen Standorten sind vernetzt um ein Gemeinsames Ziel zu erreichen. Jede Node kümmert sich um eine andere Aufgabe
  • Cluser Computing - Mehrere Computer arbeiten zusammen und können als ein System gesehen werden. Jede Node kann die gleiche Aufgabe bearbeiten, gescheduled durch Software

Cloud Service Models

  • IaaS - Infrastructure as a Service (Build a house) --> Virtualization, Storage, Computing, Network, I/O
  • PaaS - Platform as a Service (Buy a (empty) house --> Load Balancing, Dynamic Provisioning, Fault Tolerance, Resource Management
  • SaaS - Software as a Service (Rent a hotel room) --> Application + Serives

Hypervisors

  • Hardware

  • Type1/Type2 (+Host OS) (IaaS)

  • Virtual Hardware (IaaS)

  • Guest OS (IaaS)

  • Container Orchestration (CaaS)

  • Container (CaaS)

  • Services/Applications (PaaS)

  • Bare Metal - Maschinen müssen vorher gebaut und installiert werden

  • Hypervisor virtualisieren Hardware und stellen ein OS zu Verfügung (ISO Image)

  • Container nutzen das vorhandene OS (config und libs) und stellen eine Isolierte Umgebung bereit

ships within manual deployment takes automated deployment takes boots in
bare metal days hours minutes minutes
hypervisor minutes minutes seconds smaller than minutes
container seconds minutes seconds seconds

IaaS, PaaS, ...

  • Erstellung in wenigen Schritten
  • Datenbanken, Messaging, AI, IoT,... gehört zu PaaS
  • Container und Container Orchestration --> PaaS (wichtig für autoscaling)

Buildpacks/Container

  • Buildpacks liefern Framework und Laufzeitunterstützung für die App (wie Docker Images)
  • Buildpacks --> Bring your own code (Dev und Ops können einen statischen Set von Abhängigkeiten zustimmen)
  • Containers --> Bring your own container (können von Dev lokal getestet werden) Ops müssen nur Interfaces zu anderen Services konfigurieren
  • beide nach dem prinzip, you built it, you run in

PaaS Provider

Cloud Foundry

  • Cloud Foundry - open Source cloud framework
  • Pivotal Cloud Foundry - commercialized with install and administration
  • Diego - Container Scheduler - erstellt mit runC Linux Container
  • runC - container runtime reference (initialisiert und startet container prozess z.B. Docker)
  • Uses Docker containers und Buildpacks
  • kann lokal installiert werden
  • BOSH connect mit darunterliegenden IaaS (Support für AWS EC2, Apacke CloudStack, Google Compute Engine, OpenStack, VMware vSphere

Cloud Foundry in detail

"Here is my source code, run it on the cloud for me, I dont care how"

  • released 2011
  • Open Cloud Native Platform (PaaS)
  • build, test, deploy & scale apps fast and easy
  • works with many languages and frameworks
PaaS Concepts
  • Anyone can deploy applications quickly and make them accessible for everybody
  • In case of high requests, platform can scale easily
  • Focus is on app and logic, not infrastucture
Load Balancing
  • BOSH creates and deploys VMs on infrastucture and deploys Cloud Foundry on top of this cloud
  • CF Cloud Controller runs apps on Clouds VMs, balancing demand, managing app lifecycles
  • router routes incoming traffic to VMs
Administration
  • Orgs
    • outer grouping boundary
    • development account that individual or multiple collaborators can own and use
    • Collaborators access an org with user accounts
    • Collaborators in an org share a resource quota plan, applicaitons, services, availability and custom domains
  • Spaces
    • inner grouping boundary
    • app and service is scoped to space
    • org contains at least one space
    • provides users with acces to a shared location for app deployment and maintenance
    • Each space role applies only to a particular space
  • User accounts
    • User account represents individual person within the context of a CF installation
    • can have different roles in different spaces within an org
  • Roles and Permissions
    • user can have multiple roles
    • combination of roles defines overall permissions in org and spaces
  • Domains
    • refers to DNS records
    • indicate to a dev that requests for any route created from the domain will be routed to cloud foundry
  • Quotas
    • Resource Plan for an Org
    • Memory Limit, Total Routes, Total Services, non-basic Services Allowed, Trial DB Allowed,...
CF CLI
  • CLI to communicate with Cloud Foundry
  • cf push Deploys code to Cloud Foundry and will be accessible via URL
Applications (Buildpacks & Droplets)
  • Droplet = App + Buildpack
  • Droplet sits in a app container and communicates with serives like DB or messaging
Buildpacks
  • Framework and Runtime Support for applications
  • examine user provided artifacts to determine what dependencies to download and how to configure apps to communicate with bound services
  • when you push an app, cloud foundry automatically detects which buildpack is required and installs it in the container where the app needs to run
  • possible to own buildpacks
  • possible to create offline buildpacks (need manual steps)
Advantages
  • easy deployment (only code necessary)
  • automatic setup of immutable artifact
  • Automatic restart
  • Aggregated logging
  • Scaling & Load-Balancing
  • Fault tolerance

Red Hat OpenShift

  • Open Source
  • Nutzt Docker Container
  • Kubernetes für Container Management und Skalierung

Kubernetes (genutzt von Red Hat OpenShift)

  • Pod - Gruppe von einem oder meheren Containers, shared Storage und runtime config (colocated und coscheduled - laufen in einem shared context)
  • master - besteht aus Set von Components, welche in einer Masternode laufen (API Server --> internal/external I/F via JSON/REST, Scheduler --> distributor und scale von Pods, Controller Manager --> CRUD von Pods und srvice endpunkten und etcd --> key-value store für config und state)
  • Node - Kubelet --> managed state und health (start/stop), Kube-Proxy --> load balancer und netzwerk proxy, cAdvisor --> resource monitor und performance metrics

Salesforce Heroku

  • eine der ersten Cloudplatformen
  • Dynos - isolierte virtualisierte Linux container
  • nutzt Buildpack technologie
  • Entwickler müssen in ein spezielles git einchecken damit der code in der cloud deployed wird.
  • Add-Ons: Datenbanken, Messaging,...

Amazon AWS

  • leading in IaaS
  • [IaaS] EC2 Elastic Compute Cloud --> skalierbare Rechenkapazität
  • [IaaS] S3 Storage Service (Buckets with Objects = Files + Metadata)
  • [PaaS] Amazon Lambda, Amazon Beastalk --> nutzt Bundles mit WAR files zum delivern, supportet Docker (Single Container --> 1 Container pro ec2-Instanz oder Multicontainer Docker --> mehrere Container mit ECS (ec2 container service mit autoscaling, load balancing, ...), Amazon Redshift

Google GCP

  • [IaaS] GCE Compute Engine wie EC2
  • [IaaS] BigQuery wie Amazon Redshift (Datenbank)
  • [PaaS] Google App Engine - wie Amazon Beanstalk

Microsoft Azure (services across whole stack)

  • [IaaS] Virtuelle Maschinen, networking und storage; Cloud Services
  • [PaaS] App Service

Private, Public, Hyprit Cloud

Name IaaS Hardware IaaS Operations PaaS Operations Comment
Private private private private
private private provider Focus on Support
private provider private unsusual
private provider provider
Private with off-premise HW dedicated private private
dedicated private provider
dedicated provider private
Private with Dedicated HW dedicated provider provider
off-premise public private private
Public Self-Managed public private provider unusual
Public IaaS public provider private unusual
Public public provider provider Blog(4)

private Cloud --------------------------------------- public Cloud on-premise --------------------------------------- off-premise privacy --------------------------------------- cost savings individualim --------------------------------------- reliability high performance/specialized hardware --------------- unlimited capacity

Hybrid Cloud -> Kombination von 2 oder mehr Ansätze Typisches Szenario: Private Cloud für sensible Daten, Public Cloud für Massen Operationen und End-User App Hosting (reliablility)

CAP Theorem: Scale Out (Eric Brewer)

Scaling without implications - Kapazität einer Maschine erhöhen - Scale Up Scaling with implications: Anzahl der Maschinen (evtl. schlechte qualität) erhöhen - Scale Out

CAP

  • Consistency (immediate)
  • Availability (always)
  • Partition Tolerance (delayed messages between nodes because of network traffic - is given)

Flexibilität zwischen Availability und Consitency

Es ist unmöglich, alle drei Dinge zu erfüllen, es gehen lediglich 2.

Es gibt immer ein Tradeoff zwischen Consitenz (most recent read) und availability (wie schnell ist die response time)

Conway's Law (Melvin Edward Conway)

Jede Organisation welche ein System Designed wird zwangläufig ein Design erstellen, was die Kommunikation Stuktur im Unternehmen widerspiegelt

Domain Driven Design (Eric Evans)

Der Entwurf komplexer fachlicher Zusammenhänge sollte auf einem Modell der Anwendungsdomäne, dem Domänenmodell basieren

  • Domain - Anwendungsdomäne, sphere of knowledge, die Domäne, in welche rder user das Programm verwendet

  • Model - Ein System von Abstraktionen, welche ausgewählte Aspekte der Domain beschreiben und Probleme dieser Domain lösen

  • ubiquitous language - Eine Sprache, welche um das Domain model strukturiert ist und alle Team Member nutzen, um aktivitäten innerhalb der Software verbinden

  • Context - Eine Einstellung, in welcher ein Wort oder Statement auftritt und seine bedeutung erhält. Statements über ein Model kann nur in einem Context verstanden werden

  • Bounded Context - Eine Beschreibung einer Grenze innerhalb eines Domain Models, Dort haben Phrasen der Ubiquitous Language besondere und genaue Bedeutung (Sales Context oder Support Context)*** Hilft den Teammembern für ein shared understanding um zzu identifizieren, was consistent ist und was unabhängig entwickelt werden kann.

  • Entities sind Objekte, welche über ihre Identität definiert sind

  • Value Objects sind Objekte, welche nur über was sie sind definiert sind, nicht wer oder wie sie sind. (Keine Identität)

Property Entity Value Object
Identity yes no
Mutable yes no
Side-effect free behaviour no yes
Lightweight no yes
Lifecycle yes no
May exist on its own yes no

Layered Architecture in DDD

  • User Interface - Zeigt Daten an, interpretiert User Commands
  • Application Layer - Koordiniert die Aktivität der Software (keine Business Logik) - hält keinen state der business objekte, kann state der Prozesse beinhalten
  • Domain Layer - Herz der Business Software (Beinhaltet die Inforation der Domain) - State oder Business Objekte
  • Infrastucture Layer - Library der anderen Layer, Persistenz, Kommunikation zwischen Layern

Trugschlüsse bei verteiltem rechnen

  • Das Netzwerk ist zuverlässig
  • Es gibt keine Latenz
  • Bandbreite ist unendlich
  • Das Netzwerk ist sicher
  • Topologie ändert sich nicht
  • Es gibt nur einen Administrator
  • Tansport kostet nichts
  • Ein Netzwerk ist homogen

12-Faktor Apps

von Heroku (Cloud Pioneer) entwickelte Guideline um cloud-Native Apps zu bauen

  • Codebase - eine Codebase mit Versionsverwaltung, viele deploys (production, staging, dev1, dev2,...)
  • Dependencies - Explizit deklarierte und isolierte Abhängigkeiten
  • Config - Speichere die Konfiguration in Umgebungsvariablen
  • Backing services - Behandle Backing Services als anhängende resourcen
  • Build, release, run - Separiere build und run Phasen
  • Processes - führe die App as einen oder mehrere stateless prozesse aus
  • Port binding - Serives mithilfe von Port Binding ausführen
  • Concurrency - Skaliere mithilfe des Prozess Modells (mehrere gleiche prozesse)
  • Disposability (Einweggebrauch) Robuster mit schnellem Start und problemlosen stopp
  • Dev/prod parity (dev-prod vergleichbarkeit) Entwicklung, staging und Produktion so ähnlich wie möglich halten
  • Logs - Logs als Event strom behandeln
  • Admin processes - Admin/Management Aufgaben als einmalige Vorgänge behandeln

Microservices

Jede Funktionalität in einem separaten Service Git bei vielen Usern, aber langsamere Responcetime als Monolithische App

Why?

Scale (CAP Theorem), Conways Law...

Characteristics

  • Single Responsibility
  • Share Nothing
  • Independent Deployable
  • Small in Size
  • Resilient
  • Complete
  • Monitored
  • Isolated
  • Replicated Data
  • Own Your State Exclusively
  • Decounpled in Time and Space
  • Smart Endpoints, Dumb Pipes
  • Do One Thing and Do It Well
  • Decentralized Data Management
  • Easy Replacable
  • Organized atound Capabilities (UI, Bookin, Logisics,..)
  • Polyglot Deployment
  • Elastic (Disposable, Fast Startup,..)
  • Mandatory Infrastructure Automation (with continous delivery)
  • Clusterable
  • Scalable
  • Act Autonomously
  • Two-Pizza Teams ??-

FaaS (Serverless Computing)

next level services

  • event driven computing - functions are invoked by events
  • fully implements reactive architecture
  • fully implements 12-factor app
  • saves costs
Virtual Machines Containers Serverless
Unit of Scale Maschine Application or Microservice Function
Abstraction Hardware Operating System Language Runtime
Packaging AMI Container File Code
Configure Machine, storage, networking, O/S Run Servers, configure application, scaling Run code when needed
Execution Multi-threaded, multi-task Multi-threaded, single task or process Single threaded, single task
Runtime Hours to months Minutes to days Microseconds to seconds
Unit of cost Per VM per hour Per VM per hour Per memory/second per request
Amazon EC2 ECS AWS Lambda

Spring Framework

  • lightweight alternative to Java EE
  • Configured through XML
  • configurations re-occur in different deployments, so domt write them, reuse them
  • Infrastucture Support
  • enables to build Apps from Plain Old Java Objects (POJOs) and to apply enterprise services non-invasivley
  • Key concept IoC (Inversion of Control) - Generalized concept of Dependenxy Injjection (allows the framework to control custom code)

Spring Core Container

  • spring-core und spring-beans (Core Components including the IoC features)
  • spring-context (access objets in a framework-style - similar to a JNDI registry)
  • spring-context-support (allows integration of caching, mailing, scheduling, template enginges)
  • spring-expression (powerful expression language for querying and manupulating an object graph at runtime)
  • spring-messaging (key abstractions such as Message, MessageChannel, MessageHandler
  • spring-jdbc (JDBC-abstraction layer - removes need to do JDBC coding and parsing of specific error codes)
  • spring-web and spring-webmvc (web-oriented integration features e.g. multipart file upload; MVC + REST Web Services implementation for web)
  • spring-test (unit testing and interation testing)

Spring Boot

  • takes opinionated view of building Spring apps
  • Convention over configuration
  • get up and running as quickly as possible
  • Creates Stand-Aline Spring Applications
  • Embed Timcat, Jetty, Undertow (no need to deploy WAR files)
  • auto config Spring whenever possible
  • not an application server
  • does not implement any enterprise Java specification
  • no code generation
  • Spring Boot is taking over the configuration effort

Spring Boot Essentials

  • Auto Configuration
  • Starter Dependencies
  • Actuator (health status)
  • Command-Line Interface

Actuator

  • Part of Spring Boot Framework
  • Application Metrics
  • Health, Configurations, Error page, Version Details,...
  • Access through HTTP (/health /error /metrics /beans /info)

Spring Cloud

  • based on Spring Boot
  • Provides Tools to quickly build apps
  • addresses common patterns in distributed systems
  • not focused on particular platform

Patterns Addressed

  • Configuration management
  • serivce registry and discovery
  • resilience and service breakers
  • intelligent routing and load balancing

Spring Cloud Netflix

  • originated as Netflix OSS
  • based on Spring implementations
  • partially integrated into Spring Cloud projects
  • now a core project of Spring Cloud

Services Provided

  • Eureka - service registry and discovery
  • Hystrix - circuit breaker and dashboard
  • Feign - dclaratice REST client
  • Ribbon - client-side load balancing
  • Zuul - routing & filtering

Config Server

  • Store Config in Environment
  • Erfüllt damit die 12 Factor App
  • Kann über Property File injected werden
  • Default Value kann festgelegt werden

Service Registry (Eureka)

  • Multiple services run distributed and in parallel
  • to enable communication services need to know how to find each other
  • Service Provider and service consumer register at Eureka Server as client
  • Server will register them by the property string.application.name

Ribbon

  • client-side load balancing and fault tolerance

Feign

  • declarative REST client
  • simplify HTTP client cals
  • only requires declaration and annotation of an interface while actual implementation will be provisioned at runtime

REST (Roy Fielding)

Ein Stil der Softwarearchitektur. Es ist eine Sammlung von Netzwerk Architektur Prinzipien, welche darstellen, wie Ressourcen definiert und adressiert sind.

HTTP + JSON is REST, CRUD is REST, Hypermedia is optional

  • URI Addressable Resources

  • HTTP Protocol

  • Make a Request - Receive Responce - isplay Response

  • Nouns (Resources) - unconstrained e.g. http://example.com/employee/42

  • Verbs - constrained e.g. PUT

  • Representations - constrained e.g. JSON

REST ist kein Standard, nutzt aber selbst einige:

  • HTTP
  • URL
  • XML/HTML/GIF/JPEG/etc. (Resource Representations)
  • MIME Types

Glory of REST

  • Level 0: Swamp of POX
  • Level 1: Resources
  • Level 2: HTTP Verbs
  • Level 3: Hypermedia Controls
    • { "content":"Hello, User!", "_links":{ "self":{ "href":"http://localhost:8080/greeting?name=User" } } }

Hypermedia is a constraint. As in, you either do it or you aren't doing REST

The API must be changable, evolvable and deployable

In Reading Data from a service be as tolerant as possible

Consumer-Driven Contracts

Consumer tell you how they use the API, so you can test if something breaks

  • PACT (JVM)

Lessons Learned

  • Code Generation leads to couping consumers with providers
  • and couples release cycles (slows down speed)
  • therefore --> Tolerant Reader Pattern

HATEOAS (Hypermedia as the engine of application state)

Serivce Provider takes the business decision, not the client

  • Client enters REST through fixed URL
  • All future actions are discovered within resource representations from the server

Persistence

Spring Data Framework (in Spring-Boot context)

  • used in relational and NoSQL DBs
  • uses NoSQL DBs, JPA
  • Abstraction Level ist Entity/ORM
  • provides lots of default functionality
  • unified use of different DBs
  • custom object-mapping abstractions
  • custom repo code
  • Dynamic query derivation from repo method names
  • Implementation domain base classes providing basic props
  • Support transparent auditing (created, last changed)
  • Easy Sptring integration via JavaConfig and custom XML Namespaces
  • Advanced integration with Spring MVC controllers
  • DONT HAVE TO WRITE IMPLEMENTATION OF REPOSITORY INTERFACE (is creatd by Spring Data JPA on th fly)

Main Modules

  • Spring Data Commons - Core Spring concepts underpinning every Spring Data project
    • Repository (class)
      • No implementation needs to be writen for data access
      • data inegration with few lines of code
      • interface acts as marker interface
      • CrudRepository (class)
      • PagingAndSortingRepository (class)
    • If more than 1 repo, autowiring cannot guess, so additional work has to be done
    • Spring Data JPA - Makes it easy to implement JPA-based repositories
      • uses JDBC
        • works with realtional DBs
        • follows user-specified schema
        • (almost) no server-side scripts
        • transactions and ACID properties
    • Spring Data MongoDB - Support and repositories for MongoDB
      • uses MongoDB direct access
        • NoSQL document centric datastore
        • schema-free
        • loves JavaScript
        • supports map-reduce
        • own transaction concepts
    • Spring Data REST - Exports Spring Data repositories as Hypermedia-driven RESTful resources
      • uses REST protocol

JPA - Java Persistence API

  • provides components to access db for read, write and query
  • annotations solve 99% of challenges
  • Query Language (JPQL) - similar to SQL provides dynamic and flexible acces to the data
  • Java Persistence Criteria API - provides possibility to create queries (typesafe)
  • Object/relational mapping metadata - mapping Java Object info to DB tables and vice versa (requires metadata on details of mapping)
  • only realtional databases
  • widely used
  • uses Hibernate

Persistence --> (creates at startup) --> EntityManagerFactory (configured by Persistence Unit) --> (creates) --> EntityManager (creates Entity Transaction and Query) --> (manages) --> Entity

  • Entities represent data (go through variois states) - Keep possible states in mind when programming JPA
    • New/Transistent
    • Managed
    • Removed
    • Detached

UI Frameworks

Bootstrap, Thymeleaf, Spring MVC, vaadin, JSF (JavaServerFaces)

MVC

  • Model - containes data, changes are published via observer
  • View - displays data and provides means to trigger actions (knows model and controller)
  • Controller - calls model and views appropriatley
  • Controller is where actions (clicks, refreshes, forms, ...) are received

Properties

  • MVC Frameworks / Helpers
  • Component Technologies, View Technologies
  • Template-Based
  • Language-Agnostic
  • JavaScript-Based
  • Java-Based
  • Server-Side Frameworks, Client-Side Frameworks, or mixed
  • Frameworkswith Focus on Mobile
  • Frameworks for Responsive Design
  • Frameworks integrating well with Spring
  • Frameworks integrating well with other Frameworks

For Spring, use Thymeleaf

Thymeleaf

server-side Fava template enging for both web and standalline environments

  • HTML - templating doesnt perform checks, any HTML is allowed
  • XML - all XMl allowed, outcome is exprected to be XML
  • Text - allows any input and output
  • JavaScript - special escaping is available
  • CSS - CSS-aware
  • raw - used to include untouched data

Templating can be context-sensitive - you could implement own dialect

  • Thymeleaf enginge needs to be configured (where are templates, which suffixes,...)
  • Template resolver implement caching for templates, location of files, which template mode
  • Enginge finally reads files and provesses them
  • Spring Boot does all configuration by boot's autoconfig!!!

Resilience Patterns

central requirement for a working cloud application

  • Timeouts - Timer expires (no infinite waiting time)
  • Back Pressure - Make overloading transparent to client/requestor (happens before Timeout occures. Pressure [should] generates counterpressure
  • Data Redundancy - Data form another System is stored redundant in database of microservice as a fallback. If system fails we still get data
  • Bulk Heads - Devide and run functionalities in separated resources. Then, one functionality cannot take other functionalities down.
  • Circuit Breaker - calls another function as fallsback function (or provide default value) (Netflix Hystrix)
    • Hystrix provides also Dashboard
    • Hystrix Stream, additional data on dashboard

Messaging

Messaging geschieht asynchron. Es gibt ein Storage und eine Functionalität, welche sicherstellt, dass eine Message - wenn gesendet - zugestellt wird. Falls möglich. (normalerweise von einem Messaging Server bereitgestellt)

2 Architekturen:

  • Point-to-Point (PTP)
    • message producer sendet in eine queue
    • message consumer bekommt die Nachricht und entfernt sie aus der queue
    • sender und receiver kommunizieren nur mit Messaging Server (MOM - Message Oriented-Middleware)
  • Publish-Subscribe (Pub-Sub)
    • message producer schick Nachricht in ein "Topic"
    • mehrere message consumer (subscribers) zu diesem Topic empfangen die Nachricht (wenn sie online sind)
    • interagieren nur mit MOM

Asynchron vs Synchron

asynchron:

  • sender ist es egal ob receiver online ist
  • receiver liest message, wenn er verfügbar ist
  • sender wird nich blockiert (wartet nicht auf acknowledge)
  • delivery guarantees: maybe, at least once, exaclty once
  • FIFO
  • loose coupling
  • skalierbarer
  • bei Änderung müssen sender/receiver interfaces in sync bleiben

synchron:

  • Funcion Calls
  • HTTP (synchrones Protokoll)
  • für sender muss receiver online sein
  • sender wartet auf acknowledge von receiver
  • einfacher zu testen und zu ändern
  • weniger Overhead
  • bessere performance

Microservices sollten Asynchrones Messaging für die Kommunikation untereinander nutzen, da die Isolation Eigenschaft sehr wichtig ist

Terms

  • Protocol - bescheibt, wie Producer, Broker und Consumer miteinander interagieren
  • Producer - Sender
  • Broker - MOM (store and forward messages) - weitere features (transformation, aggregation und composition von Messages)
    • Bei Microservices werden die Messages nur geroutet, die anderen Features werden nicht genutzt
    • AWS: Amazon SQS
    • Azure: Azure Service Bus
    • Google: Google cloud Messaging / Firebase
    • OpenShift: JBoss Fuse und JBoss A-MQ
    • Cloud Foundry: RabbitMQ, Solace und andere
  • Consumer - Receiver
  • Message Format - Bescheibt Content der Message (Strukutr, meta-data, wie serialized)
  • Payload - tatsächliche Information, welche der Producer dem Consumer schicken will

Messaging for Microservices

Brokers (unterschiede)

  • License
  • ease-of-use
  • performance
  • scalability
  • functionality: monitoring, statistics, security
  • QoS: delivery exaclty once etc., transactionality, failover, high-availability
  • supported patterns: point-to-point, publish-subscribe
  • supportet protocols: AMQP, STOMP, MQTT, HTTP (not a messaging protocol)

Protocols

  • AMQP - Advanced Message Queuing Protocol
    • applicaiton layer protocol
    • message orientation, queuing, routing (PTP, Pub-Sub), reliablility, security
    • Kommuniziert auf Transport Layer (uses TCP,...)
    • Message besteht aus
      • header
      • delivery annotations
      • message annotations properties
      • bare message (system properties, application properties, body)
      • footer
    • erlaubt Flow Control
    • Quality of Serivce Levels
      • at most once: fire and forget
      • at least once: assured delivery
      • exactly once: Most exprensive one achieved by double-commit
  • STOMP - Streaming Text Oriented Messaging Protocol
    • known as TTMP, text-based protocol
    • interoperable wire erlaubt clients mit jedem message broker zu kommunizieren, welcher dieses Protokoll unterstützt
  • MQTT - Message Queue Telemetry Transport
    • für IoT devices (nicht microservices!)

JMS vs AMQP

  • JMS: Consumers connec to Queues and Topics (Queues and Topics)
  • AMQP: Consumers connect to Queues only (Queues and Exchanges)

Message Formats

auch Serialization Format

  • Kryo - Java only
  • Protocol Buffers
  • Apache Thrift
  • JSON

Frameworks

  • Spring Cloud Stream
    • magic
    • autoconfigures your message serializer (Kyro or Protobuf)
    • autoconfigures usage of your message broker (RabbitMQ or Kafka)
  • JMS (Java Message Serivce)
  • Specialized Frameworks for communication Microservices
    • Axon
    • Eventuate
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment