microservices architecture overview v2

56
1 CONFIDENTIAL MICROSERVICES ARCHITECTURE OVERVIEW DZMITRY SKAREDAU, SOLUTION ARCHITECT FEBRUARY 27, 2016

Upload: dmitry-skaredov

Post on 15-Apr-2017

488 views

Category:

Technology


3 download

TRANSCRIPT

Page 1: Microservices architecture overview v2

1CONFIDENTIAL

MICROSERVICES ARCHITECTURE OVERVIEWDZMITRY SKAREDAU, SOLUTION ARCHITECTFEBRUARY 27, 2016

Page 2: Microservices architecture overview v2

2CONFIDENTIAL 2

• Why do we need it• Architecture patterns

AGENDA

• Microservice• API Gateway• Service Discovery• Stateless/Shared-Nothing• Configuration/Service

Consumption• Fault Tolerance• Request Collapsing

• API Versioning

Page 3: Microservices architecture overview v2

3CONFIDENTIAL

WHY DO WE NEED IT

Page 4: Microservices architecture overview v2

4CONFIDENTIAL 4

WE DON’T EXPLICITLYBUT IT DEPENDS

Page 5: Microservices architecture overview v2

5CONFIDENTIAL 5

MICROSERVICES VS MONOLITH

Simple code base Modularity with exact bordersChange circles decoupledEfficient scalingNewcomers adopting fasterPer service team responsibilityNo technology lock

MONOLITH MICROSERVICESComplex code base

Hard to maintain modularityChange circles tightly coupled

Inefficient scalingScaring for newcomers

Hard to scale development team

Tied to chose technology

Page 6: Microservices architecture overview v2

6CONFIDENTIAL 6

MICROSERVICES VALUES

• Heavily relies on Continues Delivery principles

• Fine-grained domain capability• Team autonomy with responsibility• Independent release process• Independent scaling• System resilience• Technology variation

Page 7: Microservices architecture overview v2

7CONFIDENTIAL 7

MICROSERVICES VALUES VS COMPLEXITY

Team autonomyTime to market

ScalingComponentization

Technology variation

Cross teams communicationContinues DeploymentFault toleranceVersioningMaintenance

VALUES COMPLEXITY

Page 8: Microservices architecture overview v2

8CONFIDENTIAL

ARCHITECTURE PATTERNS

Page 9: Microservices architecture overview v2

9CONFIDENTIAL 9

ARCHITECTURE PATTERNS

• Microservice• API Gateway• Service Discovery• Stateless/Shared-Nothing• Configuration Management• Fault Tolerance• Request Collapsing

Page 10: Microservices architecture overview v2

10CONFIDENTIAL

MICROSERVICE

Page 11: Microservices architecture overview v2

11CONFIDENTIAL 11

BOUNDED CONTEXT

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams.

Page 12: Microservices architecture overview v2

12CONFIDENTIAL 12

SIZE OF MICROSERVICE

2 pizza size teamIdeal Size 7 +/-2 persons

Page 13: Microservices architecture overview v2

13CONFIDENTIAL 13

DECENTRALIZED DATA MANAGEMENT

Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence.

You can use polyglot persistence in a monolith, but it appears more frequently with microservices.

Page 14: Microservices architecture overview v2

14CONFIDENTIAL 14

DESIGN FOR FAILURE

Distributed systems are much complex than monolith.

When we have more systems there is more chances to fail.

If more places when you can fails then more often you can deal with failures.

Page 15: Microservices architecture overview v2

15CONFIDENTIAL 15

KEY CONSIDERATION

Before you go into production with a microservices system, you need to ensure that you have key prerequisites in place

• Rapid Provisioning• Basic Monitoring• Rapid Application Deployment• DevOps Culture

Page 16: Microservices architecture overview v2

16CONFIDENTIAL 16

MICROSERVICE VS SOA

Martin FowlerChief Scientist at

ThoughtWorks

Subset of SOA

