Skip to content

Instantly share code, notes, and snippets.

@jahe

jahe/microservices-cheatsheet.md

Last active December 13, 2023 16:04
Show Gist options
  • Save jahe/d2d143f1c1b2c605bb6665f9673a231e to your computer and use it in GitHub Desktop.
Save jahe/d2d143f1c1b2c605bb6665f9673a231e to your computer and use it in GitHub Desktop.
Download ZIP
Microservices Cheatsheet
Raw
microservices-cheatsheet.md

Glossar

  • Sidecar - Process that encapsulates required technologies (e.g. logging, monitoring, service discovery, etc.) in the microservices environment and makes them available to microservices that are not able to use those technologies natively
  • Immutable Server -

Configuration + Coordination

  • Zookeeper - https://zookeeper.apache.org/ - Provides configs in a hierarchical key-value store that is replicated and synchronized across large distributed systems.
  • etcd - https://github.com/coreos/etcd - Like Zookeeper. Distributed reliable key-value store for the most critical data of a distributed system. Provides a REST API. It is possible to do locking in a distributed system with it.
  • Spring Cloud Config - Provides a REST API. Config files can be based in a Git repo. The config data can be encrypted (e.g. for passwords in config files)

Service Discovery

  • DNS - with SRV-Records to provide the IP-Adress as well as the port of the service
    • One Implementation is BIND, written in C and runs on all operating systems
  • Eureka - Service Discovery Server + Client, written in Java
    • Per service Eureka saves Host and Port to the servicename
    • There can be multiple Eureka Servers for HA
    • Can act as a simple Load-Balancer since there can be registered multiple instances of one services
    • Eureka Server polls each instance to check its availability
    • Eureka Clients cache the config so that they can invoke other services directly (without a roundtrip to the Eureka Server)
    • Non-Java Clients can be integrated by a Sidecar application that provide the service discovery functionality to the microservice
  • Consul - Key/Value store, written in Go
    • Clients register on the server and subscribe for specific events
    • Provides DNS and HTTP/JSON Interfaces
    • Does Healthchecks the the services

Load Balancing

  • One Load Balancer per microservice
  • httpd - with mod_proxy_balancer the classic Apache webserver provides Load Balancing capabilities
  • nginx
  • HAProxy - Doesn't only support HTTP but all TCP based protocols
  • Cloud provider offer their own load balancers like Elastic Load Balancing in Amazon AWS

Security

  • Every Microservice has to be able to determine who (which user) initiated the request
  • There has to be a uniform security architecture across all microservices

OAuth2 Access Token

  • An Access Token can contain encoded information about about the users permissions or the users permission groups
  • JWT (JSON Web Token) is a standard for encoding information in an Access Token
    • The data structure is JSON
    • The Access Token can be verified if there is a digital signature with JWS (JSON Web Signature)
    • The Access Token can be encrypted with JWE (JSON Web Encryption)
    • Possible information within the Access Token:
      • Creator of the Access Token
      • Resource Owner
      • Validity period of the Access Token
      • Address data of the Access Token (???)
      • Or there can be your own custom information inside the Access Token
    • The Access Token is optimized to be encoded from JSON to BASE64 and then be transfered within a HTTP-Header field (These fields are commonly limited in size)
  • The first step in a microservices architecture is that the user authenticates with OAuth2
  • After that he can open the website or call the REST interface of a microservice
  • The Access Token can then be redirected when a microservice calls other microservices
  • Those microservices can decide whether a specific access is allowed with this Access Token
    • Therefore the microservice can verify the validity period of the Access Token
    • In case of JWT the Token only has to be decrypted and then verify the digital signature of the Authorization Server
    • The information within the Access Token (e.g. permission groups of the user) can then be used to decide whether the user gets access to the resource or not
  • It is important that the Access Tokens content doesn't contain the information about which microservices can be called and which not
    • The Access Token is created by the Authorization Server - so that every permission change would result in an update of the Authorization Server
    • It is better to let the microservices decide about the access permission - so that permission changes only result in an update of a specific microservice
  • Alternatives to OAuth2 as a central authorization system
    • Kerberos - Isn't well optimized for REST systems like OAuth2
    • SAML + SAML 2.0 (Security Assertion Markup Language) - Defines a protocol that applies authentication and authorization with XML and HTTP
  • Spring Cloud Security offers a base to implment OAuth2 systems
  • OAuth2 solves the problem for authentication and authorization - especially for human users
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment