Reactive Micro Services with Java seminar

copyright 2015 Trainologic LTD
Micro Services

2 copyright 2015 Trainologic LTD
• Architectural style for designing software applications.
• Revolves around independently deployable services.
• This is in contradiction to the common monolith, single
unit applications.
• E.g., an uber-process (WebSphere) managing the
complete business logic of the banking web application.
• In the micro-services approach, there will be many
small and independent services (processes).
Micro Services
2
Micro Services

• The monolithic approach has some drawbacks:
• Change cycles are bound together.
• Harder modularity (crossing the bounds is easy).
• Scaling is harder.
• Separation is hard.
Problems with the Monoliths
3
Micro Services

• Characteristics:
• Componentization is achieved via services
(processes) and not by libraries (makes them
independently deployable and upgradable).
• Teams are grouped by business capabilities (cross-
functional teams) as opposed to technology
specialization teams.
Micro Services
4
Micro Services

• Instead of “project” approach, a team “owns” a
product. A “you build, you run it” approach.
This should be backed by a proper organizational
process.
• Smart endpoints – dump pipes. Avoid using
sophisticated tools (with lots of smart logic) and
favor simple REST protocols.
Micro Services
5
Micro Services

• Automation – CI, CD and Continuous Deployment.
• Design for Failure.
• Evolutionary Design – separate evolution between
services.
• Decentralized Governance.
• Decentralized Data Management.
Micro Services
6
Micro Services

• One of the questions is how big or small a micro-service
should be.
• First rule, don’t measure in lines of code!
• Introducing: Bounded Context.
• Coined in Domain-Driven-Design.
Design
7
Micro Services

• Ubiquitous Language.
• Does your model have the same meaning in different
micro-services?
Design
8
Micro Services

• The Twelve-Factor App is a document written by Adam
Wiggins of Heroku which summarizes huge experience
with SaaS applications regarding correct architectural
style.
• It is tool and language agnostic.
The Twelve-Factor App
9
Micro Services

1
0
• Each app has a single code-base.
• There are (typically) many deploys for a single code-
base (dev, stage, prod).
• A clear violation is many apps sharing the same code-
base.
One Codebase per App
10
Micro Services

1
1
• You should use a dependency distribution packaging
tool.
• Available for almost any language.
• I.e., Maven for Java.
• Apps should not rely on any external dependency.
• Simplifies developer work (just checkout the code).
Explicit and Isolated Dependencies
11
Micro Services

1
2
• Configuration should never be in code.
• Configuration that may vary between deployments
should be defined as environment properties.
• Not even in config files or config groups (they don’t
scale well).
Configuration is in the Environment
12
Micro Services

1
3
• Backing services should be treated as attached
resources.
• You should be able to attach/detach at will.
• There is no distinction between local and third party
services.
• Migration from one to the other should be seamless to
the deployment.
Backing Services
13
Micro Services

1
4
• Strict separation between the 3 stages.
• Build: from code (SCM) to binaries (Binary Repository).
• Release: Combination of binary (previous step) and
configuration.
• Run: Running the application in the execution env.
Build, Release, Run
14
Micro Services

1
5
• An application is executed as one or more processes.
• The processes share nothing between them (neither
disk or memory).
• They are also stateless.
• All stateful data should be stored in backing services.
• I.e., sticky sessions are a clear violation of this principle.
Processes
15
Micro Services

1
6
• A twelve-factor app does not run on a web server, it
provides an HTTP service.
• I.e., embedding the server in the application’s user
space and binding a port.
• This is true for more than HTTP.
• Port-binding also allows for one app to become the
backing service of another app.
Port Binding
16
Micro Services

1
7
• In a twelve-factor app, processes are first-class citizens
(and not threads).
• There can be several process-types.
• The share-nothing and stateless model allows for easy
scaling.
• Do not rely on self daemonizing techniques. Use your
OS’s process manager.
Concurrency
17
Micro Services

1
8
• Each process should be made disposable.
• I.e., it can be stopped, started or restarted at any time.
• You processes should:
• Have minimum startup delay.
• Graceful shutdown on a SIGTERM.
• Robustness against fatal case (Let-it-crash model).
Disposability
18
Micro Services