Zhamak DehghaniPrincipal Consultant at

ThoughtWorks

Style of SOA

Right picture

Page 17: Microservices architecture overview v2

17CONFIDENTIAL

API GATEWAY

Page 18: Microservices architecture overview v2

18CONFIDENTIAL 18

API GATEWAY

How many microservices could be involved here?

Page 19: Microservices architecture overview v2

19CONFIDENTIAL 19

API GATEWAY

9at

least

How many microservices could be involved here?

Page 20: Microservices architecture overview v2

20CONFIDENTIAL 20

API GATEWAY

Page 21: Microservices architecture overview v2

21CONFIDENTIAL 21

API GATEWAY

Page 22: Microservices architecture overview v2

23CONFIDENTIAL 23

API GATEWAY

Page 23: Microservices architecture overview v2

24CONFIDENTIAL

SERVICE DISCOVERY

Page 24: Microservices architecture overview v2

25CONFIDENTIAL 25

SERVICE DISCOVERY PROBLEM

Page 25: Microservices architecture overview v2

26CONFIDENTIAL 26

SERVICE DISCOVERY PROBLEM

Page 26: Microservices architecture overview v2

27CONFIDENTIAL

STATELESS/SHARED-NOTHING

Page 27: Microservices architecture overview v2

28CONFIDENTIAL 28

STICKY SESSIONS

Page 28: Microservices architecture overview v2

29CONFIDENTIAL 29

STICKY SESSIONS

Page 29: Microservices architecture overview v2

30CONFIDENTIAL 30

STATELESS/SHARED-NOTHING

• Store state at the client• Store state at database• Distributed session• Stateless services

Page 30: Microservices architecture overview v2

31CONFIDENTIAL

CONFIGURATION MANAGEMENT

Page 31: Microservices architecture overview v2

32CONFIDENTIAL 32

STORE CONFIG IN THE ENVIRONMENT

The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

http://12factor.nethttp://12factor.net/config

Page 32: Microservices architecture overview v2

33CONFIDENTIAL 33

SPRING CLOUD CONFIG SERVER

Page 33: Microservices architecture overview v2

34CONFIDENTIAL

FAULT TOLERANCE

Page 34: Microservices architecture overview v2

35CONFIDENTIAL 35

FAULT TOLERANCE

Page 35: Microservices architecture overview v2

36CONFIDENTIAL 36

FAULT TOLERANCE

Page 36: Microservices architecture overview v2

37CONFIDENTIAL 37

FAULT TOLERANCE

Availability % Downtime per year Downtime per month Downtime per week Downtime per day

90% ("one nine") 36.5 days 72 hours 16.8 hours 2.4 hours95% 18.25 days 36 hours 8.4 hours 1.2 hours97% 10.96 days 21.6 hours 5.04 hours 43.2 minutes98% 7.30 days 14.4 hours 3.36 hours 28.8 minutes99% ("two nines") 3.65 days 7.20 hours 1.68 hours 14.4 minutes99.5% 1.83 days 3.60 hours 50.4 minutes 7.2 minutes99.8% 17.52 hours 86.23 minutes 20.16 minutes 2.88 minutes99.9% ("three nines") 8.76 hours 43.8 minutes 10.1 minutes 1.44 minutes99.95% 4.38 hours 21.56 minutes 5.04 minutes 43.2 seconds99.99% ("four nines") 52.56 minutes 4.38 minutes 1.01 minutes 8.66 seconds99.995% 26.28 minutes 2.16 minutes 30.24 seconds 4.32 seconds99.999% ("five nines") 5.26 minutes 25.9 seconds 6.05 seconds 864.3 milliseconds99.9999% ("six nines") 31.5 seconds 2.59 seconds 604.8 milliseconds 86.4 milliseconds99.99999% ("seven nines") 3.15 seconds 262.97 milliseconds 60.48 milliseconds 8.64 milliseconds

