#onenote# micro service

What are Microservices?

• “A loosely coupled service oriented architecture with bounded contexts” – Adrian

Cockroft

• Loosely coupled

• Services can be updated independently

• Bounded context

• Services are responsible for a well defined business function

• And care little about the services that surround it

• ie. “Do one thing and do it well”

Microservice Architectures are

• HTTP based (or communicate via other open standards)

• Containerized

• Independently deployable and scalable

• Self-sufficient

o Makes as little assumptions as possible on the external environment

Spring Boot Actuator

Spring Boot Actuator is one of the greatest and most useful feature in Spring Boot framework. Actuator module in spring boot helps application developers to implement the production grade features like metrics, health check, security, etc. with minimal effort.

The following technology agnostic endpoints are available:

ID

Description

Sensitive Default

actuator

Provides a hypermedia-based “discovery page” for the other endpoints. Requires Spring HATEOAS to be on the classpath.

true

autoconfig

Displays an auto-configuration report showing all auto-configuration candidates and the reason why they ‘were’ or ‘were not’ applied.

true

beans

Displays a complete list of all the Spring beans in your application.

true

configprops

Displays a collated list of all @ConfigurationProperties.

true

dump

Performs a thread dump.

true

env

Exposes properties from Spring’s ConfigurableEnvironment.

true

flyway

Shows any Flyway database migrations that have been applied.

true

health

Shows application health information (when the application is secure, a simple ‘status’ when accessed over an unauthenticated connection or full message details when authenticated).

false

info

Displays arbitrary application info.

false

liquibase

Shows any Liquibase database migrations that have been applied.

true

metrics

Shows ‘metrics’ information for the current application.

true

mappings

Displays a collated list of all @RequestMapping paths.

true

shutdown

Allows the application to be gracefully shutdown (not enabled by default).

true

trace

Displays trace information (by default the last 100 HTTP requests).

true

From <http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-endpoints.html>

For a Spring Boot Actuator application there are some additional management endpoints:

      • POST to /env to update the Environment and rebind @ConfigurationProperties and log levels
      • /refresh for re-loading the boot strap context and refreshing the @RefreshScope beans
      • /restart for closing the ApplicationContext and restarting it (disabled by default)
      • /pause and /resume for calling the Lifecycle methods (stop() and start() on theApplicationContext)

From <http://cloud.spring.io/spring-cloud-static/docs/1.0.x/spring-cloud.html>

Config service

The default profile is named default. To configure properties for different environments, we have to configure different files as given in the following example. In this example, the first file is for the development environment whereas the second is for the production environment:

application-development.properties
application-production.properties

In short, the URL is based on the following pattern: http://localhost:8888/{name}/{profile}/{label}.

The configuration can also be accessed by ignoring the profile. In the preceding example, all the following three URLs point to the same configuration:

Rrefresh Config

In order to force reloading of the configuration properties, call the /refresh endpoint of the Search microservice. This is actually the actuator’s refresh endpoint. The following command will send an empty POST to the /refresh endpoint:

curl –d {} localhost:8090/refresh

From <http://techbus.safaribooksonline.com/9781786466686/ch02_html?percentage=7.485030&reader=html#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODE3ODY0NjY2ODYlMkZjaDA1bHZsMnNlYzExMl9odG1sJnF1ZXJ5PQ==>

The Spring Cloud Bus provides a mechanism to refresh configurations across multiple instances without knowing how many instances there are, or their locations. This is particularly handy when there are many service instances of a microservice running or when there are many microservices of different types running. This is done by connecting all service instances through a single message broker. 

From <http://techbus.safaribooksonline.com/9781786466686/ch02_html?percentage=7.485030&reader=html#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODE3ODY0NjY2ODYlMkZjaDA1bHZsMnNlYzExM19odG1sJnF1ZXJ5PQ==>

autoscaling system

A typical autoscaling system has capabilities as shown in the following diagram:

From <http://techbus.safaribooksonline.com/9781786466686/ch02_html?percentage=7.485030&reader=html#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODE3ODY0NjY2ODYlMkZjaDA2bHZsMnNlYzEzM19odG1sJnF1ZXJ5PQ==>

Reactive MicroServices Architecture

The following four traits make up reactive applications:

      • Responsive —React to users
      • Scalable —React to load
      • Resilient —React to failure
      • Event-driven —React to events

Responsive