1
9
• A twelve-factor app should minimize the difference
between development, staging an production process.
• This include personnel, time and tools.
• Usually this is achieved by a continuous delivery
process.
• Developers should not use ‘lite’ versions of the
production tools.
• Modern CM tools allow for easily setting up a
production-like env for development.
Dev/Prod Parity
19
Micro Services

2
0
• Logs should be treated as streams.
• Each process should write its log to the stdout.
• In dev, it is watchable on the terminal.
• In staging and prod, it should be indexed in a dedicated
storage (e.g., ElasticSearch).
Logs
20
Micro Services

2
1
• Management and admin operations should be run as
one-off processes in the same environment as the
application.
• Admin code should be shipped with the application code
and use all the previous factors discussed.
Admin Processes
21
Micro Services

2
2
• Aim for eventual consistency and not strong
consistency.
• Each micro-service should have it’s own DB/Schema.
Data
22
Micro Services

2
3
• Design for scalability (do not block).
• Logging:
• Try to use the “entrypoint” stdout as much as you
can.
• For other logging, connect to ELK.
• Use MDC!
• Favor REST API based on JSON representation.
• Always provide liveness and readiness endpoints.
Implementation
23
Micro Services

2
4
• Always consider resources.
• Apply back-pressure always!
• Use Circuit Breakers.
Implementation
24
Micro Services

2
5
• Micro-services ease the task of building a proper CD
pipeline.
• Do it!
The Process
25
Micro Services

2
6
• Some drawbacks for micro-services:
• Complexity is shifted to the network.
• Incur barriers between services.
• Complexity in message formats.
• Load balancing and fault-tolerance may become
more complex.
• Micro services are not suited for extremely low-latency
applications.
Beware
26
Micro Services

Akka

2
8
Akka
• Akka is an open source framework for building highly
concurrent, distributed and fault-tolerant applications.
• Let’s review some of the high level features of Akka…
Introduction
28

2
9
Akka
• Akka provides the following:
• Actors and remote actors.
• Supervisor hierarchies (implementing the Let-it-crash
idiom) – explained later.
• Futures and Agents.
• Scala API & Java API!
Akka Features
29

3
0
Akka
• Use cases for Akka in production:
• Transaction processing.
• Concurrency & Parallelism.
• Simulation (Compute Grid, Map/Reduce).
• Batch Processing.
• Communication Hub.
• Backend Services.
• Gaming.
• Data Mining.
Use cases for Akka
30

3
1
Akka
• An actor is a message processor which processes
messages asynchronously (in a different thread).
• Taken after the Actors model in Erlang.
• Let’s take a look at an actor…
Actors
31

3
2
Akka
• To create an actor you should extend from the
UntypedActor class.
• E.g.:
Actor
32
public class SimpleActor extends UntypedActor {
@Override
public void onReceive(Object message) throws Exception {
System.out.println("Got: " + message);
}
}
class SimpleActor extends Actor {
def receive = {
case msg => println(s"Got: $msg")
}
}

3
3
Akka
• You should never instantiate actors yourself.
• You can never hold the direct reference of an actor.
• Only Akka does.
• This will ensure that mutable members inside the actor
are fully encapsulated and unshared.
• In order to create our first actor we need to work with
the ActorSystem.
Creating Actors
33

3
4
Akka
• ActorSystem represents a logical application.
• A configuration environment.
• Creating ActorSystem:
ActorSystem
34
ActorSystem as = ActorSystem.create("WelcomeToAkka");
val as = ActorSystem("WelcomeToAkka")

3
5
Akka
• The actorOf method will create an actor:
actorOf
35
ActorRef ref = as.actorOf(Props.create(SimpleActor.class),
"simpleActor");
val ref = as.actorOf(Props[SimpleActor], "simpleActor")
• We will discuss the Props later.
• And also the naming.
• For now, let’s discuss the ActorRef.

3
6
Akka
• Represents a reference to an actor.
• It is immutable and can be sent around inside
messages.
• Location transparent – can be obtained for remote
actors.
• Its most useful API: sending a message.
ActorRef
36

3
7
Akka
• Sending a message is done in an asynchronous way.
• The tell() method sends a message to the Actor.
Fire and Forget
37
ref.tell("Hello from Main", ActorRef.noSender());
// no need to specify sender, it is Actor.noSender (default param)
ref ! "Hello"
• The receiving actor will always get a ‘sender’.
• It will be null if the sender isn’t an actor.

