Spring Cloud’s Groovy

Spring Cloud’s Groovy

Marcin Grzejszczak, Pivotal@mgrzejszczak

@MGrzejszczak @gr8day_warsaw#GR8DayWAW

About meDeveloper at Pivotal

Part of Spring Cloud Team

Working with OSS

TWITTER: @MGrzejszczak

BLOG: TOOMUCHCODING.COM


AgendaWhat are we using Groovy for at Spring Cloud?

Quick introduction to Distributed Tracing

Why Gradle made it possible to test Spring Cloud?

How we’re testing with Spock?

DEMO


What are we using Groovy for at Spring Cloud?Spring Cloud Zookeeper tests with Spock

End to end tests of Spring Cloud

Zookeeper

Consul

Eureka

Netflix (Zuul, Ribbon, Feign)

Sleuth






DEMO


Quick Introduction To Distributed TracingModern applications are a gigantic net of interconected components

It’s crucial to have tools that allow you visualize the system’s topology and performance issues

Dapper, a Large-Scale Distributed Systems Tracing Infrastructure


Quick Introduction To Distributed TracingZipkin

A distributed tracing system.

Helps gather timing data needed to troubleshoot latency problems in microservice architectures

The front end is a "waterfall" style graph of service calls showing call durations as horizontal bars


Quick Introduction To Distributed TracingSpring Cloud Sleuth

Implements a distributed tracing solution for Spring Cloud.

Borrows Dapper’s terminology.

Integrates with Zipkin


TerminologySpan

The basic unit of work (e.g. sending RPC)

Spans are started and stopped

They keep track of their timing information

Once you create a span, you must stop it at some point in the future


TerminologyTrace

A set of spans forming a tree-like structure.

For example, if you are running a book store then a trace could be retriving a list of available books


Terminology

SERVICE 1

REQUEST

No Trace IdNo Span Id

RESPONSE

SERVICE 2

SERVICE 3

Trace Id = XSpan Id = A



REQUEST

RESPONSE

Trace Id = XSpan Id = BClient Sent

Trace Id = XSpan Id = B

Client Received


Server Received

Trace Id = XSpan Id = C

Trace Id = XSpan Id = BServer Sent

REQUEST

RESPONSE

Trace Id = XSpan Id = DClient Sent

Trace Id = XSpan Id = D

Client Received


Server Received

Trace Id = XSpan Id = E

Trace Id = XSpan Id = DServer Sent


SERVICE 4

REQUEST

RESPONSE

Trace Id = XSpan Id = FClient Sent

Trace Id = XSpan Id = F

Client Received


Server Received

Trace Id = XSpan Id = G

Trace Id = XSpan Id = FServer Sent




Terminology

Span Id = AParent Id = null

Span Id = BParent Id = A

Span Id = CParent Id = B

Span Id = DParent Id = C

Span Id = EParent Id = D

Span Id = FParent Id = C

Span Id = GParent Id = F


Terminology

SERVICE 1/start

REQUEST

No Trace IdNo Span Id

RESPONSE

SERVICE 2/foo

SERVICE 3/bar




REQUEST

RESPONSE

Trace Id = XSpan Id = BClient Sent


Client Received


Server Received


Trace Id = XSpan Id = BServer Sent

REQUEST

RESPONSE

Trace Id = XSpan Id = DClient Sent


Client Received


Server Received


Trace Id = XSpan Id = DServer Sent


SERVICE 4/baz

REQUEST

RESPONSE

Trace Id = XSpan Id = FClient Sent


Client Received


Server Received


Trace Id = XSpan Id = FServer Sent




Terminology






DEMO


Why Gradle made it possible to test Spring Cloud?What we wanted to achieve:

apart from having good unit / integration tests we wanted to see all building blocks working together

we didn’t want to write different test apps for different libraries

we wanted to write a solution that could test the libs on Cloud Foundry (PaaS by Pivotal)

we wanted to prove that Spring Cloud’s Service Discovery integration is all about changing jars and configs