The first and foremost quality of a service is that it must respond to requests it receives. The same holds true in those cases where services consume other services. They also expect responses in order to be able to continue to perform their work. A responsive application satisfies consumers’ expectations in terms of availability and real-time responses. Responsiveness is measured in latency, which is the time between request and response.

Resilient

A very high-quality service performs its function without any downtime at all. But failures do happen and handling failure of an individual service in a gentle way without affecting the complete system is what the term resiliency describes. As a matter of fact, there is only one generic way to protect your system from failing as a whole when a part fails: distribute and compartmentalize.

Elastic

A successful service will need to be scalable both up and down in response to changes in the rate at which the service is used. With sudden traffic bursts hitting an application, it must be able to make use of increased hardware capacity when needed. This includes not only working on one machine but also how to facilitate the power of several physical nodes in a network spanning various locations transparently.

Message-Driven

The only way to fulfill all of the above requirements is to have loosely coupled services with explicit protocols communicating over messages. Also known as “share nothing” architecture, this removes scalability limits imposed by Amdahl’s law. Components can remain inactive until a message arrives, freeing up resources while doing nothing. In order to realize this, nonblocking and asynchronous APIs must be provided that explicitly expose the system’s underlying message structure.

Basic Microservices Requirements

When designing individual reactive microservices, it is important to adhere to the core traits of:

      • Isolation
      • Autonomy
      • Single responsibility
      • Exclusive state
      • Asynchronous message passing
      • Mobility

From <http://techbus.safaribooksonline.com/book/software-engineering-and-development/9781491975640/2dot-reactive-microservices-and-basic-principles/chapter_02_html>

http://www.lightbend.com/lagom

It offers four main features:

      • A Service API that provides a way to declare and implement service interfaces, to be consumed by clients. For location transparency, clients use stable addresses and discover services through a service locator. The Service API supports synchronous request-response calls as well as asynchronous messaging and streaming between services.
      • The Persistence API provides event-sourced persistent entities for services that store data, with CQRS read-side support for queries. It manages the distribution of persisted entities across a cluster of nodes, enabling sharding and horizontal scaling, with Cassandra as the default database backend.
      • The Development Environment allows you to run all your services, and the supporting Lagom infrastructure, with one command. It hot-reloads your services when code changes.
      • Lagom Services can be deployed as they are directly to production using ConductR, a platform for monitoring—and scaling—of Lagom services in a container environment—no additional infrastructure needed.

From <http://techbus.safaribooksonline.com/book/software-engineering-and-development/9781491975640/2dot-reactive-microservices-and-basic-principles/chapter_02_html#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODE0OTE5NzU2NDAlMkZjaGFwdGVyXzAzX2h0bWwmcXVlcnk9>

Microservice Security Concerns

• Central user store bottleneck

• Single sign on

• Statelessness

• User credentials == pure pwnage

• Fine grained authorization

• Interoperability with non browser clients

What is OAuth2?

Delegated Authorization

• A protocol for conveying authorization decisions (via a token)

• Standard means of obtaining a token (aka the 4 OAuth2 grant types)

• Authorization Code

• Resource Owner Password Grant

• Implicit

• Client Credentials

• Users and Clients are separate entities

• “I am authorizing this app to preform these actions on my behalf”

What is OAuth2 Not?

OAuth2 is not Authentication

• The user must be authenticated to obtain a token

• How the user is authenticated is outside of the spec

• How the token is validated is outside the spec

• What the token contains is outside the spec

• Read more: http://oauth.net/articles/authentication/

What is OpenID Connect?

Delegated Authentication

• A protocol for conveying user identity (via a signed JWT )

• Built on top of OAuth2

• Standard means of obtaining an ID token

• The same 4 OAuth2 grant types are supported

• Standard means of verifying ID tokens

• “Will is authorizing this app to preform these actions on his behalf”

• And here’s his email address in case you need it

Spring Cloud Security

Features

• SSO with OAuth2 and OpenID Connect servers

• With a single annotation (and some config)

• Secure Resource Servers with tokens

• With a single annotation (and some config)

• Relay tokens between SSO enabled webapps and resource servers

• With an autoconfigured OAuth2RestTemplate

Machine generated alternative text:
Service Registry -Register Service instance
________________ Microservice
Litecycie Manager 9et Service instance 1
Change Status _____________ Instances
Metrics Collector
Microservice
. Instance 2
scaling policies Load Balancer H MicroseMce
________________ instance 3
Decision Engine
__________________ Microservice
instance 4
Depioyment Rules
Deployment Engine
I get Metrics J
UP /Down Instances

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s