3
8
Akka
• If the message is not handled, you should call the
unhandled method:
Handling the Message
38
public void onReceive(Object message) throws Exception {
if (message instanceof String) {
System.out.println("Got: " + message);
} else {
unhandled(message);
}
}
• It will send an UnhandledMessage instance to the
eventStream.

3
9
Akka
• What if you have a constructor that takes parameters?
Actor with Constructors
39
public SimpleActor(String region) {…
ActorRef ref = as.actorOf(Props.create(SimpleActor.class, "Israel"),
"simpleActor");

4
0
Akka
• The following methods are inherited:
• getSelf() returns the actor’s ActorRef.
• getSender() returns the current message’s sender (must
not be closed-over in messages). Will never be null.
• getContext() returns the context (access to the
actorsystem, children and more info).
• Lifecycle callbacks: preRestart, postStop, postRestart,
preStart.
The Actor’s Methods
40

4
1
Akka
• Replying is simple:
Replying
41
getSender().tell("Got: " + message, getSelf());
sender ! s"Got: $msg"
• The message will be added to the sender actor’s
mailbox.
• If the sender doesn’t exist, the deadLetters actor will
receive the message.

4
2
Akka
• Sometimes, we need to wait for a response and not get
it in our mailbox (or we are not actors ourselves).
• Send and receive is implemented in the ask pattern:
Waiting for Response
42
Future<Object> f = Patterns.ask(ref, "hello from main", 1000);
f.onComplete(new OnComplete<Object>() {
@Override
public void onComplete(Throwable f, Object result) {
if (f == null) {
System.out.println("got back: " + result);
}
}
}, as.dispatcher());
implicit val timeout = Timeout(5 seconds)
implicit val ec = as.dispatcher
val f = ref ? "hello from actor"
f.onComplete(_.foreach(msg => println(s"got back $msg")))

4
3
Akka
• Akka(Scala) provides better futures than Java.
• They support callbacks: onComplete, onSuccess,
onFailure.
• You must provide an ExecutionContext for your
callbacks.
• You can use the ActorSystem dispatcher, or use
ExecutionContexts for factory methods.
Futures
43

4
4
Akka
• Sometimes you’ll want to work with futures directly.
• The Promise class is a container for futures.
• You can get futures from it and ‘complete’ the promise
that will complete the futures. E.g.:
Promise
44
Promise<Integer> p = Futures.<Integer> promise();
Future<Integer> fi = p.future();
p.success(42);
val p = Promise[Int]()
val f2 = p.future
p.success(42)

4
5
Akka
• Futures can be composed using map, flatMap and filter
functions.
• Callbacks can also be chained by using the andThen
method.
• Use futures directly only when you need parallelism and
not more actor features.
Functional Futures
45

4
6
Akka
• PoisonPill – will stop the actor when the message is
processed. It will permanently stop the actor.
• Kill – will cause the actor to throw ActorKilledException
when it is processed.
• Identity – the actor will return its ActorRef. (used for
resolving selections).
Special Messages
46

4
7
Akka
• You can forward a message to another actor while
keeping the original sender:
Forwarding
47
anotherActor.forward(message, getContext());
• Its actually the same as using tell() and passing the
getSender().

4
8
Akka
• Routers are actors that dispatch their messages to their
routees.
• They are optimized to work in an efficient way.
• Example:
Routers
48
ActorRef router1 = as.actorOf(Props.create(SimpleActor.class)
.withRouter(new RoundRobinPool(3)));

4
9
Akka
• You can provide the ActorRefs directly to the router
constructor (use Props.empty() for the actor class).
• The router creates the routees, it will have its routees
as children.
• So, whenever a routee will need to access the router
(e.g., when replying) it will just get it from
getContext().parent(). (only if the routee is a child of
the router).
Routers
49

5
0
Docker
• You want to deploy many services/apps/micro-services.
• And you’d like the following features:
• Isolation (e.g.: OS, resources, networking).
• Scalability (distributed systems).
• Evolution (upgrades/downgrades).
• So want are your options?
• What about classic VMs?
The Problem Domain
50

5
1
Docker
• A VM provides:
• Full isolation.
• Evolution.
• Distribution.
• But, the downside:
• Heavy on resources.
• Takes time to start.
Classic VMs
51

5
2
Docker
• Docker provides:
• Decent isolation.
• Evolution.
• Distribution (via Docker Swarm/ Kubernetes).
• Fast start time.
• Share resources (for similar images).
• The downside:
• Only Linux.
Docker
52

5
3
Docker
• Docker is a lightweight container.
• Useful for deploying and running an
application/service/micro-service with its environment.
• You can run your packaged application on production
server, staging server, development machine or even a
laptop.
• How does Docker works?
Docker
53

5
4
Docker
• Docker leverages the Linux namespaces feature.
• Linux namespaces that Docker uses:
• pid – process id numbering.
• net – the network stack (including loopback).
• ipc – Inter-Procces-Communication (shared memory,
semaphores).
• mnt – mounting.
• uts – hostname.
Linux Namespaces
54

5
5
Docker
• Docker also leverages the cgroups technology which
allows to share and limit resources between containers.
• And because Linux kernel API is backward compatible,
you can run any Linux on any Linux with Docker!
Linux cgroups
55

5
6
Docker
• Docker uses Union FS which is layered.
• This means that a Docker image will only contain the
difference from the parent image.
• You can deploy thousands of containers from the same
image without “almost” any additional cost.
The Filesystem
56

5
7
Docker
• The following concepts participate in Docker
architecture:
• The Docker daemon.
• The Docker client.
• Docker images.
• Docker registries.
• Docker containers.
The Participants
57
Image taken from docs.docker.com

5
8
Docker
Docker architecture
58

5
9
Docker
• The host process of Docker.
• Users interact with the daemon through the Docker
client binary.
• The client can connect from a remote machine.
• The daemon manages the images and the containers.
Docker Daemon and Client
59

6
0
Docker
• Based on a “Dockerfile” file
• “Dockerfile” contains instructions on how to build the
image.
• The image itself should reside in a Docker registry.
• Read only template that is used to instantiate containers
• Composed of layers – Each “Dockerfile” instruction is a
new layer
• Based on the UFS – Union File System
Docker Image
60

6
1
Docker
• Manages Docker images.
• The main public one is: Docker Hub.
• You can create your own private registry.
• Main point of distribution.
Docker Registry
61

6
2
Docker
• A runnable instance of the Docker image
• Can be ran, start, stopped, moved or deleted
• Secure and isolated application platform
• Can be given access to resources on other hosts
Docker Container
62

6
3
Docker
• docker run [options] image [command] [args]
• More than 80 options! The most useful:
• --name – gives the container a name
• --rm – removes the container at the end of the
• -d – run container in the background
• -it – interactive mode
• -p [host port:container port]
• -v [volume definition] – will be discussed later on
• --network will also be discussed later on
Running Containers
63

6
4
Docker
• You can list the current containers with the following
instruction: docker ps
• Will list the running instances.
• Use the –a argument to list all the containers
(including stopped ones).
• To stop/start a container :
• docker start/stop [container name]
• To remove a container: docker rm [container name]
Managing Containers
64

6
5
Docker
• Connect to a running container:
• docker attach container – connects to a running
container
• docker exec –it container /bin/bash – opens bash
shell on the specified container
Debugging Containers
65

6
6
Docker
• A Docker image is built from a Dockerfile.
• Should reside at SCM
• Syntax:
• Comments are lines starting with ‘#’.
• Every other line is in the format: ‘instruction
arguments’.
• Let’s see the available instructions…
Dockerfile
66

6
7
Docker
• FROM – the first instruction in the file which specifies
the base image to build upon.
• MAINTAINER – the author of the image.
• RUN <command> -- runs a command in shell form.
• RUN [“exec”, “arg1”, …] – runs a command in exec
form.
• CMD – discussed later.
• LABEL key=value key=value – adds metadata to the
image.
Instructions
67

6
8
Docker
• ADD – adds file(s) from the context to the image. You
can use regex and even urls.
• COPY – same as ADD but without URL and tar handling.
• ENTRYPOINT – discussed later.
• VOLUME “/dir” – creates a mount point for externally
mounted volumes.
• USER – sets the user for the next instructions.
• WORKDIR – sets the working directory for the next
instructions.
Instructions
68

6
9
Docker
• Will define an executable to run when running the
container.
• Any arguments to the ‘docker run’ command will be
appended to the entrypoint.
• There can be only one entrypoint in the dockerfile.
• You can use CMD once in your dockerfile to provide
default arguments for the entrypoint.
ENTRYPOINT / CMD
69

7
0
Docker
• A specially designed directory that bypasses the UFS
• Meaning changes are written directly
• Used for persistent data (DB, files) or to share data
between containers
• docker run/create –v [[host path]:][docker path]
[image name]
• docker run –v /dbdata postgresql
• docker run –v /host_path:/docker_path postgresql
Volumes
70

7
1
Docker
• To view all the available volumes use :
docker volume ls
• To remove unnecessary volumes use:
docker volume rm [volume name]
• More useful to remove volumes that belong to a specific
container:
docker rm –v [container id or alias]
Managing Volumes
71

7
2
Docker
• To share data between containers use data container
• Creating data container:
• docker create -v /dbdata --name dbstore
training/postgres /bin/true
• Using it in other containers:
• docker run -d --volumes-from dbstore --name
db1 training/postgres
• Loads all the volumes from the dbstore container
Data Containers
72

7
3
Docker
• docker build [options] PATH | URL
• Builds the Docker image from a “Dockerfile” and a the files
located in the path/URL
• Searches for “Dockerfile” file by default or use –f [other
docker file] option to specify the Dockerfile
• The URL can point to:
• GIT repository
• Plaintext file
• Tarball context
Building Images
73

7
4
Docker
• Every image has a unique id given during the build
• It can also be tagged: [Repository[:tag]
• Repository is used to group similar images together
• Tag is used to differ images in the same repository,
usually used for versioning
• Repository != Registry
• docker build –t repo:tag1 repo:latest .
Tagging Images
74

7
5
Docker
• You can create private or bridge networks between
containers.
• By default all the containers are on the same bridge
network – can access each over by ip
• You can also use the legacy --link to make containers
aware of their peer hostname.
• Use ‘docker create network’ command to create
networks
Managing Networks
75

7
6
Docker
• User-defined networks can be either:
• bridge – single host network, every container sees
the other containers by host name
• overlay – similar to bridge but across multiple hosts
in docker swarm
Managing Networks
76

7
7
Docker
• docker-compose is a tool for managing a group of
containers on a single host.
• You can use it with docker swarm for multi-node
environments.
• docker-comose revolves around the docker-
compose.yml.
Docker Compose
77

7
8
Docker
• Example:
consul:
command: -server -bootstrap -advertise 10.0.2.15
image: progrium/consul
restart: unless-stopped
ports:
- "8300:8300"
- "8400:8400"
db:
image: mysql
environment:
MYSQL_ROOT_PASSWORD: root
volumes_from:
- sqldata
docker-compose.yml
78

7
9
Docker
• In the docker-compose yml folder:
• up – creates and starts the containers
• stop – stops the containers
• kill – kills the containers
• use docker-compose –-help for more commands
Docker Compose Commands
79

8
0
Docker
• The first tool to provide support was Google Kubernetes.
• Hard to set up and does not re-user the docker API and
tools.
• Now we have Docker Swarm which is native support for
clustering by Docker.
Clustering
80

8
1
Docker
• A cluster of Docker engines where you deploy services
• Docker engines in the cluster are nodes
• Worker node execute tasks
• Manager node
• is responsible for distributing the work
• Serving swarm mode
• Maintaining cluster state
Docker Swarm
81

8
2
Docker
• Service is a definition of tasks to be executed by the
worker nodes
• Replicated services – the swarm manager distributes
number of replica tasks based on the scale
configuration
• Global services – the swarm run one task of the
service on every node
• Task – the atomic scheduling unit – execution of a single
container
Docker Swarm
82

8
3
Docker
Docker Swarm Replicated Service
83

8
4
Docker
Docker Swarm Architecture
84

8
5
Docker
• Supports high availability with several managers.
• Let’s see a demo…
Docker Swarm
85

Reactive Micro Services with Java seminar

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Reactive Micro Services with Java seminar

Similaire à Reactive Micro Services with Java seminar (20)

Plus de Gal Marder

Plus de Gal Marder (7)

Dernier

Dernier (20)

Reactive Micro Services with Java seminar

Notes de l'éditeur