Why Gradle made it possible to test Spring Cloud?What do we want to test?

service discovery is working - apps can talk to each other

via RestTemplatevia Feign

Sleuth is working

proper spans were createdtrace information got propagated


Why Gradle made it possible to test Spring Cloud?change the apps building blocks by properties:


Why Gradle made it possible to test Spring Cloud?package apps with desired building blocks

./gradlew clean build --parallel -DWHAT_TO_TEST=CONSUL

./gradlew clean build --parallel -DWHAT_TO_TEST=EUREKA

./gradlew clean build --parallel -DWHAT_TO_TEST=SLEUTH


Why Gradle made it possible to test Spring Cloud?create Dockerfiles by executing a closure


Why Gradle made it possible to test Spring Cloud?clear separation of configurations


Why Gradle made it possible to test Spring Cloud?$ ./runAcceptanceTests.sh

USAGE:

You can use the following options:

-t|--whattotest - define what you want to test (e.g. SLEUTH, ZOOKEEPER)

-v|--version - which version of BOM do you want to use? Defaults to Brixton snapshot

-h|--healthhost - what is your health host? where is docker? defaults to localhost

-l|--numberoflines - how many lines of logs of your app do you want to print? Defaults to 1000

-r|--reset - do you want to reset the git repo of brewery? Defaults to "no"

-k|--killattheend - should kill all the running apps at the end of execution? Defaults to "no"

-n|--killnow - should not run all the logic but only kill the running apps? Defaults to "no"

-x|--skiptests - should skip running of e2e tests? Defaults to "no"

-s|--skipbuilding - should skip building of the projects? Defaults to "no"

-c|--cloudfoundry - should run tests for cloud foundry? Defaults to "no"

-o|--deployonlyapps - should deploy only the brewery business apps instead of the infra too? Defaults to "no"

-d|--skipdeployment - should skip deployment of apps? Defaults to "no"






DEMO


How we’re testing with Spock?we wanted to

run same tests for Cloud Foundry and locally

run the same tests with different libraries used

only execute related tests


How we’re testing with Spock?@Requires({ TestConditions.SLEUTH() })

class SleuthBreweryAcceptanceSpec extends AbstractBreweryAcceptanceSpec {

@Unroll

def 'should successfully pass Trace Id via [#communicationType] and processId [#referenceProcessId]'() {

given:

RequestEntity requestEntity = an_order_for_all_ingredients_with_process_id(referenceProcessId, communicationType)

when: 'the presenting service has been called with all ingredients'

presenting_service_has_been_called(requestEntity)

then: 'eventually beer will be brewed with same Trace-Id as the first request'

beer_has_been_brewed_for_process_id(referenceProcessId)

and: 'entry will be present in Zipkin'

entry_for_trace_id_is_present_in_Zipkin(referenceProcessId)

where:

communicationType << [CommunicationType.REST_TEMPLATE, CommunicationType.FEIGN]

referenceProcessId = Span.idToHex(new Random().nextLong())

}

}



static final Closure<Boolean> SLEUTH = {

return whatToTestSystemPropMatchesAny(

[WhatToTest.SLEUTH, WhatToTest.SLEUTH_STREAM]

)

}






DEMO


SummaryGradle allowed to create highly customizable project just by changing a property

With Groovy and Spock we’ve managed to create a test setup that is readable and platform-independant

Even though they are hard to debug - with E2E we’ve managed to find quite a few bugs already


Thank You!Sleuth Repo & Docs:

https://github.com/spring-cloud/spring-cloud-sleuth

http://cloud.spring.io/spring-cloud-sleuth/spring-cloud-sleuth.html

The Brewery

https://github.com/spring-cloud-samples/brewery

Rationale behind E2E tests

https://spring.io/blog/2016/01/04/testing-spring-cloud-projects





https://github.com/spring-cloud-samples/brewery/

https://github.com/spring-cloud-samples/brewery/



Spring Cloud’s Groovy

Technology

Transcript of Spring Cloud’s Groovy