99.999999% ("eight nines") 315.569 milliseconds 26.297 milliseconds 6.048 milliseconds 0.864 milliseconds

99.9999999% ("nine nines") 31.5569 milliseconds 2.6297 milliseconds 0.6048 milliseconds 0.0864

milliseconds

Without taking steps to ensure fault tolerance, 30 dependencies each with 99.99% uptime would result in 2+ hours downtime/month (99.99%30 ≈ 99.7% uptime = 2+ hours in a month)http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html

0.3% means that the one million request will have 3000 failed

Page 37: Microservices architecture overview v2

38CONFIDENTIAL 38

FAULT TOLERANCE

The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all. Usually you'll also want some kind of monitor alert if the circuit breaker trips.

CIRCUIT BREAKER

Page 38: Microservices architecture overview v2

39CONFIDENTIAL 39

FAULT TOLERANCE: CIRCUIT BREAKER

Page 39: Microservices architecture overview v2

40CONFIDENTIAL 40

FAULT TOLERANCE: CIRCUIT BREAKER

Page 40: Microservices architecture overview v2

41CONFIDENTIAL 41

FAULT TOLERANCE: CIRCUIT BREAKER

Page 41: Microservices architecture overview v2

42CONFIDENTIAL 42

FAULT TOLERANCE

Fallback logic scene involving network access, such as cache access.

FALLBACK DEGRADATION

Page 42: Microservices architecture overview v2

43CONFIDENTIAL

REQUEST COLLAPSING

Page 43: Microservices architecture overview v2

44CONFIDENTIAL 44

REQUEST COLLAPSING

In addition to the isolation benefits and concurrent execution of dependency calls we have also leveraged the separate threads to enable request collapsing (automatic batching) to increase overall efficiency and reduce user request latencies.Collapse multiple requests into a single execution based on a time window and optionally a max batch size.

This allows an object model to have multiple calls to the command that execute/queue many times in a short period (milliseconds) and have them all get batched into a single backend call.

Typically the time window is something like 10ms give or take.

Page 44: Microservices architecture overview v2

45CONFIDENTIAL 45

COLLAPSER FLOW

In addition to the isolation benefits and concurrent execution of dependency calls we have also leveraged the separate threads to enable request collapsing (automatic batching) to increase overall efficiency and reduce user request latencies.Collapse multiple requests into a single execution based on a time window and optionally a max batch size.

This allows an object model to have multiple calls to the command that execute/queue many times in a short period (milliseconds) and have them all get batched into a single backend call.

Typically the time window is something like 10ms give or take.

Page 45: Microservices architecture overview v2

46CONFIDENTIAL

API VERSIONING

Page 46: Microservices architecture overview v2

47CONFIDENTIAL 47

API VERSIONING

• Adding authentication• Adding authorization

rules• Removing a service• API contract changes

REASONS SOLUTIONS• URL Versioning• Media Type Versioning• Custom header• Hostname• Data parameter

Page 47: Microservices architecture overview v2

48CONFIDENTIAL 48

API VERSIONING

One method for indicating versioning is via the URI, typically via a path prefix:

Twitter: http://api.twitter.com/1.1/Last.fm: http://ws.audioscrobbler.com/2.0/ Etsy: http://openapi.etsy.com/v2

Some APIs will provide the version via a query string parameter:

Amazon Simple Queue Service: ?VERSION=2011-10-01

URL

Page 48: Microservices architecture overview v2

49CONFIDENTIAL 49

API VERSIONING

Media type versioning provides the ability to use the same URI for multiple versions of an API, by specifying the version as part of the Accept media type.

The Accept header can provide versioning in two different ways:

• As part of the media type name itself: application/vnd.status.v2+json. In this case, the segment v2 indicates the request is for version 2. You can provide the version string however you desire.

• As a parameter to the media type: application/vnd.status+json; version=2. This option provides more verbosity, but allows you to specify the same base media type for each version.

Many REST advocates prefer media type versioning as it solves the "one resource, one URI" problem cleanly, and allows adding versioning support after-the-fact. The primary argument against it is the fact that the version is not visible when looking at the URI.

MEDIA TYPE

Page 49: Microservices architecture overview v2

50CONFIDENTIAL 50

API VERSIONING

The above two versioning types are the most common; however, other types exist:

• Custom header. As an example,

• X-API-Version: 2• GData-Version: 2.0• X-MS-Version: 2011-08-18• etc.

• Hostname. Facebook, when migrating from the first API version, switched from the host http://api.facebook.com to http://graph.facebook.com.

• Data parameter. This could be a query string parameter for GET requests, as noted above, but a content body parameter for other request methods.

OTHER METHODOLOGIES

Page 50: Microservices architecture overview v2

51CONFIDENTIAL 51

API VERSIONING

• Typical approach. Include API version. Backwards compatible.• Some folks use custom content type allowing each resource to have a version.• Netflix: strive to be version-less from client perspective• Netflix: try to be version-less even if not wholly possible• Adding new data types or new URIs don’t require new version• Structural changes to large unknown developers better to incomplete than inaccurate. Hold onto ideas before

pushing it out.• Netflix assumes 7-10 year life of a TV• Netflix can generally move partners from version to version as needed

NETFLIX APPROACH

Page 51: Microservices architecture overview v2

52CONFIDENTIAL 52

API VERSIONING

It seems that there are a number of people recommending using Content-Negotiation (the HTTP “Accept:” header) for API versioning.

However, none of the big public REST APIs I have looked at seem to be using this approach. They almost exclusively put the API version number in the URI.

Page 52: Microservices architecture overview v2

53CONFIDENTIAL 53

API VERSIONING

Twitter URI

Atlassian URI

Google Search URI

Github API URI/Media Type in v3

Intention is to remove versioning in favour of hypermedia – current application/vnd.github.v3

Azure Custom Header x-ms-version: 2011-08-18

Facebook URI/optional versioning graph.facebook.com/v1.0/me

Bing Maps URI

Netflix URI parameterhttp://api.netflix.com/catalog/titles/series/70023522?v=1.5

Page 53: Microservices architecture overview v2

54CONFIDENTIAL 54

API VERSIONING

Google data API (youtube/spreadsheets/others)

URI parameter or custom header “GData-Version: X.0” or “v=X.0”

Flickr No versioning?

Digg URIhttp://services.digg.com/2.0/comment.bury

Delicious URI https://api.del.icio.us/v1/posts/update

Last FM URI http://ws.audioscrobbler.com/2.0/

LinkedIn URIhttp://api.linkedin.com/v1/people/~/connections

Foursquare URI

https://api.foursquare.com/v2/venues/40a55d80f964a52020f31ee3?oauth_token=XXX&v=YYYYMMDD

Page 54: Microservices architecture overview v2

55CONFIDENTIAL 55

API VERSIONING

paypal parameter &VERSION=XX.0

Twitpic URI http://api.twitpic.com/2/upload.format

Etsy URI http://openapi.etsy.com/v2

Tropo URI https://api.tropo.com/1.0/sessions

Tumblr URI api.tumblr.com/v2/user/

openstreetmap URI and response body http://server/api/0.6/changeset/create

Ebay URI (I think)http://open.api.ebay.com/shopping?version=713

Page 55: Microservices architecture overview v2

56CONFIDENTIAL 56

API VERSIONING

Wikipedia no versioning I think?

Bitly URI https://api-ssl.bitly.com/v3/shorten

Disqus URIhttps://disqus.com/api/3.0/posts/remove.json

Yammer URI /api/v1

Drop Box URIhttps://api.dropbox.com/1/oauth/request_token

Amazon Simple Queue Service (Soap)URI Parameter and WSDL URI &Version=2011-10-01

Page 56: Microservices architecture overview v2

57CONFIDENTIAL

QUESTIONS?